A typical work day

·

5 min read

I'm a junior front end developer at a small company. Most of my work is on Drupal sites, but I also do some on WordPress sites, and some sites that use neither.

First thing

I start off by checking Slack. There are channels on there for specific projects, so it's good to see if anything has come up since the last working day. There are also channels for work things that everyone might need to know. And channels for non-work things. Most of the time most of the posts are during my working day, so there's generally not a lot to read at the beginning of my day.

I also have Slack connected to other apps. So it'll tell me what's on my calendar today, what projects I'm working on today and if anyone has assigned me any tickets. So it's a good brief look at what my day is going to be like.

I also open up my email to see if there's anything in there, but most of my email is inviting me to meetings, so there's generally nothing to read there. I also check my calendar because, unlike the Slack message, this will tell me who is on holiday that day. I check that day and the following day in case anyone is off who I might need something from, so I can make sure to speak to them while they're in. I then open up the scheduling program we use which tells me what I'm working on today. I also like to look at the next few days too, so I know where I am.

This has all taken about five minutes, so I then start my Pomodoro timer - it means I take my five minute breaks on the hour.

Setting up the project

If I'm working on something that's new to me I'll get it loaded up and have a look at it. Then check the ticket to get all the information. I then add it into my to do list as tasks I can tick off. This is partly because I like ticking things off - it makes me feel like I'm achieving something. But also because one ticket could involve multiple tasks and it helps to know which I've done.

If I'm working on something that I was working on before, then I've generally got the information on my to do list already, so I can pick up where I left off.

I'll then go and check the repo to see what's been done on it. If it's a project that's already on my computer, then I check to see if anyone has committed anything since I last worked on it. If they have, and they've done or merged it on the working branch, then I pull that, so I have the latest code. However, if I'm in the middle of something I'll first finish that and test it, then merge the latest code into my branch. That way if something is then wrong I know it's to do with that merge and it's not just because I've half done something and not tested it.

The actual programming bit

I then get stuck in on the project. If I'm working on one project all day, then I'll just keep going until the end of the day. If it's multiple projects, then I'll do one and then go back to the setting the project up stage.

End of the day

I try and stop at a good place to stop - so finishing a ticket is a good place. But it doesn't always work out that way. If I'm working on the project again the next day I'll rely on my memory and my to do list to remind me where I am. If it's going to be a little while then I'll write some more notes about exactly where I'm up to.

If it's the end of the day and something's just not working, then if I think it's a simple fix I'll try and fix it. Often, though, the end of the day is not the best time for that. If I can't fix it, or I know it's a longer fix, or I don't know how to fix it, I'll write a note on my to do list about what the problem is, what I've tried to fix it and what I think might fix it. Then I can come back to it in the morning when it's likely to be an easier fix. Sometimes that works well, sometimes it's still just as much of a mystery as it was the previous time I looked at it.

Meetings

The one thing I knew about working in tech before I started is that it involves a lot of meetings. But at the moment I'm averaging less than one a day. At least when it comes to formal meetings in the calendar. It depends a lot on what projects I'm working on. Some projects have a stand up every day, generally about two hours into my day. That's because I like to start early and other people might like to start late. Some projects will have a weekly or fortnightly catch up, generally around the same time of day.

There are other non-project meetings that are weekly at most. And I may well meet with people after a quick Slack chat about something that is easier to talk about in person - or over Zoom.