Skip to content

How I Work as a Software Engineer

Learning is very big part of software development because technology advances very rapidly. Swift changes create new knowledge to acquire though we also have a lot to learn anyway. As a result, we constantly try to learn software development through books, articles, posts, conferences and videos. We all want to find out what are the best ways to do our job. Nevertheless, applying theory to practice isn’t that easy. I’ve been trying to apply many of modern or fundamental methodologies to my daily job. In this post, I actually like to share how I have adopted these methodologies to a normal working day. This post is meant to be updated over the years.

As I’m describing my day, let’s start with the morning. I first look at a bunch of graphs or dashboards. These charts simply show me everything works as expected for the system/s my team own. You might wonder why I don’t have alarms for anomalies. I have those alarms but these charts are a high-level view which may not be captured through alarms. For example: the relative drop in 3 consecutive days or unexpected increase in the last few days. If something seems to be off the road, I quickly try to confirm whether it’s a real problem or not. If it’s a real problem, then I dive into the rabbit hole. This shouldn’t hopefully happen too often. After I’m in the safe zone, I go through e-mails to find out anything surprising or urgent. The next thing I do is planning.

I mostly do a simple planning for my day. Daily planning means looking at which tasks I have and re-order them according to their prioritisation. Depending on the environment, you might also want to do this with your team. Sometimes, I also do some broader planning like 2 weeks, month, quarter or even a year. I try to divide all planning work into days otherwise they have the snowball effect. After all, the planning work results in either planning board or roadmap along with some reference documents. I keep roadmap and planning board separately. The roadmap is big boxes over a quarter or half a year whereas the planning board is detailed tasks over next two weeks or a month. The roadmap makes easy to show what’s the direction of system/s to management. On the other hand, the planning board shows current status for developers. The next thing is coding, YAY!

Coding starts with designing and designing it well. The design phase for me consists of doing some board work with pen and understanding what and how something needs to be done. I tend to ignore problems up until they become real(YAGNI). It doesn’t mean that we don’t consider near future or long-term design choices. I generally write up everything and share with my teammates and get feedback on my design. In certain cases, I need to refactor the design and consider my options. Another aspect is to review other’s design. It’s generally harder to review as you need to find and possibly suggest changes. Later, when the design is ready, I start thinking of implementation. Applying pre-designed code is easy but it also depends on the level of details. I generally postpone details like class design to implementation. Yet, I still do class level design if I’m changing the core of the system. After the design, I write the code per class and with its unit tests. I generally follow a bottom-up approach. I implement from least dependent class to the most dependent class. Once I’m done with implementation, I run smoke tests if we have any and then add a new one. Finally, I send a code review request along with the docs and necessary reports like coverage. Obviously, I send small reviews without docs and minimal explanation.

Code review process is very decisive for code quality as well as sharing common knowledge. The process gets easier for sender within years while his/her vision of software development improves. I have been learning from code reviews a lot. The code review discussions provide very good insight and enforce applying well-known principles. Again reviewing is harder than writing the code. I need to get into the mood before reviewing someone else code. So, I spend some time in places like hacker news, dzone and more. By the way, I try to stick to code review guidelines but sometimes I fail to do so because of the rush.

In this post, I have tried to outline my day. It consists of looking at dashboards, planning, design, coding and testing. I didn’t consider meetings here or things like handling system alarms. There are probably many things I didn’t mention like deployment and automation. I hope to add more details to this post later on. I am open to any feedback.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *