For many developers, the following topics significantly impact their satisfaction.

Developers are technicians, they should have technical tasks

Unfortunately, daily life for many developers looks completely different. They have to attend meetings where the time spent and knowledge gained are often not an acceptable ratio. Additionally, reports often need to be created or meticulous records of what they spent their time on must be made. From time to time, experienced developers are also asked to attend recruiting interviews. When viewed individually, all of these tasks may certainly be justified. But all in all, they require a considerable amount of time, which leads to lack of time and pressure in development work. These activities should only account for a small part of the working week. The majority of working time should be available for technical tasks, not the other way around.

Developers don’t want to work with outdated technology all the time Developers go to conferences, exchange ideas, and read magazines. They learn about great new technologies and what other developers are working on. To avoid frustration, it’s important to let all developers use new technologies, at least occasionally. There are different strategies for achieving this. For example, when developing microservices architectures or splitting monoliths, you can implement individual services or modules in new technologies. Regardless, it’s important that you don’t run up too much technical debt and regularly modernize application systems that are under maintenance.

Developers should also develop new things, not just maintain existing systems

One corporate strategy that’s still fairly widespread is having new systems be developed by external employees or service providers, as they supposedly have the necessary know-how. Maintenance of existing systems, however, is done by employed developers. Sooner or later, this will lead to dissatisfaction. Understandably, it’s not much fun to only be allowed to extend and repair what others left behind. The creative aspect of software development — creating new architectures and solutions — is almost completely lost for these developers. Basically, this approach only reveals that the company previously neglected to train its own employees. A much better approach is having mixed teams develop new systems. Ideally, these teams should primarily consist of in-house developers, who are supported by external expertise on a selective basis. This means that employed developers are involved from the outset in developing systems that they’ll maintain over a longer period of time. This also results in the best possible knowledge transfer.

Developers should be allowed to choose their own tools

This is especially true for IDEs. If tools like Maven or Gradle are used for builds, ultimately, it’s irrelevant which IDE individual developers use. The widespread objection about licensing costs for certain IDEs, while others are free to use, is too short-sighted. It’s a reason for concern if the employer cannot raise the typically three-digit license costs for IDEs. But what’s more important is the argument that a developer’s working efficiency should be valued much higher. Considering developer labor costs, there are considerable savings if they can work even five to ten percent faster using their preferred IDE than with a competitor’s product. Therefore, it makes little economic sense to save on potential licensing costs.

Developers need fast hardware

That means fast development computers with enough RAM and a fast hard disk. Equipment that slows down due to slow-running builds or tests is ultimately much more expensive. The performance of services that developers use on a daily basis is also very important. These include Git, Maven or Docker repositories, build servers, databases, and the network. If they’re slow or lack stability, developers are unnecessarily slowed down. Once again, once you multiply the number of developers by the number of working days and waiting times, you can incur considerable costs. These costs should instead be invested into improving your infrastructure.