A Day in a UI Developer’s Life

Attila Vágó
HMH Engineering
Published in
6 min readFeb 25, 2019

--

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. — Samuel Beckett

Java. That means coffee. It’s also a programming language. One that I don’t care much about. Java is as relevant to my daily job as shoes are to an elephant. And no, Dumbo doesn’t count. However, a nice mug of hot actual coffee in the fresh morning air of the 4th floor company terrace overlooking Silicon Docks is where it all starts for me. I’m a UI engineer, and I code what matters in Java… waaaait for it… Script!

Code what matters: the vision

There’s no two identical days, but what tends to be a common denominator is the overall vision. I am building one of the largest custom LMSs in the world, called ED. My work impacts students and teachers alike on a daily basis. When I do my job right, nearly 50 million students and teachers are happy 😃and when I mess up, it’s just as many sad emojis 😢expecting me to get my act together. That’s a lot of sad emojis if you ask me, so I try, throughout the day, every day, not to be the cause of it.

But how? Development from 9–5?

I don’t clock in, I don’t clock out, my only guide as to when the work is done, is our ways of working, industry best practices and frankly my own conscience. Since I work in an agile environment, the work is fairly well defined and just to make everything extra-super-duper clear I tend to gather the herd (the team) for a quick discuss and distill to clarify matters that the ticket might not cover, or needs further deliberation. It’s also an excellent opportunity to hear from other team-mates how they would tackle the problem, find out about gotchas or dependencies that weren’t obvious already.

The work itself can range from as simple as adding a few aria-labels and tab-indexes to existing code, to more complex ones where I might need to migrate an entire view or component from Angular to React or build one from absolute scratch, in React of course.

Keep pushing…

When pushing to one’s branch, I am always of the opinion that there’s no bad code, just lost code. Wrote a half-baked function and you’re going for a coffee? No matter, push the code, you never know when your computer breaks down or catches fire. It’s more common than you think and there’s no shortage of horror stories I can tell you. No matter the state my code is in, as long as it’s on my branch I like to know there’s a copy of it on GitHub.

Until it’s great!

The way I like starting a UI component for instance is to create a semantic folder, inside which lives at least one component file, a test file and a CSS file. By the way, the latest versions of React are now using css modules out of the box, just by naming your file fileName.module.css — great shtuff! It also comes with hooks, but I’m not really hooked on them just yet. 😉

Now, where things get interesting — besides coming up with the business logic of my component — is figuring what makes great code, great. After all, my code must work in the larger ecosystem, must be easy to understand for myself and other engineers, be that today or three years down the line, and must be robust enough to stand the test of time and tens of millions of users interacting with it. Just like airline pilots, I use a development checklist which helps me keep my code clean, testable and readable.

But is it really?

No checklist is good enough though on its own and a true software developer will always make an effort to test their code. I am a fan of test driven development, so I tend to try and write unit tests as I go. This of course adds to the time it takes to develop something, so I try and estimate accordingly. Write a few assertions, snapshots, write the code to validate the test and so on, until the feature is fully baked and satisfies the requirements. This is the moment I start feeling great about myself.

What about that edge case user?

You’d think unit tests being all green and passing is where the journey ends, but I’m hardly even halfway there. I mean it’s all nice and dandy and my component works, but what about its behaviour in the larger application? After all, I can’t nilly-willy just dump a new component into an app used by millions of people, ignoring user habits, edge use-cases and the fact that I am running it in conjunction with tons of other components.

Here’s where automated end to end tests come to the rescue. 🤠 I find them incredibly great, and give me peace of mind because I know there’s a much better chance things won’t break in production than if I had just relied on my own manual testing. Lately, I’ve started writing my own E2E tests and later consult a QA subject matter expert just to make sure I have someone vouch for the quality of my quality checks. That’s a lot of quality, innit? Well, unless you hear otherwise (and you won’t) quality is the best policy. 🤓

Or the disabled one?

So you’re probably thinking I’m done, ready to merge things, get the ball rolling out to production. Well, not by a long-shot. You might have not heard the news, but there are waaaay over a billion disabled people living all around us, trying to lead as normal a life as they can. But guess what, if we — software developers — don’t build accessible applications, the web is going to be a very inhospitable place for them. That’s even worse when you think of a classroom environment, where either teacher, student or both are disabled, but are trying to use the same education platform and consume the same content as everyone else. Statistically speaking in the US a whopping 13% of students are dealing with some form of disability in the classroom.

My process is very straight-forward and stress-tested. Run an AXE test at least once a day on my code. Resolve the issues it returns. While developing I always check if I am able to navigate my feature via keyboard. Finally, I fire up at least one screen reader and see if things read out actually make sense. All of this can sometimes feel tedious, extra work, but it’s so worth it.

OK, it’s probably great now… right?

Now that I’m satisfied with the looks and functionality of my UI and so is my designer, I ran the tests and everything is green, it’s time I submit my code for review. Back in the day I used to feel somewhat anxious, intimidated and possibly even scared of what happens when eeeeevryone else will start ogling at my code. It’s normal to want to look away, hide in a hole with all my fingers crossed, but that’s completely unnecessary. The PR process is set up in a way to enable learning, sharing, and no constructive criticism is meant to be taken personally. It’s there as a safety-net, an extra layer of quality check, and a fantastic opportunity to learn new tricks. By the way, did you know that getElementById doesn’t return a false but null when it’s not found in the DOM? I learned that via a PR of all things!

To Prod we go!

Now that all my peer review comments have been addressed and the code is truly great, it is time to release my code into the wild. Well, kind of… It doesn’t go directly to production. What?!? You heard me. No rookie mistakes like going from local to Prod in my book! There’s a journey to everything, and deployment has its own. If you like acronyms, it’s ITCTPT (Int > test > Cert > test > Prod > test). Yes, that’s how much I care about testing. And for good reason. Remember the prospect of 50 million sad emojis? Exactly… Now substitute those emojis with actual people. 😱

Raise your glass to a job well done!

Of course, with all that good work done, preparation and peer reviews, testing, testing and more testing, the chances of something breaking in Production are fairly low, so I get to pack up, head to the nearby pub and celebrate with a nice cold lager.

Attila Vagosenior software engineer at HMH, writer of codes, blogs and things that live on the web. Programming polyglot, pragmatic doer, with a passion for all things JavaScript and accessibility. An easily inspired inspirational individual with a strong predilection towards most things nerdy, great food, craft beer, and Lego. Uses a Mac. Exercises at 6 a.m.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Published in HMH Engineering

HMH Engineering builds fantastic software to meet the challenges facing teachers and learners. We enable and support a wide range of next-generation learning experiences, designing and building apps and services used daily by millions of students and educators across the USA.

Written by Attila Vágó

Staff software engineer, tech writer, author and opinionated human. LEGO and Apple fan. Accessibility advocate. Life enthusiast. Living in Dublin, Ireland. ☘️

No responses yet

What are your thoughts?