What does a day in the life of a software developer look like?

Broadly speaking you can divide software development into enterprise software development and technical software development. The first one is concerned with developing enterprise systems where it is important to write code to serve a lot of users simultaneously and integrating with other business software. The latter one is about developing (industrial) software for machines and devices. Here the focus is on interfacing with hardware and writing small efficient code. Each field will have different tasks and you will interact with different kinds of people.

But generally speaking this is what you wil do:

• Talk to users, analysts or requirements engineers about what the software should do
• Talk to architects to understand how your software should work together with other software
• Create and/or review software designs
• Write and test code. Most of the code you'll write is test code to check if your code is valid, secure and performs well
• Review the code, tests and documentation of your peer developers
• Estimate development effort so software releases can be planned
• Deploy software to a test or production environment
• Monitor the production environment to prevent outages
• Write or provide input to the user manual
• Provide support to users
• Demo the software to explain how it works
• Work with the other developers to think about how you can improve collaboration
• Write tooling to automate your work
• ....

A lot of development teams nowadays work according to the scrum framework. Check out the provided link below.

A day in the life would depend on the nature of work and team processes in place. However, I can share my current experience as a software developer on a product development centric team. The day usually starts with a team meeting which we refer to as a "standup". This is a daily meeting which allows each person on the team to share updates of what they were working on during the previous day and also what tasks they plan to work on for the current day. Additionally, it's one of the many (hopefully) opportunities to identify teammates that you can help or receive help from if you're feeling stuck on your work.

Afterwards, I mostly have the full day to take action on the work I've been assigned. This usually means designing solutions, programming, or researching the topic further. There could be a few other meetings pop up during the day which could be related to upcoming work for the team or even a 1 on 1 with a manager (weekly meeting). Overall, if you're on a high performing team, then you should expect to be given plenty of time to focus on your work during the day. This flexibility is one of the things I enjoy most since it gives plenty of autonomy to get the job done at your own pace.

Hi Joshua,

You've already gotten some good answers, but I'll share my experience as well. I am now a VP of Engineering, but I wrote code for about 17 years. I worked at a lot of different places. I started off with front-end web development (what shows up in the web browser), then moved to full-stack development. Full-stack development includs writing code to read and write from databases, code for the "business logic" (methods and algorithms), and code to show the application in web browsers. My typical day was:

First, get to work, get some coffee, check email. Then I would look at my to do list for the day—sometimes this was a list I had written the day before, sometimes it was picking something from a shared list we had as a team.

Usually, by the time I knew what I'd be working on, it would be time for standup, which Christian already described. Then I'd have a few hours before lunch and write some code.

There are several phases to writing code: first you have to understand enough of the requirements to make sure you're on the right track. Sometimes they are written out for you very clearly, but this isn't usually the case. Sometimes this means you meet with your product owner (also called a product manager—basically, a person who defines projects for your team). Sometimes you meet with a designer, sometimes you meet with a customer who is having a problem. Sometimes, you talk to other engineers on your team because maybe they understand the project better or the code you need to work with. My point here, is that there's a surprising amount of communication involved in software development. Every software developer has to find the right balance of writing code, asking questions, and sharing ideas with others to do the best job they can.

Once you know what code you're writing and why, you jump in and start writing it. Sometimes this causes other questions and you go seek answers, either online (like on Stackoverflow), in books, or from your team, etc. Sometimes you have to edit a bunch of code. In full-stack development, I usually started with the database, then worked on the business logic, then the UI. I typically wrote tests along with the code—write a chunk of code, write some tests, repeat. Then, when code is ready, give it to someone for review and deploy it to a test environment and then, if everything checks out, to production. It's really exciting when your code goes to production because that means people can use it!

My most productive times were usually the two hours before lunch, and then about an hour after lunch until the end of the day. I tried to do things like reading email in my less productive times, and write code in the more productive times. This is different for everyone.

At the end of the day, I would usually try to write down where I wanted to start the next day. It's kind of like putting a bookmark in a book you are reading—sometimes it's hard to go home because you don't want to lose your place. So I'd write myself a little bookmark and be able to more quickly get back to what I was doing the following day.

There are a few other things that come up all the time in software development, but not necessarily every day. Usually, you have to keep your development environment (on your laptop or desktop) up to date, so there's some configuration required. This can occasionally be frustrating, but is part of the job. Also, you sometimes need to document your code—this can vary from place to place. At some places, they think your code should be readable enough that you don't need to write any documentation, other places you just add comments to the code. At other places, you have to write documentation that your customers can read, so it needs to be really polished. There are lots of little things like this—I won't write about them all, but every job has some amount of maintenance type work. Still, it's rarely the bulk of your time, just something to be aware of.

I hope this is helpful—I've really enjoyed my career in software and I hope you do, too!

It is always a challenge. You start off with certain requirements and they are fluid so you have to keep up with the changes and deliver a product that the customer enjoys.