[CoolGuySteve]

This reads like a horoscope. I can tut-tut at the over engineers and under engineers while considering myself just right.

Anyone to the left or right of me on the spectrum will also think they're just right and I'm one of the former or latter. This recursive confirmation bias then sends the article straight to the front page.

This is the most smug article I've read on here in a long time. Why can't we just be professionals?

[Bahamut]

When I clicked the link, I was expecting a breakdown on aspects that engineers tend to excel at and what those types tend to be weak at. This article sorely disappoints at an opinionated breakdown with no way to extract it into a more objective measure.

[gervase]

I believe it usually goes something like, "Everyone who drives slower than me is an idiot; everyone who drives faster than me is a maniac!"

[robohamburger]

I think a far more useful way to divide up software engineers is by how good they are at gathering requirements/understanding the problem they have been tasked with.

That said, and this might be crazy... but sometimes it is nice to have people good at different things on your team :)

With a good lead you can have a person with overengineering leanings on your team and have it be a strength as long as you balance that with other ways of thinking.

[Thimothy]

I find that the only acceptable way to divide engineers is with a chainsaw. It might get messy, and is hard to hunt them down especially if they are of the runner kind, but afterwards you get the satisfaction of a work well done.

[robohamburger]

Slow Romero style coders can be sawed 10x faster than other normal ones.

[akvadrako]

If you haven't been in the industry long you'll realise that actual professionals (without quotes) are no more than 10% of the workforce.

Not saying the article isn't written by a "professional", but it's not like it's a solved problem, how to get engineers to behave.

[okhudeira]

Author here.

Your response is a bit over the top. I'm in no way criticizing anyone or placing myself above anyone. I've been a junior engineer and I've under-engineered. I've been a mid-level engineer and I've over-engineered. Only through feedback from senior engineers did I finally get to see code I wrote stand the test of time 2 years later with minimal to no change.

As I mentioned in the post, no matter how many years we've been doing this, we'll continue to over-engineer and under-engineer because software is hard. The article is meant to layout the mistakes I've learned from, and for engineering managers, our responsibility is to help those we manage avoid the pitfalls we ran into.