Sneak Peek into the Daily Routine of a Software Developer

Patel Asha
3 min readJun 3, 2021

Every work has an enigmatic quality to it. When we pass by the throngs of commuters in the morning, we wonder, “What do those people do all day?”, “Is the money they make worth it?”, “What goes on at their place of business?”

Since software development is such a thriving area, it is shrouded in more mystery than many other fields. So I pondered to write about what a software developer does on a typical day.

Before we get started, there are a couple of things to keep in mind: Obviously, the work changes on a daily basis. Furthermore, each organisation has its own culture and peculiarities.
Let’s start with some background information on project work.

Rush and hush in the Morning

If you’re part of an agile development team, you’ll be part of a group of five or more individuals, with the number of people ranging from five to ten. (Agile development encompasses Extreme Programming [XP], Scrum, Crystal, Dynamic Systems Development Method [DSDM], Lean Development, and Feature-Driven Development [FDD].)

In general, you will work in “sprints”: The intention is to break down a big project into two-week sprints rather than working on it all at once. Everyone on the development team will be given a role that is appropriate for them, either by the senior developer or by their team leader or project manager. Then there is a short meet every morning to track progress. These will
usually consist of 10–15 minute standup meetings in which everyone shares what they’ve accomplished, what they’re struggling or blocked with, and what they intend to do that day.

Routine of the Day

Here is how your day could go:

9 AM: Arrive, check your emails, Prioritise short, medium, and long-term tasks on to-do lists, and schedule meetings.

10 AM: Hold a stand-up meeting to plan the day and organize teamwork
After that, it's on to project work: Coding, problem-solving, and creation are all tasks that must be completed. You will seek or give advice at different times. You may use slack or skype to chat or send a message, pertaining to the situation. If your team members are around, you
could go to a whiteboard or sit together to diagram and work out a solution.

After you have found a solution, you will normally create a “change request” or & “pull request”. summarising the suggested improvements, which everyone else will evaluate. They may have their own ideas or solutions.
This will almost certainly lead to lunch. Meetings and discussions about longer-term initiatives are often held in the afternoon.

Noon time and Project launch

You’ll be given a list of specifications when you start a new project, and then you’ll have to build a design document. This is generally a two- or three-page document that describes the problem and the possible solution. Normally, you would explain how you are addressing the problem and address other options you have considered and why you dismissed them.

You would present it to your boss and the rest of your team. You would get approval before you embark on these larger issues or initiatives, so you would realize you are taking an approved approach and that people are on board with your ideas.

After you have changed your features, you will normally deploy the project to production(alone or with a colleague, depending on the company). Even if you have thoroughly checked it, make sure it runs on your own work machine at this point: After deployment, you could find bugs and have to fix them based on feedback from colleagues and users/customers.

Day’s End (EOD)

Your boss determines how and when your working day ends: It is normally after the regular 8 hours have passed, but if you are working on a project during “crunch time” , you may be asked to continue until a particular task is completed.

The best way to think of a software developer’s everyday life is as a problem-solving exercise: When the project is finished and the team has worked together, the problems to be solved are small and cumulative, leading to the development of a workable and satisfying solution.

--

--