Look for someone who values:

1. Provide business value over loving technology
   1. We are in tech because we do love technology but we should only love technology as a means to love others and help others – otherwise, our love of technology is self-centered.
      
2. Be humble
   1. We all make mistakes and we should always be learning from them instead of being discouraged.
   2. Always assume when others make mistakes that it was because of a lack of understanding and not because the person is incompetent or negligent.
   3. A great software engineer is humble. We deal with complex systems and we will write bugs – we should not pretend otherwise and we should be humble enough to admit that as being humble helps new people realize that they too can become a great software engineers.
      
3. A great programmer should be doing things to reduce business and technical misunderstanding
   1. For example, they might create diagrams, lead discussions, prefer MVPs, seek rapid feedback. If they talk more about getting good requirements or how work tickets are written, there is a good chance they do not do anything to reduce misunderstanding. They are expecting someone else to do that for them and they just want to be a ticket taker. Everyone should own helping others improve their understanding for a team to be amazing. Ticket takers by their nature take much more than they give and are not good long-term for a team to be amazing.
      
4. Code reliability is more important than readability
   1. Code that one can trust is a super-power.
   2. The tools to support reliability are Test-Driving-Development (TDD) and End-to-End testing or testing like a user or system would use the software. It might surprise one that unit tests do not support reliability very much as it mostly tests implementation details and not realistically how the system would be used. Same with type checking as that is also focused on an implementation detail and not reliability from a user or business perspective. (I have more on that topic but it will have to wait until another blog post).
   3. Reliability is the greatest stress reducer and allows an engineer to have a life outside of work
      
5. Code readability is more important than efficiency or demonstrating one’s abilities
   1. Readability is kindness to others and to your future self
   2. Code trickiness is NOT a sign of intelligence or a great programmer – it is a sign of an unclear mind, arrogance, show-off, or someone who thinks trickiness means job security
   3. Readability means that someone fresh from a good boot-camp or college can read the code and understand 95% of what it does and someone who has had a 101 level understanding can follow the control flow just by reading the code (understand about 80% of the code).
   4. The only valid reason to make code tricky or less readable is to make it more reliable based on a known issue. The reliability issue NEEDs a test or a few so that others understand why the less readable path was taken.
      
6. Code reliability and code readability are more important than deadlines
   1. Analogy: shipping an airplane on time that crashes is NOT preferred to shipping an airplane late that flies perfectly.
   2. If a deadline is hard then you have to control scope (i.e., reduce it) so that readability and reliability are not compromised.
      
7. Values the little fixes
   1. The little fixes for the business are usually undervalued but they always add lots of social value. For example, the search text-box on your home page once in focus for typing grows 2px wider causing the header elements to shift noticeably. This is a small fix but leaving it tells your users A) you don’t use your own software so you have noticed this problem – not a sign of trust; B) you have noticed but don’t care – also not a good sign; or C) you are too busy fixing worse issues – a sign that the software is not trustworthy.

I’ll do a follow-up in future blogs on how good senior engineers differ from when they started their journey and how team leads and software leadership differ too.

Credit for the idea to write this blog comes from Tien Vo.