My Typical Day as a Software Developer

Posted by Goran Božić on 10 December 2019

Until I started writing this blog, I thought that every day as a developer was the same. Thinking about this topic makes me realize that it is not true. Depending on the sprint, the day of the week or type of work; days are slightly different. Sprints can be regular or hardening, I like regular sprints more, because there is a slim possibility to work on something new and interesting. In hardening, we fix bugs and it tends to be very boring and frustrating. By type of work, I mean what a person likes to do. Some people like to make user interfaces, others are more interested in logic on the service side and in the end, we all must write tests. Ideally, we can divide work to our preferences, but there are days when you do what you must to do.

My Perfect Day as a Developer

I will try to describe my perfect day as a developer. The morning sun would wake me up, lying in bed waiting for the sound of an alarm I would think about that day. After breakfast, morning workouts and personal hygiene, I would go out in the yard to decide if I am going to work by bike or car. Although this is not part of my workday, and I certainly do not work out in the morning, I wanted to emphasize the luxury of flexible working hours. In the company where I work, we can start anytime between 7:00 and 9:30, which allows a lot of flexibility for the worker to organize his day. During my four years of service, I was in a situation of hurrying to work a couple of times, mainly because of obligations that I squeeze in before work. In these situations, I realized what it means to go to work without looking at the clock.


The first tasks after arriving at work are checking emails and analyzing the continuous integration cycle results which were run the night before. Central and local cycles are analyzed to check the quality of the program after the changes have been made. This analysis, in theory, ends by making sure that cycle is “green”, which means that the code has been checkout to the test machine, built, the new installation has been made and all tests were successfully performed (Unit tests, BDDs, automated tests). In practice, I have not yet experienced all tests have been completed successfully, so cycle analysis comes down to the conclusion that it is not our fault or if it is our fault, we fix this cause/bug right away. By the time the analysis of the cycle is completed, most colleagues have arrived at work and we drink morning coffee and talk about current topics. Current topics can be various, mainly we speak about Jokic, Game of Thrones, apartment renovations, company news or topics that can be found in the daily press. By 9:30 all my colleagues have arrived and the daily standup begins. The daily standup is a short meeting where everyone says what they did the day before, whether there are any problems and what his/her plan for the current day. Sometimes, when we reach a problem in the development phase and weren’t able to complete a task, we make jokes that we did nothing. 

After a daily standup, everyone gets into their problems and starts working to resolve it. It is often the case that someone reports a problem at the daily standup and asks for help. In these situations, experienced colleagues help to find a solution immediately after the meeting. This part of the day, in my opinion, is the most efficient and it lasts until about 12 o’clock; this is when most of us go to lunch.

Lunch is treated as a break and we have half an hour for it, but often that lunch can be very productive from a developmental point of view. Talking about a current problem, a colleague can give you an idea that can be the solution to your problem. Of course, there will be days when no one has a problem, so we spend lunch talking about sports, travel plans or the latest actress from a movie.


When lunch is over, we’ll be back in the office and continuing to develop for the rest of the day. By the end of the day, we are finishing what we have planned for the day and commit our changes. In my team, we commits push to the local repository and start the cycle to check if the quality is compromised. If by the end of the day there is still time, we take another problem or continue to develop functionality. In my team, we try to push commits frequently, especially if more of us work on the same functionality, to keep everyone aligned.

Sometimes the work cannot be done in a day, so it continues to the next day, or if it is an urgent problem, the developer stays until the problem is solved. At the end of the day, everyone goes home one by one, depending on who was an early riser that morning. When the time comes for you to go home or to the pub, you close your assignment on tracking software and leave with a good feeling because you had a successful day and finished the job you planned.


Of course, this is a description of a nice and successful day, where there are no long meetings where we plan the next sprint or groom the work that follows. We spend on average one day every three weeks for planning and grooming meetings. I described the day where all the plans were completed with no problems that sometimes know to drive you crazy. Of course, you will have bad days too but these are part and parcel to any job, heck, without them, it might get boring.  After all, the most important thing is that you don’t dread the idea of going to work in the morning.