Interesting. I never thought about dividing engineers this way. I do know that the two best engineers I've ever met were slow. Not just slow in working, but slow in everything. Speaking, moving, etc. This frustrated some people, but these engineers saved everyone else much time and frustration because their work was rock solid, well thought-out, and complete.

And, once you accounted for time spent bug-fixing and validating things, they weren't actually slow.

> And, once you accounted for time spent bug-fixing and validating things, they weren't actually slow.

The constant battle between instant gratification and delayed satisfaction.

“Delayed satisfaction”—I love that.

> two general classes of great engineers: fast and slow ... Everything else I would try to have tension -- a mix of the two

To add to this, if you are one of these engineers a great career hack is to find an engineer you respect on the other end of the spectrum and partner with them.

As a "slow" engineer I make sure our key interfaces are abstractions are correct and my "fast" partner ensures that everything gets shipped and that I don't sweat the small stuff. This has lead to a lot more successful and impactful projects than I could manage on my own or with another "slow" engineer.

Some of that is deeply ingrained, but it’s useful to be able to swap between different kinds of problem solving.

Ultimately, there isn’t a single best approach to software development just different tradeoffs. Being able to whip up a bug ridden happy path that only works for some set of data is useful when trying to build an understanding of some new system. At the other end even if most of what you do is short lived demos creating a few rock solid building blocks can save you a great deal of pain.

:D

May I propose terminology that has less negative connotations associated with them? How about "quick" vs "deliberate"?

Yes, I sometimes say fast and precise

Focus-work that is broad and shallow versus narrow and deep.

As a slow engineer I always liked the term “careful”. As in:

Move carefully and fix things; vs

Move fast and break things.

I’d say that most experienced tradespeople are capable of operating in either mode or somewhere along the continuum.

Personality traits, beliefs, perspective, motivations, attitudes, age, and experiences might predispose someone to favor one side or the other.

Since I consider "Move fast and break things" to be one of the worst and most destructive philosophies to find adoption in software engineering, I guess it's obvious which side I favor.

It depends on what you're building, tbh. If you run a large b2c site and want to outpace your competition then you default to shipping. If the costs of failures are much higher, you are better off defaulting to a slow and steady pace.

True, from a certain business point of view. As a customer, though, I want nothing to do with such software and I don't want to work on software that I wouldn't personally use. That's why I say it's obvious which side I fall on.

> I found that there were two general classes of great engineers: fast and slow

There is a third type: those who can adapt to what is appropriate under the circumstances.

Yeah, I gotta say, it seems like one of the key skills that differentiates a mid-level dev from a senior one is knowing whether the current task calls for being a slow engineer vs being a fast engineer.

This is an interesting observation. I like to think myself as a slow programmer. Do you think discussing this in an interview before you actually got the job in order to evaluate if you are fit to the role joining is a good idea ?

Sure, just use the word “meticulous” instead of slow.

That's how I see brains work differently: fast and slow - one brain can quickly associate, find information; another brain is slow to load, in the end, you get 100% of what you need. I appreciate slow brains.