“As a software engineer, your main contribution to the project isn’t the code that you write”

Your main task is to shape the way that the software is designed, built, and tested, such that all subsystems work well together, and, eventually, run smoothly in production. This requires a bird’s-eye view across the boundaries of the different project phases and a critical attitude towards the processes, architecture, organization and technology that eventually all have an impact on the quality of the software that’s produced. Of course, you’ll spend considerable time coding. That’s the core of software engineering. However, that time will be unproductive if you don’t spend enough time knowledge sharing, setting the standards for design and documentation, and optimizing the toolchain that’s used for CI/CD.

Alt Text

“For a software engineer, the real testing takes place in production”

When we say the real testing takes place in production, we don’t mean to state that the code shouldn’t be properly tested upfront. It goes without saying that strong test automation should be conducted. However, automating these tests can take up a lot of time and money, so it’s important to initially determine the criticality of your application. You simply can’t spend unlimited resources on every application writing test automation. So, it’s important to balance customer cost with customer value and timebox – with your project team and customer – how much time we agree is feasible to spend on automated testing, and how much time we’ll allow for ‘real-life testing’ and quick fixes while in production.

In practice, automated tests can filter out many bugs, but the most complex situations emerge in the wild: when the code runs in production. Consequently, if you’re striving for a high-quality application, you should make sure that you can quickly react to errors when your code runs in production. That’s why a DevOps approach is essential. Through constant monitoring and logging of incoming data, unexpected behaviors can be spotted early on and the team can act on these before they become a real problem. DevOps allows for short development and test cycles, making your applications flexible for change and improvement. In other words: if your way of working is agile and you’re prepared for rapid change cycles, testing in production can be an agreed optimal way to go.

“As a software engineer, your job is to make yourself redundant”

This means that the work you deliver should have such quality that future work is either automated away or transferable to a colleague at any time. Of course, it sounds controversial to work in a way that could potentially leave you without any work but this also means your employer and/or customer can be flexible in using your skills in different projects and solutions. Any sudden need for your expertise in another project, any shifting in priorities – which moves current work to the backlog – or even any sudden leave or absence shouldn’t prevent a colleague from picking up where you left off.

What does this mean for your daily activities? Besides communicating and documenting the decisions you make, the software you deliver should be thoughtfully and understandably designed and crafted. It should be clearly written and documented, it should have a consistent style, formatting and syntax, and it should be properly structured and versioned. In short: this means writing well-documented and easily readable code. The better you become at being redundant, the more valuable you become to your employer or your customer.