What do front-end developers do every day?


I am an aspiring front-end developer and I have been doing it as a hobby for a while now but have never had a full-time front-end developer job.

I was wondering what the day-to-day looks like for a front-end developer/engineer and also if this type of role changes depending on the size of the company (startup vs big tech company for example).


1 Like

This is something I think @senocular, @travis, @steve.mills, and @tbo may have a lot to share on! :stuck_out_tongue:

1 Like

Great question @sephorus. I work for a very small agency, there are only about 20 people so I imagine the experience would be much different at a large company. In my job I am extremely autonomous most of the project’s I’ve worked on has been either by myself or with one or two other developers. I have a few meetings weekly with project managers, sometimes with clients but other than that it’s 100% self directed work. I’m very lucky in my situation, I think I have more flexibility and autonomy in my role then is typical.

Project managers work directly with clients then create tasks for developers which I estimate. After the feature gets approved I just start working on it. If it’s a project I’m working on with other developers I will submit pull requests which are reviewed by at least one other dev. If it’s a project I’m doing my self I generally merge pull requests on my own after thoroughly testing a feature, sometimes if something dosen’t feel quite right or if the feature is pretty big I will loop in another dev for a second set of eyes. I think this would be drastically different at a bigger agency/company. Larger companies have whole teams dedicated to testing and QA so your pull requests would be reviewed by far more people and take a bit longer to be merged into production.

I hope that helps a bit, if you have any more specific questions about the work, lifestyle, or technical questions about the stack/tools I work with I’d be happy to provide more answers.


On the other side of the spectrum, there’s me, working for a large company with around 24,000 employees. Overall, though, the experience is not entirely all that different.

There are product managers which are largely responsible for the requirements of a product or feature set. They are in tune with customer needs, doing interviews and presenting ideas, etc., as well as work devs and others to get an idea of what we want to get done and what can be done.

Often at the start of a project devs will work with them to develop specs and define DoDs (Definition of Done) so that we know what we’re doing and what it takes to know that we’re done. Devs are also involved in their own explorations making PoCs (Proof of Concept), exploring possible technologies and various approaches or implementations to see what is possible and what will work, or just see if something cool can be done that we can slip in because they had a good idea and thought it might be easy to do. Project managers largely steer the ship, but devs can have influence too.

When everything is decided, we have tasks in our issue tracking software that get assigned out to the devs for them to work on. We have 2 week sprints where they’re given a certain amount of the tasks in the larger backlog collection to complete, and teams will meet every 2 days (though some teams may meet every day or less than every 2) to cover what was accomplished and what blockers anyone ran into that’s preventing them from getting their work done.

The dev work can vary. You may be working on something brand new or be working on older, more legacy code, doing more maintaining than creating. Most of the projects are fairly large, even when they’re new. Having so many people means there’s usually a large number of people working on the same thing so even new projects can seem to get bloated quickly. And even new things can depend or rely on the old or be made of older components so you never know when you need to break out those ES5 Backbone skills.

Depending on what you’re working on, completing a task could require a lot of research. This may include research on approaches out in the wild (google) or finding out how things are already being done in the massive codebase you’re working in. Some internal documentation may exist, but it’s largely non-existent or out of date. Sometimes things can move so fast its not worth doing documentation early and then things are too far along for anyone to want to do it from scratch so it just doesn’t get done. We’re trying to be better about it but so far it hasn’t been working out :–P

Once a task is completed, it gets submitted as a PR (Pull Request). Automated systems kick in to make sure it can build correctly and doesn’t fail any of the tests, then human reviewers will read over the source code and check to make sure its good. When it is, someone from QE (Quality Engineer) will go over and make sure it actually works right and does what it should in a working stage build. Once that gets the ok, it gets submitted to the mainline branch and work on the next task begins.

Depending on the project, new releases could happen every few days, or take months. Every time you submit code it needs to be complete and in working order since it may go live. It’s ok to add incomplete code, but only if its not user-facing. For example for larger features you may submit a small part of the feature that the user never sees just to get it reviewed and checked in. You generally want to avoid having massive PRs because they’re harder to review.

Then the whole thing starts all over again.

After a few years, your product might reach its end of life and you’ll be moved on to something else,
or you may move as a result of re-org or if you simply decide you want to work on something else. The company is large enough that its not hard to move people around if they’re unhappy with what their working on now and managers are usually very understanding (though this is easier for larger teams than the smaller ones). I myself have worked on about a half-dozen projects throughout my 16-ish years at this company, though some do more than that, and others less.


I’m at the other end… a team of 1.
I do small business web sites for people (usually referred).

TBH I spend most of my time doing my own projects.

Most small business’ are happy with a template sites that they can modify.

I spend most of the build time ensuring that the site gets all greens in Lighthouse/ accessibility/ structured data.

If they want graphic design/ photo shop ect, I know a person that I refer.

I get the client to use Cloudflare worker sites/ pages to host and Cloudflare workers to run a basic CMS of sorts.

Right now I’m re structuring so I do all the hosting/ CMS ect.


For what it’s worth, you might aspire to be a front-end web developer and end up either preferring or ending up in a career that involves backend work, or native work, etc.

Answers to your question might even prompt you to consider a career path that’s modified by the answers in this thread. Don’t close anything off too early.