You may have seen a thread circulating around on Twitter recently about "10x engineers". If you haven't, you can read it in all its glory:
Shekhar Kirani @Accel@skirani10x engineers
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?13:02 PM - 11 Jul 2019
The summary of it is, unless you fit some super narrow and stereotypical view of being a developer, you are not a "10x engineer".
Many will say a "10x engineer" doesn't exist as being 10x better at something than someone/most people would be pretty damn hard. Even if the person doesn't literally mean "10x", it is still trying to say there is someone significantly better at everything.
Personally I hate the term "10x engineer". Like "rockstar developer", they are poor descriptions and definitions of what great developers are.
It would be disingenuous to say that all developers are equal. Just a few minutes of looking at different developers on Twitter, I can already see many developers that know a hell of a lot more than I do. That said, talking about this "10x engineer" like they can significantly increase the odds of your business being successful is pretty ridiculous.
Enough about beating down that terrible stereotype of "10x engineer", let's talk about the things that really make great developers (aka the real "10x engineer").
Unless it is some trivially small code base, they don't know every line of code that has gone into production. Sure they can solve a lot of problems by themselves but they know when they are stuck and know when to ask for help.
Nothing is wrong about asking for help, no matter your skill level!
There are times for programming independently and there are times for programming in a team. These developers don't just take a task and run off into a corner to work on it in silo to everyone else. Development beyond the smallest scale requires constant collaboration with a team - whether that be paired programming, code reviews, bouncing ideas, helping with debugging etc.
That isn't to say that a great developer isn't more comfortable working by themselves on certain tasks but large scale development is practically impossible without strong collaboration.
Have you ever asked a colleague for help and they did? Congratulations, they might be a great developer. We might look at documentation or even Stack Overflow for help but sometimes we actually need help from someone who knows our code base. If you're a developer who knows something that could help a colleague, help them!
Being a great developer isn't about being a smart ass, showing off your intellect, disregarding meetings because you're better than those people. Being a great developer is also about being good with the non-technical things. If you're "helping" a colleague by yelling at them and criticising their code, just stop.
This might sound controversial but a great developer isn't going to give you the answers all the time. That might sound in contradiction to #2 and #3 however this isn't meant to hold something over you. A great developer is someone who can give you just enough so you can solve it yourself. These little challenges help make you a better developer and allow you to understand what things you might need to learn more about.
Not to say these developers aren't checking out new tools and languages (they can do whatever they want in that regard) but they do understand new tools aren't magically going to solve every problem.
James Hickey 🇨🇦👨💻@jamesmh_devWe are obsessed with learning about more tools and languages!
If your architecture is bad, you're solving the wrong problems, your client doesn't understand when you try to explain things... then shiny tools don't help.
And these are fundamental to your business' success!18:54 PM - 27 Jun 2019
Stereotypes of programmers aside, why would the time when you program actually make a difference? Program in the middle of the night if you want/are allowed by the company and don't do it if you don't want to. The only reason time should be coming into play is when you've been programming for too long and haven't slept! The actual time of the day doesn't matter unless it affects your team (eg. you work at midnight programming to intentionally avoid everyone).
Same with editor themes, why would a dark theme actually make you better? I'll give you a hint, it doesn't. Dark themes have their purpose but that sure isn't it.
This might be obvious but there was another Twitter thread the previous week talking about programming something complexly like that is a good thing to do. When was making our job and the jobs of our colleagues harder a good thing?
There are definitely times we can end up programming a complex solution like perhaps we don't (yet) fully understand the problem. This can happen on our first attempt at programming the solution, that's when you usually hear people talking about refactoring code or not being "proud" of code they wrote the previous week/month/year.
Unless they truly have written every line of source code themselves from the compiler up through all the business logic, they know it was a team effort. They don't try and take the spotlight from anyone else on the team - they highlight all the contributions that made a project a success.
When a project goes poorly, they don't go ahead and blame everyone. Team projects fail as a team, not as an individual (unless malicious intent). They help the whole team learn from the mistakes and help prevent them happening again.
At the end of the day, these great developers are people you actually enjoying working with. You rock up at work (or remote in) and are happy to be working with such an awesome team.
If you know any developers that sound like this, tell them how awesome they are and how you're happy working with them. 🙂