A Day in the Life of a Frontend Developer at Useberry
•
9 min read
Follow a day in the life of a Frontend Developer at Useberry, from morning coffee and standups to focused coding, code reviews, UX collaboration, and one final git push at the end of the day. Sarah shares how product development at Useberry blends clear thinking, teamwork, and a lot of personality.
Hello everyone,
I’m Sarah, a Frontend Developer at Useberry.
My day usually starts with coffee, some mildly chaotic developer energy, and a quick mental scan of whether I’m walking into a feature day, a bug day, or a “why is this one tiny thing acting like it pays rent here?” kind of day.
I’ve been working in web development for more than a decade, across freelance work, full-stack roles, e-commerce teams, and CRO projects in Greece and the UK. So by now, my process is pretty simple: understand what the experience needs to do, build it, test it, break it a little, fix it, and keep going until it feels smooth. At Useberry, that mindset fits right in, because the goal is never just to ship something. It has to make sense, work well, and feel right for the people using it.
And that is pretty much what my workdays look like. A lot of building, a lot of thinking, a lot of collaboration, and just enough jokes to keep the codebase from getting too serious.
9:30 AM: 🚨 Code Coffee
Before I even get to my desk, there’s an important stop to make. I grab coffee at our local coffee shop, which has unofficially become the Useberry morning meeting point for the Berry devs and designers. It’s one of my favorite parts of the day because it doesn’t feel like the day has fully started yet, but it also kind of has.
It is usually a mix of catching up, joking around, and we usually avoid “shop talk” during this time although it is not a rule or anything. You know how stolen fries taste better, right? Coffee tastes better when it comes with a side of frontend gossip.
10:00 AM: Set up, check the list, warm up the brain
Once I’m in the office and settled in, I start by looking over my task list.
I check for anything left from the day before, anything new that has come up, and what I want to tackle first while my brain is still fresh. This is usually a quieter little setup window, with some light office chat in the background before the daily standup starts.
I like this part because it helps me get a read on the day. Sometimes I know exactly what is ahead. Sometimes I open a task and immediately remember that past Sarah was a bit too optimistic yesterday..
There’s also usually a bit of back and forth with the team around this time. A quick “did you see that?” or “I’ll check that in a minute” kind of rhythm. Nothing too dramatic yet. The drama comes later, if a component decides to develop opinions.
10:30 AM: Guardians of the Frontend, assemble
Yes, that is really what we call our frontend group chat. At 10:30, we have our daily frontend standup. That’s where the frontend team checks in, shares updates, raises blockers, and gets aligned on what everyone is working on.
This is also one of the points in the day where Chris, our Lead Developer, helps keep things moving in the right direction. If something needs prioritizing, if there is a technical question hanging in the air, or if a task needs a second opinion before we commit to an approach, that usually comes into focus here. Chris is very good at helping us cut through the noise and get to the practical next step, which is always appreciated before everyone disappears into their own tabs for the next few hours.
Standup is not a huge dramatic event, but it is important. Frontend work might look like individual work on the surface, but it is connected to everything. One update can help someone avoid losing time. One blocker raised early can save an afternoon. One tiny UI detail can turn into a whole conversation if you let it (sometimes it does, even if we try to not let it).
11:00 AM: Code reviews, quick investigations, and the first real decisions of the day
If anything comes up in standup, this is usually when we start pulling at the thread.
Sometimes I sit down with another developer to investigate an issue. Sometimes there is a quick follow-up with Chris to sanity-check an approach or talk through the cleanest way to handle something before it grows into a bigger task. Sometimes it is time for the first peer code review of the day, which I actually really like doing early while everyone is still sharp.
Morning code reviews are underrated. Your eyes are fresher, your patience is higher, and your brain has not yet been hit by twelve unrelated thoughts and three browser tabs you forgot were making noise.
This is also when development gets very collaborative very quickly. You start by reviewing code, then suddenly you are talking about behavior, states, empty cases, interaction logic, or one tiny thing that feels off but you know will matter once it reaches real users.
That is one of the things I enjoy most about frontend work. It sits right in the middle of product logic, UI details, and UX reality.
12:00 PM to 2:30 PM: Proper focus mode
This is my main focus block.
This is when the metaphorical do not disturb sign goes up and I get into the real hands-on work. Building features, fixing bugs, refining UI, cleaning up components, making things clearer, faster, smoother, or less likely to randomly misbehave.
Usually our tasks are already clear by then, which helps a lot. Everyone knows what they are working on, so the energy shifts from talking to doing. That is my favorite mode. Head down, music on, coffee still doing its job, and a good chunk of uninterrupted time to actually make progress.
🌟 Last couple weeks, I have been receiving reminders to write this article riiight in the middle of this block.. thanks for that Yigit.
Some days, the focus block becomes collaboration time
Not every midday stretch is pure coding. On days when we have cross-team meetings, that is usually when the designers present future ideas or upcoming features so we can talk through them together.
George, our Head of Design, will walk us through the thinking behind a feature, the user need it is trying to solve, and the flow they have in mind. Then we start asking questions from the development side. What states do we need to account for? What happens when the data is missing? Can we simplify this part? Is there a better way to make the interaction clearer? That back and forth is where a lot of good decisions happen.
It is not design on one side and development on the other. Everyone trying to get to the best version of the same thing.
3:00 PM: Break time, because staring harder is not a strategy
Around 3:00 PM, I usually take my break.
I like this time because the kitchen is quieter, which means I get a bit of actual me time after a long stretch of coding. No tabs, no tickets, no one asking me whether a spacing issue is small or spiritually significant.
Just a small reset.
I’ve learned that stepping away for a few minutes is sometimes the most productive thing you can do. There are definitely moments where I have been stuck on something, taken a break, come back, and immediately seen the issue. Apparently the brain enjoys drama and likes to solve things only after you stop begging it to.
3:00 PM to 5:00 PM: Back to coding, pair work, or figuring things out with people
The afternoon usually depends on what is scheduled.
Sometimes I go straight back into coding and keep moving through my tasks. Other times this is when pair programming happens with another developer, or I sit down with a designer to work through a UX solution in more detail.
These are usually the more dynamic hours. Less isolated focus, more back and forth. Maybe we are splitting work on something. Maybe we are refining an interaction. Maybe I’m sending an update to the rest of the team so everyone knows where things stand. Maybe George and I are looking at a flow and trying to make sure the experience feels simpler in the product than it did in the first version. Maybe Chris jumps in because there is a smarter implementation route and we would all prefer that over inventing new problems for ourselves. Maybe its Maybel.. nope not saying that.
That’s a big part of the rhythm at Useberry. You spend part of the day executing, and part of the day shaping things together so execution stays pointed in the right direction.
There is a lot of focused work in development, obviously, but there is also a lot of talking, checking, joking, aligning, and occasionally sending messages that are basically “I fixed it” followed by “never mind, I fixed a different thing.”
5:00 PM and after: Final countdown
From around 5:00 PM until the end of the day, it is usually one final block of coding, a bit of code review, or a sweet snack reward on a successful day (sometimes the whole team like to order croissants together).
I like that this last part of the day can shift depending on what is needed. Sometimes I want to wrap up a clean piece of work before I log off. Sometimes I use the time to review something for someone else. Sometimes it is a good moment to slow down a bit and spend time on personal development. (sometimes a nap might be needed.)
Then comes one of the most satisfying moments of the day: the final git push. It is small, but it always feels important. That is the point where the day’s work stops living only in my head and my local environment.
Around 6:00 PM, I log off, and leave everything else to be a problem for future Sarah.
Why I enjoy it
What I enjoy most about being a Frontend Developer at Useberry is that the job is never just about code. There is a lot of focus in the day, but there is also a lot of personality. A lot of energy. A lot of collaboration. A lot of moments where someone asks a very good question at exactly the right time. I think that balance is what makes the work feel good. You are building seriously, but you do not have to become serious all day long to do it well. Did I mention the fun? Yea, we have some fun during the day.
So yes, that is my day in a nutshell. Secure coffee. Meet up with the Guardians. Build things. Fix things. Observe something unexpected. Laugh a bit. Push code. Repeat.
Want another peek behind the scenes?
If you enjoyed this one, you can also check out our previous article in the series, A Day in the Life of a Product Designer at Useberry, where George shares how his workday moves from early inspiration and UX thinking to design decisions the whole team can build on.
