A day in life of a senior (UI) engineer

I am a Lead Frontend Engineer in a team of 13 people at Redbox.
Redbox is a streaming service, we offer a wide variety of movies and TV shows on demand. Those of you in US might recognize the name from the red kiosks all around for renting DVDs and Blurays.

Being a streaming service we have apps covering many TV platforms, Samsung, Vizio, LG, VewD, PS4/5, Xbox, Roku, and more to come.
Our main projects are native Roku app, and web app that supports every other platform besides Roku.

But business occupies a whole spectrum, from customer facing, to internal tooling. My team has about 10 projects we maintain.

I often encounter beginners that think seniors write thousands of lines of code daily, deploy it to millions of users, and somehow it is all stable all the time by itself.
I even forget I was once a beginner that thought something similar.
But, those of us in the "trenches" know better.

So, how do engineers manage to create stable apps people use every day?
How does a day of a senior frontend engineer look like?

Step 1: check email

So, my morning starts simple enough.
I quickly check my email. It takes 5-10 minutes, I got stuff organized in folders so I can make easier and quicker sense of stuff.

Step 2: check metrics

I move onto taking a short look at Grafana charts for performance of our backend services that my (frontend) team maintains. These are small in terms of backend code, but important, as they deliver stuff like feature flags and various misc content from CMS(like Terms & Conditions texts).
We do have alerts setup for critical scenarios, but that doesn't excuse not manually checking for trends.
This is what some of these charts may look like, they're fed by Prometheus into Grafana.
We got error percentage, Redis used memory, event loop lag, and so on.

Step 3: check bug monitoring

After that, I move onto the bug monitoring.
We use Bugsnag.
Again, alerts for critical stuff are setup here too, but manual checks are desired.
There's a timeline of bug trends and view of bug events themselves, with all the good stuff like stacktraces, breadcrumbs, custom event data an app might attach, etc.
Unhandled errors are setup so they automatically open bugs in Jira, handled stuff usually not. But, just because an error is handled, does not mean it's okay for it to occur. It might, for example be a symptom of some issues at the backend, like on the data sync side.

These 2 monitoring steps are not something that all team members are required to do every day, but we encourage everyone to be comfortable with them.

Step 4: deployments

Next, if there are any deployments to be done, I like to do it now.
This is not something I alone do.
We encourage everyone to be comfortable with the process of deploying to production. As in CI/CD, deployment is something to be seen as (daily) routine, not a big deal.
After merge to master, Jenkins builds our code, and when build is done Spinnaker automatically deploys it to staging.
Test automation starts running right away on freshly built stage instance, and our manual QA folks are automatically alerted by a webhook in a chat about the new build in staging, so they can pick it up too.
Once everything is greenlighted, production is just a click away in Spinnaker.

Step 5: code reviews

After all these usually short endeavors, I move onto code reviews. Since we have many projects, that are in separate repos, we have a Gitlab CLI utility that lists open merge requests on all our projects.
This is what that looks like, it's a simple script but quite helpful.
We have a rule, code review takes priority if you're in between tasks, and having opened merge request more than a day old is considered a red alert for taking up code review.
This is because we embrace the trunk based development, with short lived branches only.
Merge request => code review => merge to master/main => test => deploy as soon as possible.

Step 6: daily team meeting

After this point, we usually have a short daily meeting.
A short status update and getting rid of various misc doubts and blockers people might have.
We encourage people to also do this by a chat at any time they have doubts about some approach and would like to get a consensus from team.

Step 7: actual coding

And finally, we got to the actual coding.
I'm not going to get into the details of coding, but just an overview of the process.
Every one of our projects has it's own Jira board, but as a rule we don't venture there for picking up a task, as that would be too chaotic.
We have a team Jira board, that pulls tickets from all Jira boards of projects our team maintains.
A master board, if you will.
As a developer, this is your taking off point.
In this board, priority is by sorted top to bottom, so developer doesn't have to go "window shopping" for a ticket. First ticket in TO DO column is yours for the taking.
We are doing Kanban with a backlog, also called Kanplan.
The spin is we embrace what is called zero bug policy. Meaning, bugs can't be in backlog, and they take priority over stories/features.
This does not mean our UIs have literally 0 bugs at all times, or at any one time for that matter, only that bugs don't get to live happily ever after in the backlog. We either fix the bug ASAP, or declare it as not relevant and close it.

Step 8: afternoon meetings

In the afternoon, as a lead I usually attend some meetings.
This is usually for various planning/grooming purposes with product people.
We all know how fun this is, so we try to spare other team members from it as much as possible.

Step 9: misc

Some other things that can pop up here and there.

Triage, which I sometimes do by myself, but also bring in other team members when needed. We have no strong rules here, we do it when and if it is needed when bringing tickets from backlog into TO DO world.

Retrospective once a month to review our team practices and processes, and try to improve.

Feature flags are setup for most of major features, with optional A/B testing. As soon as work on a major feature is started, feature flag for it is set up. In this way, doing parts of a new feature and opening small merge requests is doable, because unless feature flag is turned on, partially done feature won't be visible to users. It goes hand in hand with trunk based development, since everything is on master/main and in production all the time, but we have control over what users see.

Step 10: And that's pretty much it. Now you know (almost) everything

Thank you for your attention and take this inspirational quote to go.
”What one programmer can do in one month, two programmers can do in two months.”

• Frederick P. Brooks