A Day in the Life of a JavaScript Developer – Remote Edition

So you want to work from home - that's nothing new in the tech world – but what is it like as a remote Javascript Engineer? Whether you're a new tech grad or just trying to understand life as a Javascript Developer, we're about to reveal all. We got special insight from the eyes of an anonymous Frontend Engineer that for security purposes we'll call Jack*. Let's get cracking!

Coffee all the way

The day usually starts at about 7.30 am or 8.00 am, and it's straight to coffee (or your breakfast of choice). The great thing about working from home (WFH) is that if you really want to, you can live a whole other life before you start your role. Think: gym, going for a run, dropping off the kids, etc. Or (and there is no judgement here), a lie-in.

Whilst having my morning coffee, I'll usually check my emails to ease myself into the day whilst spending time with my pet cat Bongo. It's a way to catch up on anything that was left pending from the previous day but in a less pressured environment than an office. This week I've been working on a new user interface with my company so I check where we got up to refresh my memory.

By 9:30 am I'm usually ready to get down to business. Mind you, a JavaScript developer doesn't actually code for 8 hours a day. In any real-world job, there is a lot of investigation, meetings, and learning apart from actual coding.

At 10.00 am is the Daily Standup meeting, where my team members and I meet on Zoom. We catch up on what we did the previous day, what we'll be doing today, and whether there are any blockers. The Scrum Master usually runs this call and it shouldn’t take more than 15-20 minutes. If there are things that need more attention from the Scrum Master, they'll meet the person after the meeting to discuss them further.

Starting to Code

After the meeting and another quick coffee (don't judge me, I'm not a morning person), you should be all set to start working on a new feature, an improvement, or a bug fix. At my company, we work in Sprints that last for 2 weeks during which all of this work is done and the application gets a new release at the end of it. The 2 weeks comprise of development, testing, and release. This isn't specific to JavaScript Developers alone, but most developers follow this method of project management.

Speaking of Project Management, all the issues that are being worked on are listed on a tool like JIRA. This is where all the information about a particular ticket is housed and this is your first point of entry. For a new frontend feature in JavaScript, the feature ticket in JIRA should ideally contain the mock-ups from the Design Team, the acceptance criteria, and the point of contact for any queries. The acceptance criteria are the base for the logic that needs to be implemented.

For a JS developer developing a login user interface, the acceptance criteria may contain points like “While entering the email address it should check if it is valid on the fly and show a notification to the user”. How to design the notification and how it should be displayed will be present in the mock-up.

There are times when a JS developer needs to use their intuition rather than relying on mock-ups and the acceptance criteria. As I mentioned, it isn't always that these are present in a ticket. In such cases, you should look at the existing application and try to fit in the new feature as close to the existing style as possible. I tend to code for about an hour or two before going for lunch. (Sometimes I like to just sit down and crack on though, so it all depends on my mood and the flow of work.)

Meetings, meetings, meetings

I hate to say it, but the more you code, the more meetings you'll probably have. The blessing in disguise is that WFH, I'm in much more of a comfortable environment to take the meetings.

There's often several meetings throughout the day – some planned, some unplanned. If you are a Senior JS developer, you might need to mentor some of the new joiners or junior JS developers. I also liaise with other teams to get work done.

If you're a Kunior JS developer, you might attend trainings that are mandatory and meetings with their managers to keep track of their progress. I don't particularly love meetings (I feel more productive without them), but as I mentioned - they're a little better whilst WFH.

Wrapping Up

Once all the meetings are done, I tend to have time to code for another hour or two before wrapping up your day. Towards the beginning of the Sprint, I like to make sure that I have all the information required to start working and complete the ticket successfully.

If you're a JS developer like me this includes the mock-ups, any assets, styling information, internal documentation regarding the feature, etc. If it's a bug reported by the testing team or the end-user, it's important to have the steps to reproduce it, any logs or screenshots, and the point of contact.

Before ending my day, I'll try to reply to emails, messages, or queries from other team members. If this is the end of the Sprint, there'll be a call with the stakeholders to demo the feature I've developed so that they can sign it off. This will ultimately go to production during the release. By 6.00 PM I'm usually ready to log off, grab a coffee (or tea if I'm trying to wind down) and enjoy the rest of my day.

And that's it! A very ordinary day in the life of a remote Javascript Developer. Ready to step into a new Javascript role? Sign up for hackajob here.

Like what you've read or want more like this? Let us know! Email us here or DM us: Twitter, LinkedIn, Facebook, we'd love to hear from you.