[closeparen]

Nope, not even slightly. Research is something you do after you know the problem at hand, to see if you find anything helpful. Preparation is something you do before you know the problem to minimize reaction time once the problem is revealed. Preparation is wildly inefficient, as it involves studying a bunch of material that will not turn out to be needed, just in case.

If you're writing software under the kind of time pressure where consulting reference material is unacceptable, something is deeply wrong. Most software engineers, most of the time, should be able to research topics as they come up rather than prepare (beyond the standard preparation in college).

Making long-term plans, building consensus around them, etc. is important, but is nothing like practicing for whiteboard interviews.

[Blazespinnaker]

So wrong in so many different ways. The questions you research / prep for may be needed at some point in your career.

Much like programming. You program for all relevant edge cases, as one might be used at some point.

People who don’t prep are horribly lazy and are terrible at enumerating edge cases. The have buggy code that fails at some point. Laziness is by far the way worse quality? Though not the only sin.

Lack of sincere desire to be helping the team succeed and no innate talent are bad too.

[closeparen]

>The questions you research / prep for may be needed at some point in your career.

And most people, most of the time, can and should research them as needed.

>You program for all relevant edge cases, as one might be used at some point.

Yes, because a program doesn't get to pause execution and defer to the human mind to ask "hmm, what do I do in this case?" A programmer does so all day every day.

>are terrible at enumerating edge cases

Any attempt to pre-compute the edge cases of all possible programming situations will be hopelessly inadequate. Enumerating edge cases requires analytical thinking in the moment, essentially the opposite of preparation.