What Makes A Talented Engineer
- Talent, And Top Talent
- Define "Talent"
- Abstraction Building
- Continuous Learning
- Focused Ambition And Drive
- Talent Vs Experience
- Talent Vs Output Over Time
- Product Understanding
- Technology Choices
- Diversity And Versatility
This essay is a the first part of a mini-series on hiring top engineers, a common challenge faced by many companies and in particular startups today. Before we can talk about hiring top engineers though we need to define what a "top engineer" actually means, which is the purpose of this essay.
There are several competing adjectives to "talented" in the context being discussed. One of them is "great". I also like "high functioning", because as we will see soon, engineers in this category eventually have both more depth and more breadth than "standard" engineers. "Top performing" and "10x" are also valid alternatives, keeping in mind that we are discussing performance on a much broader level than a particular assigned task.
Talent, And Top Talent
For readers unfamiilar with the concept of a "10x engineer" I strongly recommend reading Joel Spolsky's timeless essay Hitting the High Notes first.
It is important to clarify the difference between absolute talent level of a particular person and their talent level relative their peers at their particular workplace. Specifically a company saying they want to "hire talented engineers" may mean that they don't want to hire anyone who is less talented than existing employees, but this doesn't say much about how good those existing employees are. Unfortunately it is extremely difficult for most people to distinguish which of two engineers is more talented when they are both more talented than the evaluator; hence, to some extent, all companies are constrained by their existing talent when hiring. However, the goal of this essay is to outline effective strategies for identifying engineers with high absolute talent level.
Merriam-Webster defines "talent" thusly:
1.a: a special often athletic, creative, or artistic aptitude
b: general intelligence or mental power: ability
I think both parts of the definition apply, in that some people are - either genetically or through their upbringing/life-to-date - more talented than others, but improving one's talent is a process that anyone can undertake, and individuals who happen to be talented do not retain their talent by being idle.
What, then, does it mean for one engineer to be "better" than another? I posit that a talented engineer possseses the following three qualities:
- They are able to build effective abstractions;
- They are always learning;
- They have focused ambition and drive.
Note that length of experience is not one of the criteria, nor is technology choice although as we'll see momentarily technology choice is a corollary of one's ability to build abstractions.
Let's look at each of these qualities in depth and then examine some interesting corollaries.
I thought a lot about what separates great engineers from average ones, and I think that ability to build effective abstractions is the hallmark of a talented engineer. These abstractions are things that are taught in schools and described in professional literature. Some examples are:
- Organizing code into functions and modules;
- Object-oriented programming - encapsulating logic and data relating to a real-world concept in a class which is then operated on as a single entity;
- Design patterns - structuring a body of code in such a way that it can be referred to with a single word or phrase: "It's a factory";
- Programming languages - at the highest levels of engineering talent people invent programming languages which provide tools for solving classes of problems that were previously cumbersome or impossible to deal with, like Go and Erlang concurrency or Lisp's treatment of code like data;
- Interfaces and the idea that one interface can have multiple independent implementations which are interchangeable.
The common thread of all programming abstractions is taking a relatively large body of code and using it as a primitive, indivisible unit - be that a function call or a concurrency primitive. In a typical application there are many opportunities to create abstractions like that. For example, the following are all abstarctions found in modern Ruby on Rails applications:
- Single-statement definition of associations (
- Default scope;
- S3 upload as an option to the file upload field type
has_attached_file :image, storage: :s3);
- Class instances as validators encapsulating complex logic;
- Presenters encapsulating fields exposed via API endpoints
In case of Ruby specifically, these abstractions may be built within a run-of-the-mill application, and a complex application will almost certainly have several homegrown abstractions like this in it. Talented engineers can spot the need for such abstractions and have the skill to implement them in a way that makes them easy to use, thus creating an effective abstraction.
Early in my career I was of the opinion that everyone was learning and improving all the time. Over the last few years it has become apparent to me that this is very much not the case. Most people, including software engineers, have no problem learning when they feel they need to; the issue is that many people at some point in their engineering carreer feel that they know enough and stop feeling the need to learn more. Steve Yegge has an excellent essay going into much more detail on the topic of continuous learning, or lack thereof in most engineers, titled being the averagest.
Continuous learning is what enables talented engineers to stay talented throughout their careers. Talented engineers are always curious about new technology, not necessarily because such technology is popular or in demand but because they are always looking to gain a new skill or a new perspective on something they already know. But technology in the sense of frameworks and programming languages is only one area of learning - an engineer may decide to broaden their product management skills, learn how to be an effective engineering manager, or perhaps learn how to sell a product successfully. Talented engineers expand both their breadth and depth of knowledge and ability over time.
Focused Ambition And Drive
In order to achieve something, one must first desire that thing. But desiring alone is not enough - non-trivial achievements require non-trivial effort to attain them. Hence ambition and drive separate engineers that can be great from engineers that are great.
The "focused" part is important for practical considerations, when discussing software engineers in typical companies. Most companies must turn a profit, typically by selling some product or service, to continue existing, and aligning with the company's needs to generate profit makes an engineer more practically useful.
I think all other attributes of top performing engineers are natural consequences of such engineers demonstrating the three pillars just described. This is a nice sampling of how people define great engineers; to reflect on some of the mentioned attributes:
- Good communicator - ability to explain oneself to varying audiences in a sufficiently detailed yet accessible manner is a skill, and this skill can be learned and practiced.
- Likes debugging - debugging is required to ship and support code in production, therefore engineers driven to help the company be commercially successful do not shy away from debugging. Effective debugging is also a skill which can be learned.
- Balancing pragmatism and perfectionism - an engineer with an understanding of product lifecycle, as well as business stages of a company, will recognize when a prototype is needed and when a system is built to underlie the backbone of the company's operations. Both rapid prototyping and stable, long term architecture design are - you guessed it - learnable skills.
Let's now look at some interesting corollaries and misconceptions regarding engineering talent and performance.
Talent Vs Experience
A particularly important distinction to make is that between talent and length of experience. It is easy to conflate length of experience with seniority and subsequently talent, but I have worked with enough engineers to confidently state that, because many of them choose to stop learning at some point in their careers, they also stop increasing their talent level at that point. Any additional length of experience does not make them better engineers as they simply repeat solutions they are already capable of building, or have built, but they often cannot come up with new solutions and have difficulty absorbing new concepts. As technology is always moving forward, such engineers effectively lose their talent level over time.
Similarly, an engineer without much experience can nonetheless be talented if they exhibit the three listed qualities. This does not mean that all "talented" engineers are equal; what it does mean is a talented fresh-out-of-college engineer, for example, will handily outperform a fresh-out-of-college engineer who is not talented, because the former will learn the company's software and systems on their own initiative while the latter will be constantly asking more experienced engineers questions, and may not produce if answers to these questions are not forthcoming.
Talent Vs Output Over Time
As already established, talented engineers are always learning, which constantly improves their output in terms of both quantity and quality. Engineers with substantial length of experience who lack one of the three pillars may have good output but their output in terms of both quantity and quality tends to stay constant over time. The practical consequence of this is a less experienced but more talented engineer will initially produce less than a more experienced but less talented one, but given time the more talented engineer will overtake the less talented engineer in actual production. Depending on the talent gap, the required time period for this to happen may be quite short indeed.
In an early draft of this essay I specifically mentioned product understanding as one of the three pillars. The current version specifies "focused ambition and drive" instead. I think that product knowledge and appreciation is a natural area of interest for talented engineers working in product-centric organizations, hence emphasizing product is unnecessary.
I can also imagine that engineers working on, say, stock trading algorithms have a different definition of "product" than I do working for B2B and B2C startups; however, I expect a talented engineer working for a bank to learn about how markets and trading works.
Some programming languages offer more powerful abstraction building tools than others. It is my impression that Lisp offered very powerful abstraction building tools, although the abstractions themselves were not necessarily easy to use and the language was not too practical. Ruby is a language which is quite practical (although it does have limitations) and offers excellent abstraction building facilities. The biggest reason why I like Ruby is the language allows me to express my designs in a way that resembles what they look like in my head. Python, for example, is considered by many to be fairly equivalent to Ruby, but Python's abstraction building facilities are much more limited which results in plain inability to create many of the designs possible in Ruby.
Ruby does have its weaknesses, of which memory consumption, runtime performance and concurrency per memory used are the biggest in my mind. This is why I am excited for languages such as Go which is built to operate in a very different performance envelope and as a result does not have the facilities that Ruby has. However, I find Go to have better abstraction building facilities than, say, C or Java, and as a result I favor Go over C and Java.
Diversity And Versatility
As I mentioned, talented engineers will tend to expand their skills in both breadth and depth. Practically speaking this means that an engineer who is both experienced and talented should have a broad knowledge base with good depth in more than one area that they know or worked in. These engineers are often quick to think on their feet about various engineering-related challenges, because they probably pondered these or similar questions to some extent already. Talented engineers, depending on their interests, can be hidden designers, product managers, system administrators and so on.