I don't lean frontend or backend
I've coined a term for this - ambidextrous engineering.
I never really got the "frontend" or "backend" labels we use as engineers. Or really, while we're at it, any labels. QA Engineer, Sales Engineer, Design Engineer, etc. - not that the work these people do is weird, but why do we place engineers in these unecessary boxes?
We like to call ourselves "problem solvers", so tell me. Why does a keen interest develop in considering one a (insert label here) engineer?
I've aimed to become an ambidextrous engineer, which I like to define as being affluent in the entire stack. (FE, BE, DevOps, etc.)
On this Page
Why I stopped picking a side
My journey started on the backend. In school, our first programming course was C++. I quickly fell in love with the language, and the power that came with it. Pointers, syscalls, virtual memory — it was all so fascinating to me. I did dabble in iOS and exploit development in my free time, but at the time, this was all I knew.
However, as I grew, I started to get more and more interested in the frontend. It's funny cause people would come to me with app ideas, and it felt sad that I couldn't do anything about it.
The true shift occurred when I did my first full-stack project NyumatFlix. With no one to pass the baton to, the choice was stark: learn the backend or fail to ship. And that was one heck of an effective motivator.
What the helly ™ is an "ambidextrous" engineer?
Well, it really depends on who you ask. Of course in penmanship, many will say it means being able to write with both hands. In engineering, some might say it means being able to work on both the frontend and the backend.
I think it's a combination of all the definitions. In simple terms, it means that I can do work comfortably on each portion of the stack.
I can write JSX markup, make a distributed message-passing system, build a rendering engine for a game, and I can design a database schema.
I'm not suggesting that you should be able to do everything on the stack, but I think it's important to be able to work where the need arises. It's allowed me to be more productive, and to understand the big picture of how things fit together. I also started making cooler stuff simply because I could.
Remember. The benefit isn't that you know everything — it's that you can ask better questions everywhere.
It's not all perfect though
Naturally, breadth can hide shallow knowledge. I keep a running list called 'Things I hand off to experts without shame.' It currently includes nuanced terraform, keyframe animations, and cryptography. Let's talk about some of those woes:
My brain gets tired from switching contexts. Exhaustion is real!
Always try to batch similar tasks together to stay sane!! I generally keep it to 2-3 projects a day. If I'm constantly switching between projects, I'll be unable to get into a flow state.
Tasks that are hard to split up end up eating up more time
I've found that some tasks are hard to split up. For example, let's say I'm building a shell like Fish. I can't really work on redirection, piping, and job control until I've finished tokenizing, parsing, etc. This idea shows up often in various contexts, even outside this systems programming example - trust me.
To no surprise, some companies still prefer deep specialists over generalists
In an age where AI is making everyone a generalist, some companies still prefer deep specialists. And I predict it only will get more pronounced as time goes on. I try to keep a "U", "V", or "T" shape in my knowledge - where there's a set of topics I'm really good at, and a broad set of topics I'm at least somewhat familiar with.
To be clear, I'm not suggesting everyone must become ambidextrous; deep specialization remains crucial in many areas, as I said.
However, if you're driven by solving problems from start to finish, this approach is incredibly rewarding and, at times, the critical factor between being stuck and successfully shipping.