A day in the life of a software developer
Every job has an air of mystery to it. As we see the countless commuters in the morning, questions flit through our minds: What do those people do all day? Are they worth the money they make? What goes on in their workplace?
Software development is a relatively new field, and as such is shrouded in more mystery than many other disciplines. So we’ve taken a look behind the curtain to look at a typical day for a software dev.
Before we dive in, we should add two disclaimers: Obviously, the job varies day to day. Also, every company has its own culture and quirks. We’ll start with some context for project work.
Sprints and the Mornings
If you’re working as part of an agile development team, that will include roughly 5 or more people, and reaching anything up to 10. (Agile development includes Extreme Programming [XP], Scrum, Crystal, Dynamic Systems Development Method [DSDM], Lean Development, and Feature-Driven Development [FDD] among other disciplines.)
Generally you’ll be working in “sprints”: The idea is that rather than working on a large project in a single run, it’s broken down into two-week sprints. Everyone on the dev team would take a task that’s suited to them (either chosen by the dev themself or assigned by their manager/supervisor).
Then, every morning there’s a shorter session to assess progress. These would typically involve standup meetings of 10-15 minutes where everyone says what they’ve achieved, what they’re struggling or blocked with (if anything) and what they’re going to be doing that day.
So your day might break down like this:
9am: Come in, check emails, arrange short, medium and long-term to-do lists, organise meetings
10am: Standup meeting, coordinate day and organise collaboration (if any)
Then it’s into project work: Carry out coding, problem-solving and development. At various points you will ask for advice (or give advice). Depending on the environment, you might chat or send a message via Slack or IRC (a form of chat popular among software devs). If members of your team are free, you might go to a whiteboard together or sit together, and then diagram and work out a solution. (Then you might possibly go back to struggling!)
Depending on the company, after you find a solution, you’d usually create a “change request” or “pull request” summarising changes proposed, which someone else would review. They might have ideas or solutions of their own.
This would probably bring you to lunch. The afternoon is often when meetings are held and longer-term projects are discussed.
Afternoon and Project Launches
When launching a new project, you’re given a list of requirements, and then you would have to create a design document. That’s usually a 2-3 page doc describing the problem and proposed solution.
Usually you would say how you’re approaching the issue and you would discuss other alternatives you have considered and why you rejected them. You would pitch it to your manager and the rest of the team. For these bigger issues or projects, you’d get the go-ahead before you start and you’d know you’re taking an approved approach and that people are on board with your ideas
Depending on the company, after you change your features, then you would usually (alone or with a colleague) deploy the project to production. At this stage, even assuming you’ve tested it rigorously, make sure it runs on your own work computer: You might discover issues after deployment and you’d have to address bugs based on feedback from colleagues and users/customers.
End of Day
How and when your working day ends depends on your employer: It’s usually after the traditional 8 hours have elapsed, but at “crunch time” for projects, you might be required to stay until you’ve finished a specific task.
The best way to look at a software developer’s daily routine is to think of it as problem solving: The issues to be addressed are small and cumulative, building to the creation of a workable (and gratifying) solution when the project is completed and the team has worked in tandem.