If you are working as a software engineer, chances are that you are fixing bugs and adding features to a system that was conceived years before you joined.
Every successful system grows beyond the original design. Whatever the creators imagined, changes to requirements and technology soon outgrow what the initial team can keep up with.
What makes software development hard is not reading or writing a screen or two of code. You learn that in any programming course. The challenge comes from managing complexity as the system grows.
Hence, a crucial skill for a software engineer to be able to get into a complex system quickly and to make changes that solve more problems than they create. You need to get a level of understanding where you can make changes with confidence.
Seeing the big picture
What you see when you look at a system is the user interface and one or two screens of code at a time. If you are lucky, you may also find documentation of selected parts of the system. It may even be correct and only slightly outdated. You may also find tests. Sometimes even tests that runs and actually tests business logic.
There is a whole lot of the system you don’t see. It’s like navigating in a large warehouse with only a flashlight, trying to find the aisle and shelf where the box you are looking for today is located.
You are trying to create a mental map of the system based on the pieces of evidence you pick up as you solve specific tasks.
What are the major components of the system right now? How do they interact? Is this how we want it to be or can it be improved? If yes, what are the changes that will safely and most efficiently take the code base there?
This is the big picture view of the system that allows you to navigate quickly and make changes safely.
One commit at a time
As your understanding of the system grows, you should express your hard earned insight in the source code, documentation and tests. With every commit, I improve the code base and make it easier for the next who comes along. This is the Kaizen approach: Improvement through many small and safe steps, rather than through few large and risky changes.
You need to do this with a dialogue within the team. Where are we taking the code base? What conventions and patterns do we follow when making changes? What are our long term goals? It can be alignment over coffee talks and code reviews, it doesn’t have to be a manifesto.
Leading change
At my latest assignment, I worked hands-on cleaning up code pulling specific bugs and features. As my understanding of the system (and the business domain) grew, I documented my understanding in an AS-IS description of the system. This then formed the starting point of a technical roadmap that also formulated the desired TO-BE state, and the steps and priorities to get there.
To bring the team on board, I held sessions where I explained best practices for coding, testing and writing documentation (see How to test microservices). I anchored the presentations by using specific examples from our daily work. Making sure not only to explain how to do it, but also why and what alternatives could be considered and when.
A complex software system is never finished. There is always something you want to change. For your team to be able to keep up with business requirements and technical evolution, you must have someone who sees the big picture and can lead the dialogue with the team about where to take the system. To make sure your system stays relevant also beyond the next release.
Available for new assignments
I'm an IT professional with 20 years of experience leading teams, designing software and writing code. I'm available for on site work in the Stockholm region or remote. Reach out on LinkedIn.