The irresponsible sale of new features favors pressure in software development. This increases health risks for developers.
Many programmers, and especially good ones, can do just about anything, they say. And shouldering projects alone is the daily bread of many developers. Everything should be done to make the often much too hard work of programmers easier and to reduce the much too high pressure. This requires automated deployments and tests. Everything else leads straight to technical and health problems. Unfortunately, companies often save on the health and quality of life of their developers.
One thing is clear: Good and young developers, between 20 and 30, want to get things moving, take responsibility and get most of the tickets through. They want to get the recognition of the senior developers. But at some point in their lives, this is postponed. You’d rather work efficiently and spend less time at your desk. To be lazy in a smart way, by writing and using something that does the work for you, and above all, delivering reliably – without bugs. Otherwise, inefficient workflows and ever-increasing pressure will make you tired and sick in the long run.
That’s why employers who insist on outdated, non-standard applications for “reasons of the economy” or who leave automated testing out of the equation and thus put the health of their employees at risk should be turned their backs. It may even be possible to help them in this way and get them to change course one day after all – by making the constant migration of employees to insight and self-reflection.
Transparent work through tickets is a must
Tickets do not protect against chaotic working conditions and high pressure. But they do depict workloads transparently. So you can see what is currently being done and what still has to be done. This sounds banal and self-evident, but it is far from being the general state of affairs. Because far too many small things are simply not captured in projects, and programmers who focus on themselves run the risk of being crushed under the increasing load.
If there is no insight here and a project can be saved by hook or crook, then help is needed to save oneself. Developers should demand transparent workloads and not always get involved in deadlines that are hard to meet. It’s also important to say no when something simply can’t be done in the time planned “from above” without causing major collateral damage to quality and health. Especially since often not even that much happens if you don’t deliver on time.
Because that is exactly the problem. Because you don’t say no, you end up being burned out. Developers are in demand and worth a lot. They must not always be at the back of the process chain and decisions. Customers must not simply say that something has to be ready in half the time and then everyone cuddles up because otherwise, another agency will do it.
Another problem is that things like maintenance and infrastructure are not paid for. Yes, entire deployments are sometimes not billed and automated tests are not paid for.
Legacy Fighter: Refactoring – everything else is pointless
Agile programmers often say, just for fun, that in the age of microservices any method with more than one line of code is already legacy. At least this has a true core: Less code is more. However, readability must not be neglected under any circumstances.
Nevertheless, code must be improved again and again. There are two main reasons for this: Firstly, because you can’t deliver perfect code off the cuff. In the first steps – and even if you have planned your code – you first try to create functionality according to the principle “try, error, debug”. On the other hand, there are external influences: form on the day, the mood in the office, pressure and last but not least personal motivation. That’s why a second look is important, and this is best done in a team. The goal is to tidy up and improve code. Then it becomes good, readable and maintainable.
