Four Engineering Lessons I Didn't Learn From Frontend
Support work, deployments, and distributed collaboration taught me lessons that frontend never could.
When I started my career as an Engineer, I thought engineering meant output. Success looked like building features, writing clean code, and delivering fast. The more output, the better the engineer. And that is what I believed.
Looking back, the most useful engineering lessons didn’t come from frontend engineering at all. They came from places that I considered unrelated and non-engineering.
Process Friction
The first lesson came from my earliest role. It was a process-oriented role. The work itself wasn’t glamorous. A lot of process, a lot of repetitive executions, a lot of coordination.
At that time, I thought I wasn’t learning anything relevant. But over time, I noticed something. Small inefficiencies created large delays.
One unclear email, one missed email attachment, one missed checklist item, one delayed response.
None of them felt important to me. But together, they slowed the entire process. Without realizing it, I learned my first engineering lesson: “Small friction compounds”.
Execution Friction
Years later, I moved into software engineering. Everything felt exciting. I was finally building frontend, features, and deliverables.
It was a startup where speed mattered. At first, I felt this as pressure. But later I realized something different. “Speed forced prioritization”. I stopped polishing everything. I stopped looking for a perfect time. I prioritized things. That period taught me something precious: “Throughput is not always about hard work. Sometimes it is about reducing unnecessary work”.
Operational Friction
A few years later, I was spending time outside Frontend, which is my core domain. At first, I resisted it; I wanted to stay close to Frontend works. Instead, I found myself dealing with things that looked operational.
One particular activity repeatedly blocked the progress. It was a deployment process that was blocked the whole time. The process was manual and time-consuming. People accepted it because “that’s how it worked”. Eventually, I automated it. What used to take two and a half hours dropped significantly.
The biggest realization wasn’t the time saved, but the impact of one improvement repeated over multiple people becomes larger than the individual effort. That changed my way of thinking. I stopped asking “How can I finish it faster?”, and I started asking “Why does this need to be repeated?”
Support Friction
More recently, I’ve been spending time in support and operational conversations. Initially, I saw this as moving away from Engineering. Then I noticed a pattern. A specific question was repeatedly asked in the product’s support forum. This consumed my attention. I started wondering, “Why do these questions appear at all?” Could the system communicate it better? Could the documentation improve? That was another shift. “The best support request is often the one that never needs to happen.”
Looking back, the lesson wasn’t that frontend engineering became less important. I still enjoy building interfaces. Over time, my definition of engineering changed. Engineering is partly about building; it’s also about reducing friction. Reducing friction for teammates. Reducing friction for users. Reducing friction for systems.
