Being a developer doesn’t mean that you’ll be writing code all day. It doesn’t even mean you are sitting in front of a screen all the time. Here is what I typically do in a workweek besides coding.
Reading Code
As a software developer, I often read more code than I write. Trying to understand other people’s code can be time-consuming. Good documentation is therefore important. By the way, “other people” can also mean: Myself 2 months ago.
Planning/Architecture
Good planning is half the battle: Much of my working time is dedicated to structuring complex architectures, researching new technology products, and planning work within the team. This planning includes mentally capturing all requirements to identify possible borderline cases. Of course, not everything can always be thought of, but the more effort you put into planning, the fewer surprises there will be later.
For all decisions I make regarding architecture, I try to design in such a way that they can be easily changed in case requirements change. Some decisions in this regard are, of course, final. It is rare, for example, to change the programming language entirely within a project (although I have seen that happen too). The smaller the components, the easier they are to replace.
Troubleshooting
Who hasn’t experienced this: Something doesn’t work correctly. Maybe the new version of the corporate firewall prevents the connection to GitHub, or the update of the IDE fails. Or perhaps you just have to help a colleague with such problems. Such problems are annoying, but unfortunately, they happen regularly.
Training and Coaching
In most of my projects, I am not only a software developer but also a trainer. Part of my job is to empower my teammates to write better code. I, therefore, spend a lot of time preparing training materials, doing the training itself and, of course, individual coaching. In some projects, people from completely different disciplines, such as biologists or physicists, write code themselves for the project for the first time. Sometimes, however, teams adapt a new technology that I train.
Integration
As a freelance consultant, I have learned about many different work cultures. Small and young companies often work in an agile way and with cross-functional teams, while in large companies, there are often still visible boundaries between different departments. Whatever the working culture is: When software becomes more complex and teams larger, not everyone in the company can know everything. It, therefore, becomes necessary to discuss the requirements of other departments (for example, the legal department) or their work results (for example, if a company wants to make two different products compatible with each other) and to take them into account in one’s own work. Integration coordination is necessary even within a very small team: just think of frontend and backend as an example.
It gets even more complicated when it comes to research and development. Working in a research department is significantly different from working in a product-driven environment. And, of course, the transformation of research results into a commercial product is an immense effort in terms of communication.
In addition, there is integration work that involves third-party products; for example, when a new database, a new cloud provider, or a new ERP system is to be introduced.
Paperwork
A lot of my working time is spent on paperwork, of course. Accounting issues do not only concern freelance software developers. For example, many companies offer their employees subsidies for home office or further training. Receipts for such expenses have to be collected, of course. But these financial issues are the smaller part for me. Much more often, I have to do paperwork that is legally required by the software development itself. This is the case, for example, when it comes to data protection or industry certifications such as HIPAA for medical devices.
Learning
I decided to devote a fixed part of my working time – on average about one hour per day – to continuing education. During this time, I attend conferences, webinars or work through online courses. Because learning always means trying things out, I still write code, of course, so this point only counts for half.
Interacting
Another fixed part of my working time is spent networking. I do this, for example, by writing this blog, maintaining my Twitter account or getting to know new interesting people through coffee chats.
Drinking Coffee
I love coffee and I do enjoy my coffee breaks. However, I don’t overdo it: 2 cups a day are fine for me.