The Day in the Life of a Backend Developer

Here is a more or less exact transcript of a day in the life of me as an ASP.NET Core Backend Developer:

TR; DR; – summary

Reflecting on a typical working day, I’d say I spend 50% of my time on project work, 20% in meetings and on general communication, and the remaining 30% working on immediate requests and bugs. My daily toolkit consists mainly of Visual Studio, an integrated development environment, Azure DevOps, a project management tool, Slack and Gmail for internal communication, Git for code version control, Google, StackOverflow. 

7.45 am: I usually go to the office between 7:30 and 8 am. This is the best time to get some peace and quiet, and gives me the chance to get organized for the day ahead. I spend about 30 minutes to 1 hour checking for errors and bug reports to see if any issues cropped up while I was gone, and prioritize my to-do list accordingly.

8.30 am Each morning we get together for 15-25 minutes to discuss ongoing projects. We talk about what we did the day before, what we’ll focus on for the day ahead, and any obstacles we’re currently facing. This allows us to make sure we’re on track as a team and to plan the rest of the week.

9 am Now the real work begins. With the first meeting out the way, I’ll get stuck into my high priority tasks. This might be something leftover from the day before or an urgent bug that needs fixing. In the absence of emergencies, I simply make a start on my to-do list. We use a project management tool called Azure DevOps for scrum planning and TMetric for time tracking, so I’ll get the next project from Azure DevOps and start tracking my time.

We do also practice pair programming, so depending on the task at hand, I might sit with one of the other developers so we can work on it together. This is a fairly common practice in the software development industry and basically enables us to pool our knowledge and brainpower to find the best solutions.

Once I’m done with a task, I submit my code for review. I upload it to the testing server and to Azure DevOps with a comment on what I’ve done and why any changes I’ve made and instructions on how to test it. I’ll then mark it for review so that my team sees it. We operate a policy whereby all code has to be reviewed by at least one other team member, so that’s what this step is for. Once I’ve submitted my code for review, I’ll stop the time tracking in TMetric and move that task to the QA column.

2 pm, After lunch, Back at my desk, I take the next card from the sprint planning column in Azure DevOps and start the time tracker. The time tracker helps us plan our time more efficiently - we get a good overview of how much time we’re spending on what, and we can make realistic estimates for future projects. Once I’ve finished my task, I’ll move it to the QA column in Azure DevOps.

4 pm I spend the last hour of the day tying up any loose ends and getting ready for tomorrow. I’ll check the projects that I submitted before lunch to see if they’ve been reviewed yet. If they have, I’ll go through the feedback and apply all the changes requested, and then re-submit for further review. I’ll then attend to any bug fixes or requests from the other developers, and review any code that has been submitted.

At 5 pm: I shut down my PC and head home. I generally don’t work overtime unless there’s something really urgent to deal with. As long as I’ve wrapped everything up and know what I’m doing the next day, I’m ready to leave on time.