If your reading this blog, and used twitter in the past few days, you have probably already seen this tweet, or some of the replies coming through from the community:

10x 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?

— Shekhar Kirani (@skirani) July 11, 2019

As a developer who tries to be good at their job, I have thoughts on this. As a Human, I like to be heard. (Note that being heard is not the same thing as being agreed with, or being right.) So here I am giving my opinion on this idea of a 10x developer, and specifically these "10 signs" put up online.

I like the idea that there are no 10x people, instead, you can strive to produce 10x teams.

1. Meetings

A lot of people don't like meetings. But unfortunately, communication is a big part of effective teams and businesses. While it is true that some people love meetings, and some meetings don't hold productivity, the key here is communication. If you can find an effective means of communication within a team that works, that is most important. Having a team full of people that don't have meetings doesn't make a 10x team. If meetings are causing you or your team problems, it is work looking at other strategies for effective communication. There are alternatives out there.

2. Office Hours

"Nine to Five" is such an old fashioned idea these days. Not only do some countries have alternative ideas like 4 day weeks, long lunch hours, "flexitime", but more and more business work across locations and across timezones. We are asking people to work outside these hours for various reasons already, so why not some give and take here?

Most people would love flexible work hours. It turns out that if people can work around their own schedule, they put their best work forward when they are present. I would much rather have someone contribute 100% at 9 pm at night because their kids are in bed and they can concentrate rather than pay them to sit at their desk for several hours texting and calling their family. Just a thought.

We are so fortunate that in our industry is so capable and adjustable to different working hours that it is a shame not to support this. It is not that "10x developers are the people who like this", it is actually that most employees want this, and it can be done.

3. Screen colour and worn keyboards

If I saw a sports star on the field/pitch/court wearing badly worn shoes, I wouldn't think "This is a superstar", I would probably think "he isn't paid enough".

Why are you letting your developers use worn-out equipment? Buying the required hardware and software is such an important thing, just do it! In all seriousness, though, giving staff the right tools to get their job done is always a good idea.

There is an interesting dichotomy with custom technical tools as well. If you have one developer that goes against the grain of the team with customisation, then it both makes it harder for them to use other machines (e.g. during pairing/mobbing) and for others to use theirs. There is some efficiency to using the out of the box defaults too. You can get up and running faster, and waste less time doing customisations every time you refresh your machine or change jobs and get new hardware.

Also, if you have to have everything customised your own way, you won't be able to acclimatise to new situations, new tools, new teams. Not someone you want to add to your team.

4. Good memory

One my big comparisons between my generation and the one before me (that is the one with the access to Google, but not access to iPads) was that at school we were no longer taught to memorise and recall information. Instead, we were taught, and learned, the importance of finding and referencing information. There is too much information for us all to hold in our heads. knowing where to look and what to look for is far more important that memorised information for a technology that will be obsolete in 3 years (if you are lucky), let alone memorising a dozen of them over time.

Yes, it is great to get people who know the domain really well, and for some people, it really is a skill. But people can't know what they haven't seen yet, and new hires always start as a blank slate. Not to mention tomorrow will bring a new set of libraries, applications and services that need to be learned and understood.

Scott Hanselman talks of the experience-groundhog-day scenario.

Do you have 10 years’ experience, or the same year 10 times? https://t.co/LhIeWiWl3H

— Scott Hanselman (@shanselman) May 29, 2018

5. Full Stack

Don't you love buzz words? FullStack. A full-stack would be from the HTML/CSS/js to the backend code, to the database. But it is also understanding how the TCP/HTTP layer works with packets and routing. How does your platform infrastructure run, do you manage and patch the servers? Database backups and data security, not to mention how the hardware scales, can you write the assembly to work with arm processors too?

Jack of all trades, master of none. That is a saying that acknowledges you are spread too thin. You can't be an expert in everything, so instead, you can hire an expert in each thing. Yes, you want everyone to be a generalist, but make sure you have coverage with all of the specialists, too.

I can't say I've met too many people who can design and build an amazing user experience, and also optimise a large scale database, and run a datacentre. Oh and also works well with others...

6. Wait, WAT?

This one I just have to quote it in two parts:

10x engineers can convert "thought" into "code" in their mind and write it in an iterative fashion.

Just for a second, imagine with me, that you could replace the words "10x engineer" with "a developer". Crazy idea, but it might actually work.

Given a product feature, they can write that entire feature in one or two sittings of 4 to 6 hours with a caffeinated drink without distraction.

We all have good days where we fire on all cylinders. Or a task or feature fits into just the right hole in a system. Cherish the days when it happens, but realise its more about the stars aligning and less about the ability of your developer. We are all capable of this. But the rest of the time it's just a Monday.

7. Good Memory. Part Deux

We talked about this. Enough said.

8. Learning

This is another one of those things with a dichotomy. If you are always learning something new, you never get to master anything. There is a benefit to having people who are masters, and people who can learn, and people who can teach and share. You need balance both as a developer and person, but also in and within a team. If you don't have this yet, look at hiring the capabilty, but don't use it to rule in or out talented people.

9. Terrible leaders

Yes. I think exactly what you want to do is hire someone who cannot teach how the system works to new staff. That will help you grow. No, not really. The team is only as strong as its weakest point. And the ability to both cover for, and teach and grow newer talent is key to growth and success.

Also, while it is true that some people will be amazing on your team, but will interview poorly, I can't say there is a direct reverse correlation here, either. Sorry.

10.

10x engineers rarely job hunt or move out of the company. They move out because you make their life miserable with the process, meetings, training, and other non-value-added activities. If you come across them, hold on to them. Celebrate them.

So close. This is the first point I almost agree with. Just go ahead and replace "10x engineers" again with "developers", Or even just "employees" will do.

0.1x developers

While there are seeds in here that make for an interesting debate, they have nothing to with "10" or "X". The best summary of the whole situation is this: The scale is off. I think the truth of the matter is that there are developers who might contribute to failings in a team (and some warning signs appear above, under the wrong inversion, though). We can call them the 0.1x developers. They are the ones to truly watch out for.

As founders and employers, you will want to be doing all the right things to attract and keep good talent, and that is more important than going after a mythical creature known as the 10x developer.

What someone needs to do is follow the footsteps of Dylan Beattie's Rockstar programming language and make a language or piece of hardware board and call it "10x". Then we can all be Rockstar Programmers and 10x Engineers.