If you’re considering a career in web development, you’ll no doubt want to know what’s it really like once you land that first role.
To provide some real-life insight, we asked our in-house web developer Sam to talk us through his typical working day.
Having originally trained as a musician, Sam decided to make the switch to web development. After taking the CareerFoundry web development program, he started out as a junior developer and now leads a team of three.
Here, he tells us how he goes about his day, what challenges he faces and what keeps him motivated. If you’d like to follow in his footsteps, scroll to the end of the article to watch a video he made about how to become a web developer.
Over to you, Sam:
A day in the life of a developer: Sam’s routine
I usually get into the office somewhere between eight-thirty and nine, before the hubbub starts. This is the best time to get some peace and quiet, and gives me the chance to get organized for the day ahead.
I spend about 45 minutes sifting through my emails and Slack messages.
I’m a zero-inbox person, so the only emails in my inbox are open tasks that I need to work on or respond to—everything else is archived. I’ll then check for errors and bug reports to see if any issues cropped up while I was gone, and prioritize my to-do list accordingly.
Time to grab a coffee before our team meeting. Each morning we get together for an hour or so to discuss our weekly sprint goals.
We talk about what we did the day before, what we’ll focus on for the day ahead, and any obstacles we’re currently facing. This allows us to make sure we’re on track as a team and to plan the rest of the week.
Now the real work begins. With the first meeting out of the way, I’ll get stuck into my high priority tasks. This might be something left over from the day before, or an urgent bug that needs fixing. In the absence of emergencies, I simply make a start on my to-do list.
We use a project management tool called Ora for agile planning and time tracking, so I’ll get the next project from Ora and start tracking my time. At this point, I tend to stick my headphones on and work independently to a bit of classical music.
We do also practice pair programming, so depending on the task at hand, I might sit with one of the other developers so we can work on it together. This is a fairly common practice in the web development industry, and basically enables us to pool our knowledge and brainpower to find the best solutions.
Once I’m done with a task, I submit my code for review. I upload it to the testing server and to GitHub with a comment on what I’ve done and why, any changes I’ve made and instructions on how to test it. I’ll then mark it for review so that my team sees.
We operate a policy whereby all code has to be reviewed by at least one other team member, which is why version control systems are vital tools. Once I’ve submitted my code for review, I’ll stop the time tracking in Ora and move that task to the QA column.
By now I’m pretty hungry and ready for a break, so we all head out for lunch.
I tend to go out for lunch as I think it’s really important to get out of the office and interrupt your workflow for a bit. We talk politics, philosophy, bitcoin, and family life over burgers before heading back to the office.
After lunch, I grab my second hit of caffeine before the next round of meetings begins. Next up we meet with the design team for project handover.
They present their UI designs, walking us through everything, and we can ask questions and start thinking about how we might translate their designs into code.
The meeting lasts about an hour, and once it’s finished, we make a card in Ora summarizing this particular project. It’s then added to our backlog of tasks.
Back at my desk, I take the next card from the sprint planning column in Ora and start the time tracker.
The time tracker helps us plan our time more efficiently—we get a good overview of how much time we’re spending on what, and we can make realistic estimates for future projects. Once I’ve finished my task, I’ll move it to the QA column in Ora.
I spend the last hour of the day tying up any loose ends and getting ready for tomorrow.
I’ll check the projects that I submitted before lunch to see if they’ve been reviewed yet. If they have, I’ll go through the feedback and apply all the changes requested, and then re-submit for further review. I’ll then attend to any bug fixes or requests from the other developers, and review any code that has been submitted.
Around six, I close my laptop and head home. I generally don’t work overtime unless there’s something really urgent to deal with.
As long as I’ve wrapped everything up and know what I’m doing the next day, I’m ready to leave on time.
Some evenings, I’ll work on freelance projects after I’ve had dinner and spent some time with my family.
Otherwise, I like to unwind by watching TV or playing piano. Generally, I try to take a break from programming—however, ideas often come to me as I’m in bed falling asleep, so I grab my phone, type out a quick email to myself and send it to my work address.
I don’t have my work email or calendar on my phone, as I prefer to have some separation and try to leave my work in the office as much as I can.
The day in review
Reflecting on a typical working day, I’d say I spend 50% of my time on project work, 25% in meetings and on general communication, and the remaining 25% working on immediate requests and bugs.
My daily toolkit consists mainly of Ora the project management tool, Slack and Gmail for internal communication, GitHub for code version control, Atom for text editing, Google Keep for note-taking, Zeplin and Sketch for design hand-off, and Google Drive for anything miscellaneous.
The biggest challenge to my productivity on a daily basis is definitely the ad-hoc requests I get from other teams. Slack can be really distracting, but it’s also a communications tool we just couldn’t do without.
It’s important to manage other people’s expectations and to balance the act of responding to urgent error reports, and knowing when to shut yourself off and focus on the larger projects.
Finally, I wouldn’t be nearly as effective at my job if I didn’t like our product. Being passionate about what the company does keeps me motivated from day to day: I go to work each morning knowing that what I’m working on has a direct and visible impact. I can see things improving as a result of my work, and that’s really satisfying.
I hope you enjoyed reading about Sam’s day, and got a lot of insights into what a programmer’s day-to-day is actually like.
Just want to read more about the world of coding? Check out these articles: