I very much doubt this originated from me but whether I heard this somewhere and took a liking to it or thought of it myself, I became fond of saying this while

I very much doubt this originated from me but whether I heard this somewhere and took a liking to it or thought of it myself, I became fond of saying this while I was at Google: "How do you know if you're engineering if you're not overengineering?" Now I don't direct this at Google specifically. This is more about the mental traps we, as engineers, can easily fall prey to. Take interviewing and the FizzBuzz thing that was popularized (if it didn't originate with) Joel Spolsky. The beauty of FizzBuzz is that it's a quick and great _negative_ signal. This doesn't mean that if you ace it, you're a superb engineer but it does mean if you fail it, you're almost certainly not. Hiring (from the employer's perspective) is a numbers game. Every candidate costs you time (giving interviews, writing feedback, etc) and is a huge opportunity cost (other work that could be done, other candidates that could've been interviewed) so the goal is the filter out the "no"s as quickly as possible. So the engineer trap when faced with something like FizzBuzz is to think "oh wait, that's too simple!" and they go on to change the problem to something you'll pass if you've heard of the particular obscure algorithm and will probably fail if you haven't. It's a easy fallacy to fall for. Harder is better. However now you're not optimizing to cull early candidates. Now you've designed a test that optimizes for people who do well coding under pressure (with some degree of luck) on a whiteboard. That is completely different from the original intent and (IMHO) almost entirely useless as a hiring signal. Another example: another thing I was fond of saying at Google was that there was a hierarchy of engineers: - At the top level (in their minds) were the C++ engineers. You're not engineering if you're not writing code in C++ (basically) - Next tier were the Java engineers. They thought you weren't engineering unless you were writing in Java or C++ - Next came Python and Go - Last came Javascript Now at Google I met some engineer who were _superb_ C++ engineers. Like truly amazing. I also met others who were like walking Wikiepedias for the C++11/14/17 standards. And no, that's not the same thing. So one example that springs to mind once was surprised to learn that I didn't know what perfect forwarding was. This is something that probably only needs concern you if you're writing a widely used C++ library using templates (especially template metaprogramming). As a user of such libraries, it's not often something you need to know. My point here is that with all the knots C++ has twisted itself into over the years as a result of its origin and legacy, the trap some fall into is viewing such complexity as a virtue instead of baggage. IME these aren't the people you want making design decisions on complex systems. The people you want making design decisions on complex systems are the ones who reverently follow Postel's Law.