10x Your Developers

Every company in the world wants better software and more software. We all want to be two projects ahead instead of one project behind. We want to free up 20% of our developers’ time for R&D projects, or to reimplement that-old-system or to rewrite the customer dashboard. And I just read that we could tie Hadoop into our analytics platform but… none of the team is free for 6 months.

Developer productivity, image by the cool dudes at Monkey User.

What we all want are the fabled 10x developers who can churn through development work faster, with more focus and with higher quality than average developers. That’s why they command huge salaries, offices with slides in, foosball tables and office dogs. Some of them may be prima donnas but I couldn’t comment.

But there’s a secret of 10x developers who, like the Unicorns, seem to live in a world of productivity several standard deviations above the average. There is a way of increasing your software productivity without spending the 10x rates, changing your business model to a photo sharing app or moving your office to San Francisco and causing your costs to quintuple. In short, there is a 10x dev hack.

But this isn’t what most companies do to improve software quality. The first steps in solving software quality are usually process, framework or people shuffling.

The process fix involves shifting from waterfall to agile, or scrum. Or tweaking the scrum process so the daily standups don’t take up too much time. Someone will find a new project management app which perfectly fits your scrum methodology. These often help, but they aren’t the biggest fix.

Or someone finds a new framework which solves the big problem of the last project, or helps us inject a new buzzword into the marketing material. Frameworks help. Sometimes. But they don’t solve the biggest problem either.

Or they get new people on the team. This is hard to argue around because if you get the right people on the project, the project will improve. But that’s not a fix; it’s tautology.

In fact, in our imaginary scenario (which is entirely real for most companies, and probably yours) we can’t change the process (it’s too late), the framework (the application is too big) or the people (recruitment takes forever). These are our fixed costs and constraints. Is there still a fix? Yes.

The fix is found by looking at what developers spend most of their time doing to improve software quality: finding information and debugging. If you can improve this area, you’ll make a difference, dramatically increasing the features your team can shift.

10x the tools to 10x the developers

Many companies don’t see a strategic relationship between the tools the developers employ and their ability to ship high quality, low defect software rapidly. But if you look at what developers spend their time doing, most of it is spent on information gathering to answer either “what happened earlier?” or “what is happening now?”.

If they aren’t actively finding the information in logs, databases and reports, they are putting in place information to answer “what happened earlier?” or “what is happening now?”.

This activity looks a lot like what a developer does, but it’s not actually work. This is patching-over-mistakes work. Developers spend hours understanding the problem, mentally visualising the system, hypothesising the cause and then working out where in the system the answer will be.

Again, this looks like work but it’s actually programming busywork. You need to do everything you can to kill it because it can infect a team’s morale, the project’s progress, the product’s quality and the company’s performance. Companies who recognise this are at a huge advantage because they step out of the stream of reactive bug-fixing and keeping their head just above the water, and move into longer term strategic work.

Programming in movies vs real-life. Original

Without the right tools, developers spend a lot of time context-switching. They jump from one task to another, bringing the status of the new task from their memory and shifting from the productive “flow” state to the less productive context-switch state. The flow state is something 10x devs and companies guard jealously.

In order to minimise the time spent wondering about what’s going on in the software, developers need to use a whole spectrum of tools, including static and dynamic analysis tools, advanced logging processes, and shit hot debuggers. They need to be able to minimise the time spent wondering did we log that? or will we know this value?

This allows the developers to write code rapidly, ship it, deploy it to production, and then to investigate any problems that arise without having to write complex log gathering scripts, or recreate the issue which key customers are complaining about. This really is a dream for developers and product strategists alike; everyone hates stepping back into projects which you thought were done instead of working on future-facing – aka “fun” – work.

10x developers are not made of adamantium, nor do their brains operate that differently. But they do spend more time on creative work rather than busywork. Having all the right tools across the team cements the team’s ability to work as quickly as possible, and shift quality software rapidly.