Forgive me if I am a little late to the party. I am getting caught up on my podcasts. A few times in the past week, I have heard a series of tweets mentioned that speak of the virtues of the 10x engineer. It goes on to outline eleven ways to identify a 10 engineer. It goes on to say that you should know who they are, how productive they are and reward them.
10x engineers— Shekhar Kirani (@skirani) July 11, 2019
Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.
OK, here is a tough question.
How do you spot a 10x engineer?
This series of tweets have created a storm of negative responses. Many people express that that these are exactly the types of people that you don’t want in your workplace. I want to take a few minutes and share my thoughts on this. Not because I want to pile on, but because the tweets describe someone who, at one time, I thought I wanted to be.
1) 10x engineers hate meetings
I am going to give the benefit of the doubt on this one as I don’t know a whole lot of people that love meetings. I have attended my fair share of meetings that should have been a phone call or an email.
At the same time, I am not paid to live in a box and cut myself off from my peers. A well run meeting can be productive and, dare I say, enjoyable. The people who are not present because they can’t tolerate the idea of being in a meeting that bring it down.
It is fair to say that meetings should be executed well, this is an art and some meetings are better than others. It is better to live in, and enjoy, the moment than be upset by poorly executed meeting. There could be an opportinuty to make it better for everyone.
2) They keep irregular hours
I have a confession to make. I can become obsessed with solving a problem, finding a solution or finishing a feature. This can lead to me working for extended hours, on weekends or thinking about a problem when I’m shopping.
Does this improve my long term productivity? Maybe. I can geek out on something in the short term and make a lot of progress or learn a lot about a topic. Sadly, it is not sustainable and any benefits are likely to even out in the long run.
The author goes on to talk about not participating in meetings, coming into the office late, and working after hours. These aren’t the traits of someone who is pushing themselves to be a better developer. These are the traits of someone who lacks the discipline to wake up in the morning and participate.
There was a time when I thought that this was acceptable, but now I will pass on this one as well.
3) Their laptop uses a dark theme
3. 10x engineers laptop screen background color is typically black (they always change defaults). Their keyboard keys such as i, f, x are usually worn out than of a, s, and e (email senders).— Shekhar Kirani (@skirani) July 11, 2019
This one is pretty silly. Sure, I use a dark theme from time to time. Most people generally will try out different themes and tools to try and find the right fit for them. Some people like to write on the cream colored pages of a Moleskine, others prefer their phone or a tablet. Some like to wear button up shirts with bright colors and others like dark t-shirts. Do any of these choices demonstrate their productivity as an engineer? No.
How about worn out keys on a keyboard? Again, no.
4) They know every line of code that has gone into production
This one seems excessive, but again I will give the benefit of the doubt. When taken with the last identifier (rarely leave the company), this describes someone who has experience with the technology and the codebase. They have run into many issues with the logic, data, and application before and are able to draw from this experience.
That’s not magic and it isn’t a matter of knowing every line of code. It means that they have experience with the product. Is it good to appreciate developers who can fix issues and have experience? Sure.
5) Full stack engineers, except for the UI bit
It’s once again confession time. I’m pretty awful with UI. I can hack something together, but I wouldn’t consider myself to be very good with it. Often, I am in awe of what a good designer or UI developer can do. I prefer to work with the rest of the stack. Does that make me a better or worse developer? No.
I like to have some experience with all different parts of a system but I am best with data and backend. The idea that a UI developer is somehow not as important or not as good is absurd. I hope to be part of a team that has a good UI developer, we will deliver a better product.
6) Turn “thought” into “code”
I am confused by this one. I think he’s trying to say that the 10x engineer will emit code that is perfect for any given situation. An experienced engineer will be able to sit down and write good code. But the implications go beyond this.
This idea of sitting down and writing perfect code flies in the face of [number ten, (no hacking)](). Productive engineers write simple code and tests. Afterwards they refine and refactor as needed. Maybe that is what is meant here, maybe not.
7) Rarely look at the documentation
7. 10x engineers rarely look at help documentation of classes or methods. They know it in memory and can recall from memory. They write code at the same ease as writing English. No breaks, no pauce, just type.— Shekhar Kirani (@skirani) July 11, 2019
Most good developers that I’ve known read a lot of code and documentation. They also write a lot of code and documentation.
The more experience you have, the less you will need to reference documentation. Let’s not go overboard here. 10x engineers are pushing themselves to learn more and share what they learn. This involves looking at and making documentation.
8) Always learning new frameworks
I can agree with this one. Great developers are always learning new things. These are not always frameworks, they could be new concepts, languages, or soft skills.
No engineer knows all that there is to know.
9) Poor mentors
9. 10x engineers are poor mentors as they can't teach others on what to do OR parcel the work. They always think "It takes too long to teach or discuss with others, I would rather do it myself." They are also poor interviewers.— Shekhar Kirani (@skirani) July 11, 2019
This is the tweet that I disagree with the most. Mentoring and sharing what you know is one of the most important and rewarding aspects of coding.
A poor mentor that writes a large part of a codebase should be a red flag to leadership. This is how to rack up huge amounts of technical debt.
10) They don’t hack things
I read this as, “10x engineers commit production ready code and practice good coding hygiene”. I agree with this.
11) Rarely job hunt or leave the company
I don’t have much of an opinion on this one. I’ve been working for the same company for a long time. Has that been beneficial to my career or my productivity? I can’t say. Have I missed out on opportunities elsewhere? Perhaps.
I wouldn’t say that this is a trait that determines how useful or productive someone is.
This series of tweets has brought a lot of attention to Shekhar Kirani over the past month. He likely didn’t expect to have such an overwhelming response to them, especially such a negative one. There are some things in the list that are good traits. There are some things that are not relevant or toxic. Twitter has been quick to jump on these.
To me, this series of tweets highlights the changes in my outlook, developed over time. There was a time when I believed that someone could isolate themselves and pull perfect code out of the ether. There was a time when I felt that I was undervalued and unappreciated because I tended to keep to myself. There was a time when I thought that software had value without the people who develop and use it.
This way of thinking was short sighted and naive.
Are there any things that you used to believe that have changed over time? Leave me your thoughts below.