Observable Traits of Great Engineers
How can someone who is not a software engineer discern someone who is world class at software engineering?
How can someone who is not a software engineer discern someone who is world class at software engineering?
Non-technical founders and product managers struggle with this challenge regularly, especially those who are entering the software space for the first time. While there aren’t many great answers before the person is writing code (besides having another world class engineer vet the person), there are many observable traits after the work begins. Most of these indicators surface within days to a few weeks, which I’d argue is generally early enough to avoid a major problem.
Here’s my working list. Please note that I’m only trying to enumerate the traits that diagnostically separate great software engineers from mediocre ones.
Speed. The greatest engineers I’ve worked with take concepts and turn them into working code generally within a day or a few days. If you’re checking in week-on-week and there’s no real progress, that’s a huge red flag.
Accuracy and Improvisation. The solution precisely solves the problem discussed without extensive back and forth on details, and when you see the solution you realize that the engineer understands it better than you did because he or she has also improvised to improve upon the concept. This is not to say that back and forth discussion isn’t valuable, it is, and it almost always improves the result, but the unicorn super engineers I know all love to take a vague discussion and make it into something useful without a lot of intervention in the process. This leaves the creativity in the engineer’s hands.
Sufficiently abstracted. The solution is not brittle, and it can adapt to new, reasonable pressures to expand into adjacent uses. You know this is true when you say, “could it also do X?” and the response is “yup, no problem” and then a few hours later it actually can do that thing.
Handles edge cases. Does not immediately break the moment someone acts like a human and interacts with the creation in an unexpected or clunky way.
Tight loops/production ready. There is never a long delay between ask and some incremental delivery. A lot of engineers will say “it’s done” and when you ask to see/touch the product, waffling ensues. This is born out of neglecting that deploying a product for real world testing is in itself real engineering work that exposes new challenges. If you can’t play with it, it’s not real. The best in class don’t assume that you’ll install a bunch of programs and perform hours of setup to be able to view the product. They view “done” as “ready for anyone to touch” even when that touch is the first ever non-developer touch. Walking this walk means the engineer is doing their own smoke tests which raises the quality bar substantially. It also shows that the engineer groks that tight feedback loops make great products, not endless private toil.
Rarely calls an ask impossible, but acknowledges real obstacles. Generally this is about imagination and skill. Imagination because “impossible” can usually be translated into a first version that is simpler than the “impossible” ask but still gets at the core of the idea, and skill because a lot of people give up when something gets hard or they become frustrated. The best always find another way or consult with someone else until a viable possibility emerges.
Software engineer colleagues and friends–please feel free to comment on the list! Would love to harden it in the public domain as these are intended to be transparent observables that anyone could discuss together.
(Originally posted June 27, 2018 on previous blog)