Do you regret becoming a developer yet?
If I asked a room full of seasoned developers why they chose their profession, I bet I would hear things like “I enjoy writing code,” “I enjoy problem-solving,” “I like building new products.” In the early days, I suspect software development was just what they hoped for: spending time fixing the code, adding new features, and being proud of their accomplishments.
Back then, it was easy. You were responsible for the code you produced; nothing more, nothing less. But since then, things have changed. Think about it: how much time do you spend doing things you enjoy versus things you have to do?
The Rise of Targets
Modern software development requires you to keep track of and satisfy many targets that are often non-functional and therefore require more bandwidth to manage. Where have all these non-functional requirements come from? You need to ensure that your code meets quality bars, security criteria, performance demands, reliability and scalability… the list goes on and on. This means that you gradually spend less and less time writing code.
Developer Responsibility Shifts Left
Everyone in the industry talks about shift left. The earlier in the cycle that we find issues, the cheaper they are to fix. What The Shift Left in Testing Means shows that more people can become involved in the early specification, design and implementation of a new feature. But when this approach is introduced, the thing that isn’t talked about is that we have shifted responsibility left to the developer, both in ensuring their code meets more requirements and in managing the extra people involved at an earlier stage.
Everyone Has an Opinion
In addition to the added responsibility of shifting the SDLC onto developers, there’s also a lot more scrutiny of every step. There have been many advances in tooling to help developers. The rise of CI/CD means that you get early feedback on the quality of your code, and the integration of tools that scan your code in your pipeline mean that many metrics can be provided for each of your merge requests. You could even employ a full-time development team to provide a dashboard of these metrics.
The result is that you can write some code, and as soon as you go through the process of getting it reviewed, both you and your manager can see-in great detail-all the ways that your code falls short. Suddenly, development has become not an artform, but a conveyor belt of ways to ensure we hit our KPIs.
Get back to the aspects of coding that you love
Before you get too depressed with the current state of the world, there is help at hand. The next generation of tools for developer productivity use advanced core engines built with AI. This sounds very impressive, but what does this mean for the developer? Put simply, these tools are not interested in saying “Your code sucks.” They are more interested in saying “Hey, look at this suggestion! It will make your code better.”
For example, AI for Code (used in Diffblue Cover) will take away the boredom of writing unit tests from scratch, so you can get a good base of tests that will help you hit targets and focus on the more interesting parts of your job.
In the wise words of Martin Fowler:
“Imperfect tests, run frequently, are much better than perfect tests that are never written at all.”
Why should you have to do more than think about what you want to test, e.g. which values make sense? After all, if we didn’t want any efficiency gains, we would all be programming in assembly language.
Software development as a profession might have its low points, but the capabilities of new tools can help you get back to the aspects of it that attracted you to the job in the first place.
