A couple of years ago I was asked by a junior developer if I had any suggestions for techniques they could learn about to improve their productivity. It was a great question, one which I'm really glad I was asked as it showed interest and also got me seriously thinking about how you can improve the productivity of a development team. One of the striking things is how despite it being a very broad topic the best things to learn will be highly dependent on the skills of the individual in question and the projects that they are working on. In many ways in the IT industry the best approaches to improving productivity are related to the best approaches to learning, more so than in any other industry I can think of knowledge is often the biggest barrier to better productivity. In such a fast changing industry learning new skills effectively is a huge asset, being able to efficiently learn improves productivity enormously. Often the trickiest question is figuring out what techniques to learn next. Hopefully after reading this you have an idea of how go about answering that question.

There's a bit of a distinction to be made with bigger picture considerations and specific techniques. The rest of this article will focus more on the techniques side of things. Techniques that provide productivity enhancements have 2 major factors that determine their worth:

1. How much a time/effort the technique will save you when it is used.
2. How often that situation will come up where you can apply that technique.

If you have a situation where 1 and 2 simultaneously apply then you really should strongly consider prioritizing learning more about it. Any time something will save a lot of time and comes up frequently it's often going to be very valuable to your career to learn more. More often though you get situations where the product of 1 and 2 are good enough to justify the time it takes to learn.

Some things come up infrequently but save enormous amounts of time and effort when they do come up, for example being able to use git to recover from a catastrophic mistake in a repository, large reward but infrequent. More frequent but lower reward might be general proficiency with your operating system or using a search and replace to change identical strings in a document as opposed to manually finding then copy and pasting. A more sophisticated version of that might be finding based on a regex.

Possibly the biggest wins in the high frequency category are the category of techniques that dramatically reduce the feedback loop time. Things like running a linter or setting up good error messages or a continuous integrations setup all have large impact because they are very frequent tasks and getting any savings on things you do all the time can have a large impact.

If we are prioritizing what we are learning we also have to consider how long the technique will take to learn. Sometimes we won't have a good idea of how long something will take to learn before we embark on learning it. If techniques take an inordinate amount of time to learn then the trade-off is not so good, it might actually decrease our overall productivity. Good mentoring is worth a lot in these situations as a good mentor can help you estimate the effort better and perhaps show you some sensible paths towards efficiently learning the material. Having a variety of smaller learning tasks on hand is often useful because those tasks are less daunting and are easier to slot in around other commitments. I actually explicitly keep track of things I want to learn more about so I don't forget.

Then some things take substantial time investment. For example learning how to use a more powerful IDE or text editor might end up saving a very large amount of time over the course of the career of a developer. However those returns will take some time to show through so people can get discouraged and not want to outlay the time needed to learn a technique. However learning the technique might save many multiples of the time lost by doing it the slow way, sometimes this can be tricky in from an organizational point of view. As someone I worked with used to say "the biggest threat to efficiency is the "good enough" solution". I remember one group wasting an hour every day doing an error prone manual process for builds because "it used to take a day before and it's good enough now", this same build could have been fully automated and taken 1 minute to run with far fewer possibilities of mistakes being made. Along with the understanding of the techniques involved a slightly longer term view might have identified the immense savings available there. From an organizational point of view you need to think about how often your developers are spending on things that could be improved and then weighing this up vs the time it takes to learn those things. This XKCD comic perfectly sums up that situation:

By having honest discussions with your developers about ways in which they can improve their skills in such a way that benefits the current projects you can get a really good win-win where people get a chance to learn and improve their careers while providing more value to the organization at the same time. These learning opportunities will also really help the morale of the more skilled and enthusiastic developers which in turn will help overall productivity. When people are really engaged they just do better overall.

Here's a few suggestions for potential productivity gains:

• Learning a version control system to the point where it is second nature to do the basic commands in the workflow
• Learning how to use your IDE well
• Automating builds
• Automating deployments
• Automating anything that's really tedious (bonus points if you hate doing it)
• Setting up and using a linter system (Especially if using dynamic languages)
• Learning about how to use a continuous integration system, or how to set it up if you aren't using one
• Improving typing speed
• Improving your command line efficiency, for example I was pair programming with someone once and I noticed they weren't aware of tab-completion, pointing this out to them both saved enormous amounts of time and also made their day!

Some of these are very general. There are many more specific skills as well but the more specific a skill the more the value will depend on your industry and your projects. Have a think about what would help your organization and your projects.