What does a typical day look like for a front end developer?

Do you want to get a good understanding for the many things that you would be expected to do working as a future front end developer? I’ll give you a good break down of my day and some of the things that I do.

---

So you might be thinking…

Who exactly are you? Why should I believe that you know anything about what a developer working day is like?

Well… let me first introduce myself. I’m a self-taught, front end developer and work for a medium sized company in Austria. I’m not extraordinary by any means and I don’t work at a top tech firm. I do however work at a good company and one that probably few have ever heard of. So I think I’m more than qualified to answer this question. If you are curious as to how I first got into programming and my previous career background, then have a read of my how I found success in programming article.

Anyways, I started my first developer job about 1 month before the whole Covid pandemic thing started to get serious/blow up in Europe. So I’ve been lucky to have been able to work fully remotely/from home for the past year. Given those circumstances, I will give you a breakdown of my typical (remote) working day, which has become pretty much permanent now.

This post will also give you a good insight into what a front end developer career might look like at a well established company, working on a large existing project. This day is likely not typical of what working at a startup would be like.

So let’s begin…

Before work: Getting ready

I thought I’d cover this before I start my actual work day, because it will show you some of the benefits of working remotely and in tech. It may (or may not) be important to you, but for me it is!

I usually start my day by waking up to my alarm going off a little after 7:30am. Though I’ll sometimes wake up naturally around 7:00am, which is also a great way to start off the day. However, if I’m feeling extra tired from the night before, I might push my alarm back by half an hour or so. This is one of the great perks of having flex-hours and working in tech. Basically…

No strict working hours and no being “late” for work again!

I personally really love this benefit as I’m not one to conform to rigid starting/finishing hours. I like the leeway of having several hours to choose from regarding when I can start/finish work. I only need to be “at work” during my company’s core hours.

Another side benefit to flex-hours is sometimes my morning routine includes going for a morning walk, catching up with a friend from half way across the world, or going grocery shopping. I can do all of this without having to get up any earlier!

And one of the best parts of working remotely is that my office is only a few steps away! Right in my apartment. No morning commute on the train, nor having to deal with a rush of crowded people trying to get to work.

The last benefit is I get to wear comfortable clothes and don’t have to care too much about my appearance. So no need to grab my jeans in the morning anymore!

Starting work: Morning to mid-morning (10am)

I’ll usually start somewhere between 8:15am and 9:15am. Sometimes I’ll start even earlier, and other times a little bit later. It all depends how fast (or slow) I am in the morning and if I have any extra errands to do. I find this flexibility to be totally awesome, and it really suits my lifestyle. In my past career, I always dreaded having to be at work at a fixed/set time and worrying about whether I was going to be late.

Okay, okay… let’s get to it, right? Actual work wise, what is it that I do?

So one of the first things that I’ll do, once my laptop is up and running, is open up Chrome in order to “digitally” clock in (well… into my company’s time tracking system). After that, I open up Slack and my e-mail inbox. I’ll check/read all of my messages and see if there is anything important that needs my attention. This might be something like:

• A message from a colleague asking for something
• A request to review a pull request (PR)
• A message that I booked time on the wrong task
• A question about a task that I’m working on
• Comments on one of my PRs
• Important company news or meetings to attend to

Now I have to say that not every single thing is rosy. There is one thing that I find not so great, which is my company has a vigorous time booking system that we need to adhere to. This means that I have to keep track of my time, and what I spent it on, in a very detailed manner. I do this by using a simple notes file on my desktop. I’ll write down the date, time I started working and start keeping track of my hours. Throughout the day, I’ll come back to this note file to keep adding to it.

So you may ask….

When does the developing happen/start? I just want to develop!!

Well… the short answer is whenever you want.

Often times I do immediately jump into developing a task that I’ve been working on. I find myself most productive in the mornings, so I try to make use of that when I am fresh and have a clear head. Though, other times I will take an “easier” morning start and go through PRs to comment on, review, and approve. This is basically reviewing other developers work/code and making sure that everything works as per the ticket description and that nothing was overlooked. The aim is to make sure that the code is clean and doesn’t introduce any bugs.

And on the days where I’m feeling extra motivated, I might spend a bit of time studying/learning. So reading up on some new developments in JavaScript or React. Watching some videos or online courses for programming topics that I’m a bit weak in, or that I want to expand my knowledge in. Or even going through some online documentation or articles.

Depending when I start, this part can be quite short, or I can have a solid 1-2 hours of work before my first…

Yes, developers have meetings and there can be a lot of them on some days! This is just like any other office job. All of our meetings are done through Zoom and are virtual in nature.

At my company, the first meeting is a morning coffee daily that is totally optional to attend. This is where you socialise (or don’t) with your colleagues, or sometimes stare at each other in silence.

After the coffee daily, we immediately switch into ‘work’ mode and have announcements. These come from our project owners (POs), scrum masters (SMs), designers (UX) and quality assurance (QA) teams. The announcements are very brief and the whole process goes by super fast. At the end we split up into our own sub-team Zoom rooms, and have our team dailies.

Team dailies last about 15 minutes and we spend our time going through all of the tasks in the sprint. We go one by one and report what we did the previous day, challenges, issues, if we require help/assistance and our plans for the current day. I would say that the benefit is mostly for the PO and SM to find out what is going on and for developers when they need some help with something.

