A Day Of a Software Developer

How does a software developer's day look like? It all depends on the kind of work/industry. Whether it is freelancing, contract work or full time employed. Another factor of how the day goes is the software development cycle (SDLC) that the company/developer uses to get his/her work done. There are common ones that will be most encountered in the workplace, waterfall (one of the oldest and most straight forward structures) and agile methodology. Since these two are most commonly found, let's discuss what the day look like for a developer and his/her team for each methodologies.

Waterfall

Waterfall methodology is structured in a way where the work is divided in phases, each phase must be completed to continue to the next one. The classic approach is Analysis > Design > Code > Testing > Maintenance.
This is where days, weeks and months might differs from one another, because each phase might required different kind of work and structure. Let's go over what each phase might look like.

Analysis

This is where engineers, product owners, and other managers of the projects get together to present the overall project functionality. Engineers have a chance to ask questions and discuss the feasibility of the project. Managers discuss timelines, budget and other requirements to get the project started. This phase is mainly sets of meetings, sometimes all day for several days.

Design

Once the analysis phase has been completed, budget set and timeline agreed upon, the design phase beings. This is where software developers and architects start defining the overall hardware and software requirements for the project as well as documenting the changes that are to be made to existing code base or new code base required. The developer spends most of his/her time working alone analyzing existing code, doing research on new technology needed and documenting. Collaboration might happen between fellow developers or system engineers. Depending on the size of the project, this step might be finished at the 1-2 month mark since phase one. Not a single line of code has been written at this time.

Code/Implementation

This is where the fun begins, once the design of the project has been finalized and approved by software architects and principals, the developer starts coding based on the design phase. Changes might have been done to the original design phase, any changes must be documented and approved. Most of this time is spent coding, 80% of the day is spent working solo, collaboration might occur. Again, depending on the length and complexity of the project, this phase might take between 1-2 months.

Testing

At this point of the project, code has been done along with code reviews from software architects and peers, the project gets passed along to quality assurance team where they test the software for functionality, performance, error handling, etc. The developer is available if needed for fixing any bugs found or performance issues. At this point, the developer might start working in parallel on the next project's analysis phase.

Maintenance

Once the code base gets released to production, any issues encountered are to be addressed. Time spent on this is minimal, there is usually a couple of developers in charged of fixing bugs after the code is release to production and it doesn't take much time as each fix is done as surgical as possible (not making big changes in the code).

Waterfall worked well for many years, however as technology advances and companies get more competitive new methodologies emerged to make software development faster and more efficient. As you can tell, waterfall might take between 4-6 months to complete. Clients will need to wait for that long for new features requested, which might impact the business.

Agile

Agile methodology ideas have been around since the early 90s, however it wasn't until around 2000s where a more defined practice started when a group of software developers collaborated to create the manifesto for Agile Software Development. This approach is more granular than the waterfall methodology. The idea is to have a more evolving project, more collaborative and cross-functional teams and their customers/users. This encourages more flexible and rapid development.

In contrasts of waterfall, the agile methodology invites changes of requirements throughout the life of the project. Agile is usually accompanied by the Scrum process which suggests small teams (fewer than 10) to break down the work into attainable goals that must be completed in timeboxed iterations (usually 2 weeks, called sprints).

Because agile and scrum has shorter and more organized cycles allocated for each team/developer, it makes it easier to create a routine of work as opposed to waterfall methodology. This is the usually day of a developer in an agile environment

Morning

As part of the scrum process there are certain events that happen throughout the sprint (approx. 2 week cycle), these events are called "ceremonies". There is a quick meeting early in the morning, this ceremony is called "stand-up" meeting. These meetings are no longer than 15 minutes and are meant to be done standing up to encourage the attendee to share 3 things, what was done the previous day (tasks completed), what is planned to do the current day, and share if there is anything blocking him/her from doing the work (such as waiting for client's response, waiting for other team member to complete a task, etc). After the stand-up meeting, the developer goes on and continue working on his/her tasks.

Lunch time (yum)

This is the most important time of the day for a developer

Afternoon

Depending on when the other scrum ceremonies are scheduled, either the developer continues working on his/her tasks or ceremonies take place such as grooming meetings, this meetings are meant to get the team together, present what work is planned for future sprints and estimate the complexity (measures by points) or the work. This complexity system matures overtime as estimations get more accurate, this is important for planning as each complexity point is averaged per sprint cycle and it helps better estimates how many points (ultimately tasks) can be added per sprint. The goal is to have enough tasks per sprint where they can be completed in time and be ready to be shipped to production if the product owner decides to do so.

Other ceremonies include retrospective of the previous sprint. In this meeting, developers, product owners and anyone else involved in the sprint shared what worked well, what did not work and what can be improved in the cycle. This meeting is to improved the process, as each organization/team is different and needs to be improved over time.

I included a chart on how my time is spent between meeting and time I have to work on projects/research.

Agile/scrum methodology might feel more rushed than waterfall but it is also more organized and it allows rapid change in direction. The developer has more structure way to plan his/her day and he/she gets faster feedback from both colleagues and users. Users also enjoy the benefit of faster turn around for critical functionality or bug fixes. Developers and product owners can rapidly act on new technologies, if priorities change there is only a 2 week wait time to start working on them as opposed of 4-6 months for waterfall.