The goal of a hackathon is to create functioning software or hardware by the end of the event
I have only stumbled on a couple instances where someone clearly blocks out how a hypothetical work day should be structured for a software developer. It was many years before I stopped trying to get as much “work” done as possible and instead focused on finding a sustainable rhythm that was enjoyable and ultimately produced better results. Below is a breakdown of how a day in the life of a software developer could look.
Settling In (9AM - 9:30AM)
You get to work just before 9AM and pour yourself a coffee, tea, or water. These few minutes help remind you that you’ve entered a new head space for the next 8 hours. Whether remote, or in office, one can segment the day by whatever the current time is.
Say hi to your teammates. Smile. Be human - it’s very easy (and detrimental) to become a robot as a software developer.
Take some time to re-familiarize yourself with where you left off the previous work day. You should enter standup with a solid understanding of what you would like to communicate with your team. This should be more focused on what is needed today, rather than just reporting what you did the previous day.
Standup (9:30AM - 9:45AM)
This is where the day’s “hackathon” begins. You should determine what the most important thing to accomplish today is. There may be some smaller items to be done, but usually there is one main thing that ideally is completed by the end of the day.
Depending on the project the goal might be to get a small UI update coded, reviewed, and deployed by the end of the day. Or it might be making a clear incremental step toward the progress of a larger feature. Either way, this goal should have a clear end point. Not everyone on the team may be directly involved in the work, but if they know what is going on they can make sure to provide assistance when necessary.
Clear Out Distractions (9:45AM - 10AM)
Respond to any messages that require your attention. In the two hours after this, I will suggest ignoring messages altogether. If you’re like me, the morning tea has you ready for a bathroom break. You want to exit this period with confidence that nothing will interrupt you for the next two hours.
Focus Block #1 (10AM - 12PM)
Now that you’ve identified what the goal of the day is, this is the first chunk of time to work on it. On average, software tasks take twice as long as we expect them to. Ideally, your day’s goal appears to be accomplishable within this first focus block. This leaves ample room for code review, testing, and potentially some minor tweaks in the afternoon focus block.
Now is the time to mute Slack. Slack is is easily the #1 productivity killer at companies. It takes almost 30 minutes to recover from a distraction , which means it only takes 4 sporadic Slack messages to destroy an entire 2 hour focus block.
If you’re response is actually necessary right that moment - the person can come find you or call you.
When nearing the end of the first focus block, it’s good to be realistic about what you can complete. You should be comitting smaller changes along the way and with about 15 minutes left, should be looking to tidy up where you’re at.
If the task is complete at this point, you can use the next several minutes to make your pull request and give it a scan before anyone else reviews it. This can save a ton of time as you will catch low hanging fruit before it gets sent back from code review.
If you have not completed your task yet, now is a good time to think about what will be accomplishable by the end of the day. Are you stuck? Should you be asking for help after lunch? Remember, what you were working on was only supposed to take a couple of hours. If you have much more work to do, it’s likely that you have underestimated the task and should communicate this.
Lunch (12PM - 1PM)
Taking a proper lunch is incredibly important. Stepping away from the computer allows your mind to relax and rejuvanates the mind. I often find that after lunch I’ve solved whatever problem I was facing without actually consciously thinking about it.
In a team setting, this is important time to spend time with others. We are social animals and this helps form stronger connections with the people you work with.
Check-in (1PM - 1:15PM)
This may be contraversial, but checking in with those you are working directly with at this point is invaluable. Depending on how the morning went, it might already be time to shift priorities. Perhaps someone on the team is stuck on something, or the work from the morning revealed new requirements that should be discussed.
Code Review (1:15PM - 1:45PM)
From the check-in that you just had, teammates should have identified work that needs to be reviewed. In an ideal world, this work was done as part of a pairing session, which means that this code review should mostly be looking for things the original two authors missed rather than sending the entire thing back to the drawing board.
Focus Block #2 (1:45PM - 3:45PM)
Pretty much everything from Focus Block #1 applies here as well. Depending on the day, you might be furthering work that was started in the first focus block, or you might be starting something new. Either way, you should be focused on completing the task or making tangible incremental progress. Anything more than a couple of hours of coding becomes difficult for others to review - eventually delaying how long it takes to get deployed. If you realize you’ve bit off more than you can chew, consider breaking down your current task into smaller pieces and focus on completing just one of those subtasks.
Code Review (3:45PM - 4:15PM)
At this point, you (and your team) should have more code that needs to be reviewed. Instead of opening a pull request and then doing nothing, actively seek out final approvals. In 5-10 minutes it should become clear whether the current staged changes will be approved (possibly with minor changes) or if some change is requested that will require a decent amount of work. If this is the case, plan to continue the work tomorrow.
Reflect (4:15PM - 4:30PM)
Sprint Retrospectives is the main time I have seen reflection suggested in the development process. These usually happen every 2 weeks and focus on the broader sprint goal. I highly recommend incorporating a brief indivdual reflection in your day-to-day work schedule. Take several minutes to recap what happened in the day. What went well? What didn’t go so well? Are there things that could be done differently tomorrow?
This is uncomfortable territory for lots of people. “I should be doing real work instead” is probably the most common reason to not reflect. I have proven to myself time and time again, that reflection is an extremely powerful tool to accelerate your productivity and improve daily satisfaction - leading to large long term benefits.
Prepare for Tomorrow (4:30PM - 5:00PM)
The work day is nearing the end. Now is a great time to start preparing for the next day. This could mean getting some questions answered about upcoming work or breaking down a larger task into something that seems manageable in a 2 hour focus block. Inevitably, there’s also still some amount of lingering conversation regarding the work earlier in the day.
Wrap-Up
I’ve intentionally kept details about actually deploying code sparse. This will be very dependent on your current team’s process. If you followed the above and have small, independently deployable changes it should be easy to figure out how to incorporate other aspects of deployment into the above. For example, if you have QA run checks against changes, this could occur right after (or while) code reviews are completed.
Despite how it looks, this is not a prescription for every day to look exactly like this. Instead, it is a starting place to work off of. Sometimes things take longer or shorter. I encourage you to at the very least sit down and write out how you want your ideal work day to flow. I didn’t do this for years. When I finally did it felt like everything made a lot more sense.