Finally around mid-morning, we get a good chunk of focus time to work on our tasks (unless it is one of the days filled with meetings).

In the groove: Mid-morning to lunch (varies, but usually between 12 - 1:30pm)

This is where the magic happens.

By magic… I mean on the verge of ripping my hair out and throwing my laptop out the window because I can’t figure out where the bug is in my code.

Aaargh… Why won’t you just f*cking work??

In all seriousness, that has not happened. Nope! Not even once! So don’t worry, you won’t go through this. Google and StackOverflow always have your back!

Alright… so if I’ve just started a task, I usually like to read the task description (user story) and make sure that I understand everything. If something isn’t clear, I will ask the PO or the person who created the ticket to clarify. Once I know what I need to do/implement, I’ll go ahead and create a new branch off of the master branch.

This is the start and I’ll go ahead and start writing some code. This could be CSS if it is a UI/styling related task or bug. Or the task could be more complicated and might involve adding a new feature that may require me to create a new React component and write some JavaScript, or JSX. It could be adding some logic implementation to show or hide a certain feature, or portion on the website. Or it could be implementing an A/B test for an experiment. Or it could even be a task that involves cooperation with a backend developer and requires working in multiple repositories to finish the task.

The user stories and tasks vary greatly!

In the case that I’m already working on a task, but stuck / in need of some help, I would have an informal meeting here with a senior developer to get some advice or to do a bit of pair programming. At minimum, I get some insight on the problem I’m having. Other times, I might need to talk to the PO to discuss changes to the user story, or bugs that I’ve found in the task, or some unexpected problems that arose during implementation.

As you can see… what I’m working on during this time varies quite a bit. Usually it will be either in an informal meeting discussing a task/work, coding, or searching on Google why the f*ck my code implementation won’t work. Believe me… that happens more often than you may think!

Once I get to a good point (ex: meeting is finished), or I wrote enough working code, or maybe it’s not working at all and I just need a break…

Then I will have my lunch break. Usually this is only 30 minutes, but sometimes I take longer to go do something, or to go outside. So it could be 45 minutes, 1 hour or even more. It is quite flexible here, but the longer you take for lunch… the longer you’ll need to stay working.

Gotta get those hours!

The most important thing is that you work enough hours by the end of the week.

Finishing off the day: Post lunch to the end of the day (4:30-6pm)

So after lunch, and eating a meal, I won’t always have the same amount of energy to get back into things. If there is a problem that is on my mind and something that I can’t figure out… it’s really easy to just get back into that zone of trying to solve the issue.

If I had finished off a meeting, or things were going smoothly on my task, I might take a little bit to get back into the groove. So depending on where my head is (it’s definitely still on my head though), I might go through e-mails and slack messages. See if anything important popped up. Or I might spend some time going through, reviewing and approving PRs. This is just to change things up and give myself something different to work on.

More often in the afternoon, I seem to “finish” off my tasks.

Wait?!?! Why are you quoting finish? Mmmm…

Well, because once you “finish” the code implementation of a task, there is still a long way to go before it is truely finished!

Did somebody forget about testing?

Yes! Once I’ve implemented the code, I will vigorously test my task. This happens manually, and I’ll go to the place on the site where I made my changes to make sure that everything is still working okay. That no bugs are occurring!

Often times I will notice an issue, or bug, and I’ll have to get back to work. Occasionally the bugs I find won’t be related to my task, so I can just create a bug ticket for them.

Yay!

When I’m happy with my task and everything is looking good on the site, I’ll open up a PR and wait for the comments, reviews and approvals to come in. This can take up to several days depending on how big the PR is. During this time I will create testing documentation to manually test the task, and when I have my approvals, I’ll manually test it (and all edge cases) to make sure that everything works as per the task description.

Often I’ll also have to write automated tests for my tasks (where appropriate) and this can be done before, or after, I open up my PR. This is another part that I don’t particularly enjoy doing and I often experience trouble with writing good tests. This is an area that I’d highly advise future developers to learn and get a lot of training on.

Sometimes writing the tests are the hardest and most time consuming part of the task and you would expect it to be the other way around. So this is an area that you definitely want to get good at, as you’ll not be able to avoid writing tests.

If you are wondering…

Do you do all of that work in one day???

Gosh no!! Only if a task is a one-liner, or super simple, then maybe yes. However, most of the time these tasks take multiple days to implement (to the point where you have the PR open) or it can be a week or longer depending on complications, unexpected issues and complexity.

So don’t worry. At my company, a sprint lasts 2 weeks and I’ll usually take 1-2 tasks into a sprint. So you have time to go through the entire developer process and work around all the meetings.

Meetings are heavy at the start and end of a sprint.

Once I’ve had enough for the day, or I finished off what I wanted to get done…

Guess what I need to do??

Yup, my time sheet!

I’ll transfer all of my time tracking notes (the thing I talked about at the start of my day) into the online time tracking software we use. This can be relatively quick, or take 15 minutes depending on how many different things I worked on/did and all the different number I need to book on.

Aaaaannd…

Finally I digitally clock out and close my laptop!

Phew! That’s my working day in a nutshell and just some of the things that I’ll spend my time working on. I also wrote a blog post where I reflect upon my first year working as a developer. In that post I give some different insights into my work, as well as my overall programming progress.

Other wise if you have any questions, or would like some more information on a particular topic, feel free to reach out to me via email.