[neilv]

> premature optimization

This reminds me of my first FAANG interview, about 2 decades ago. I was already accomplished, and I assumed it would be a normal software interview, which pretty much always went very well. But once in the interview, they wanted me to write some code on a whiteboard, which I'd only seen once before, and to talk as I'm doing it. OK, I'll try that. (I actually hadn't slept the night before, for unrelated reasons, and I'd unknowingly eaten something that makes me feel queasy, but I knew my way around whiteboard analysis and design, and I guess I could code on one.)

Right before then, I'd been working on an (introvert-powered) meticulous coding style, so I adapt that style to this unfamiliar interview format. I was time-slicing my attention between focusing on the code, and explaining my thinking process for some stranger's mental model (plus the social context awareness overhead).

While I'm coding on the whiteboard, I see that I have a variable that will end up getting set redundantly sometimes in a loop. As I quickly correct that, I verbalize what I'm doing.

And he interrupts me with an order, "Don't prematurely optimize." No clarification -- like that he thinks I'm barking up the wrong tree on algorithm approach (plausible), or that he doesn't know that meticulous coding can be super-effective and not a barrier to also seeing bigger picture, or that he just knows "premature optimization" is a thing. I should've asked, but I was thrown by interruption of my flow, and the tone of voice.

In any case, that set the tone for the interview, and I didn't get an offer, somewhere that otherwise seemed made for me. I ended up going instead to a career path much less lucrative than 2 decades of FAANG, so that might've been an extremely expensive waste of whiteboard marker.

Today, people who use the term premature optimization had better be using it well, or I will secretly think glares at them.

[TeMPOraL]

I feel for you. I'd probably be just as distracted as you were if this happened in the middle of an interview, but in the off case I weren't, I'd probably talk the interviewers' ear off. What they seem to not understand is, this kind of correction is natural and perfectly normal when you're writing code. I do it all the time - I think of a small piece of code to write, I write it, and before I'm done I notice obvious improvements, which I do on the fly.

It's not "premature optimization", as it costs me nothing (on the contrary, not doing it will cost me my focus / peace of mind), improves performance of the code - or rather, avoids stupidity - and often improves readability, as the code is now closer to a "pure" description of what it's supposed to do.

I've long held that a big part of why software today sucks so badly is because people don't do this, or likely can't do this. They write stupid code, and never bother to learn how to write non-stupid version of the same code by default.

[neilv]

I suppose it might be more normal for C and C++ programmers to get in the habit of meticulous thinking through the code as we write it, since that's more a necessity than in most other languages. (If we're not careful, we risk having to pay with painful debugging sessions, and expensive correctness/stability/security problems.)

But meticulous coding is still useful for nontrivial code in any language that we want to work well. And it's not that hard; it's just something we practice and get better at over time.

[progmetaldev]

This is the same process that I follow. I think the best developers I've met are constantly going through this iterative approach as they code, instead of leaving it to come back to. Besides not having the time once a manager sees a working model, I think this makes you a better developer and allows you to focus on the problem more clearly with a "clean" initial solution.