A twitter storm erupted recently in response to one person’s thread about how to find a 10x engineer . Since I started programming FORTRAN with punched cards back in 1974, was an industrial engineer in the 1980s and now run a software company, I’ve worked with a few people, rightly or wrongly considered to fall into that category. So, I thought I’d weigh in on the original author’s points.
10X Engineers hate meetings
There are only two types of software developers who don’t dislike meetings. New developers don’t mind meetings too much because they have a lot of questions like “who do I talk to if I need access to this repository” or “What version of Unity was used to develop this game I’m supposed to update?” They also have specific questions about why the sound function they wrote is not working and Bob, who wrote similar functions for another game is sitting right there. Another type of developer actually likes meetings because he is complete shit at his job and it gives him an excuse not to be expected to do it.
Every other engineer I have ever met either dislikes meetings or actively hates them. The ones you think don’t dislike meetings are just pretending.
We have a 10-minute meeting every morning at 7 Generation Games. People not in the office drop in online. Everyone complains about it but we do it anyway. Why? Because, for example, I can find out that Adekola actually finished the teacher reports for Making Camp Premium before he left and see an example. Then, I can tell the people in marketing to include that in their discussions with schools. I can also tell one of the developers to take that code and modify it for Tribu Matemática , the Spanish version of Making Camp. In 3 minutes, everyone knows what the reports look like, that they are available and who is working on the next one. This leaves seven minutes for José to ask Bob about the sound function.
10X Engineers have irregular hours and work when other people aren’t around
I can’t think of any software developers who work better when other people are around. Writing code for anything complex requires having a mental model in your head of at least the part you are writing and, hopefully, some of the larger project in which it is used.
I’ve worked with a few people who were hit it out of the park better than anyone else. One definitely was a late night person and preferred to get to work when he got there. However, when crunch time came, he could work 8am to 10pm and code all that time if he had to do it. He wasn’t going to like it, though, who would?
On the other hand, about half of the really top engineers I know – both software and hardware – choose to work 9 to 5, even when telecommuting. The main reason they give is that those hours allow them to spend time with their children or spouse. Contrary to popular belief, the 10x engineers I’ve known tended to be married, although they did seem to get married a little older than the average.
10X Engineers know every line of code that has gone into production
This is just nonsense. I remember when SAS was rewritten in C (yes, I am that old) and hearing that it was something like 3,000,000 lines of code. I am assuming the author meant that these 10x engineers know every line of code WRITTEN BY THEM that has gone into production.
I don’t believe that, either, assuming what he means is that they can recall it immediately and say,
“Yes, in that function beginning on line 683, I pause the audio that’s playing, change the source file to the audio for the next scene, change the image file for the image for the next scene, increment the counter by one and restart the audio”.
If what he means is that they kind of recognize it like that person you met at a conference two years ago and are trying to remember their name, I might faintly agree.
We wrote Spirit Lake: The Game in 2012-2014. NO ONE who worked on that game remembers all of the code in it. I can say this because it was all done by me and The Invisible Developer and he is as good as you’ll ever find.
Here is an experience I share with every software engineer I have ever met, including the very best ones. I look at code and think,
“Who wrote this crap? Please don’t let it be me three years ago.”
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 faster than of a, s, and e (email senders).
They always change the defaults part is true. One thing for sure all of the best engineers I ever met had in common is they like to mess with things. I only knew two people who had black backgrounds – ever. When I have time I’ll have to post about pseudo-10x engineers. Anyway, neither of those guys are anything special unless weirdness is a category.
Most of the best people I know have either pictures of their family or their favorite activity, like soccer or hiking, or a vacation photo as a background. Usually the e key gets worn out first because it is the most common letter in the English language. People usually name directories, datasets and variables something comprehensible.
Is there anything true about a 10x engineer?
Since my 10x merit badge hasn’t come in the mail yet, I don’t have time to address all 10 points from the original thread. There were two points he made that were consistent with my experience.
Most really good engineers aren’t really good interviewers
I could only speculate about why that is true, so I will leave it as that is what I’ve observed. Maybe it’s because they are uncomfortable with exaggeration or with being asked to prove their competence.
10x engineers rarely job hunt
I have found this totally to be true and it makes sense. If you have someone that good in your organization and your management is not made up of complete morons, they are doing all they can to hang on to their best people. Usually, unless they work for morons, people that good are hard to hire away, too, because their current company is doing its best to keep them.
How would I find a 10x engineer?
I wouldn’t, because we are a small company and we can’t afford to pay what someone like that is worth. On rare occasions, we have been super lucky to be able to catch someone great for a short term contract that they just wanted to take for personal reasons.
We find good people and we develop them to be at the top of their field. I think the best way to identify a good software developer in an interview is take a look at their code. Ask them to bring something to the interview and explain how they solved particular problems in the code. Ask why they made the choices they did. If it is a project they know well and are proud of, you’ll get a lot of information. If they say, “I don’t know” a lot, that’s a bad sign. I’ve also found that people who typically “don’t interview well” forget about the interview part, focus on the project and become interested in telling you all about it.