The conversation

Lessons learnedExperience excerpt · English

I like to rate engineers across various categories, but really I found that there were two general …

I like to rate engineers across various categories, but really I found that there were two general classes of great engineers: fast and slow. For marketing tests, etc., the whole team would be fast engineers. For payments, the whole team would be slow. Everything else I would try to have tension -- a mix of the two so they learn and appreciate each other. This is condensing a multidimensional vector into just a line, but effective enough to explain to non-engineers. If you are a precision (slow) engineer, then you are more likely on the backend, more likely to write tests, more likely to avoid costly errors. This will be wasted on some kinds of tasks (trying out new things, for example, but as a class these tasks can generate a lot of management interest). The only kind of management interest in the precision stuff is failure, and it is usually doomsday failure. That said, security is always present, and I am noodling ideas right now on how to eliminate whole classes of security and privacy issues while making it even easier faster for all engineer types.

Original discussionOne common behavior seen in “mature” software engineers119 source comments · at import
8

What was this responding to?

Parent context · original excerpt

PA

The idea of fixing a whole class of problems is common in safety critical software. When you find the cause of a bug its not just about fixing the bug but looking for this pattern of failure everywhere and fixing that and then understanding the aspects that led to this class of bugs to begin with and eliminating those. Its just good engineering to solve the class of problems not just the bug in front of you. But I have also been part of a team that was replaced by another because we weren't heroic enough, because we had no bugs in our software and there was no drama for the business to get what it wanted and needed. Management rarely values this type of engineering.

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 8

Direct replies available in this import. Original-language excerpts.

HE

> 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.

Full original
JO

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.

Full original
RE

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.

Full original
AM

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

Full original
TH

As a slow engineer I always liked the term “careful”. As in: Move carefully and fix things; vs Move fast and break things.

Full original
RL

> 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.

Full original
ZU

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 ?

Full original
PO

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.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.