Most of What We Call Progress

Most of what we call progress in software is just motion. New tools, new frameworks, same problems. Maybe fancier logos. Yusuf Aytas watched a colleague set up Apache Spark for a modest analytics job. Dataset was small. Requirements intimately known. Complexity completely unnecessary. Asked why. Answer: "Because it scales." That moment stayed with him. Not because Spark was wrong, but because he realized how easily engineers confuse capability with necessity. After years in management, still feels like an engineer. The illusion of progress often looks exactly like progress: more systems, more layers, more abstraction. Feels like forward motion until it's not.

Early in career, cleverness feels like proof of skill. Shorter code, more elegant abstraction, you feel you've outsmarted the problem and maybe everyone else. Used to believe that too. Best engineers wrote code you had to study twice to understand. Unfortunately clever code doesn't scale. Not across time, not across people. What feels ingenious becomes a small trap for whoever inherits it next, including your future self. Someone will wholeheartedly say "what the fuck is going on here?" When you're debugging late night incident and reading your own comments from two years ago, clever loses its charm fast. Simplicity is not the absence of sophistication. It's evidence of mastery. Clarity compounds like everything else. One clear decision enables ten more.

Software is craftsmanship. Learn it from books or courses but not all. Learn it by building alongside someone with different experience. Not necessarily years but sometimes just the stack they worked with. Watch how they think, how they name things, how they stay calm when system crashes. Those are things that make it memorable. Abstraction teaches structure. Apprenticeship teaches care. Good systems, like good people, survive on both.

Good ideas start pure. Then someone turns them into a process, and that's when they start to rot. Agile was born from rebellion, handful of engineers tired of bureaucracy from unfit waterfall. TDD was the same. Call to slow down and think. Both were tools for clarity. Somewhere along the way, they became economies. Certifications, coaches, metrics. Agile died the day it became a job title. You can follow every Scrum ritual and still move nowhere. Hit 100% test coverage and still 0% confidence or understanding. Follow every process to the letter and still turn smart people into spectators. Process doesn't save bad culture, it amplifies it. Dogma starts when we mistake the tool for the truth. When ritual matters more than result. When following the "right" method feels safer than thinking for yourself.

Every engineer eventually overbuilds something. Think you're being smart, thinking ahead, building for growth. Before you know it, you've created a system ten times heavier than your actual problem. Keep designing for imaginary futures, for scale that may never come, call it engineering. But it's not engineering. It's over engineering. Industry rewards it too. Nobody gets promoted for keeping things small and sane. Get promoted for complexity, for showing initiative, for saying microservices and distributed. Over engineering doesn't come from stupidity. Comes from ambition and fear. Ambition that wants to prove mastery. Fear that wants to look prepared.

Experience humbles taste. Stop craving freedom and start craving stability. Realize the boring stuff (type safety, documentation, process) is what lets you take real risks somewhere else. For long time, questioned why PMs existed. Both product and project. Used to see them as blockers, layer between engineers and the work. Then led teams. Realized how much of day vanished into coordination, context switching, glue work nobody saw. That's when it clicked: good PM isn't there to control engineers. They're there to protect them. Buy them time. Filter noise so they can think. Good ones translate business goals into product decisions. Connect dots others don't see. Know why something matters, not just when it's due. Absorb chaos so rest of team can stay calm. Bad ones make noise. Good ones build silence.

Every system that failed on his watch didn't break because of missing tests or weak design. Broke because someone didn't talk to someone else. Misaligned assumptions. Undefined ownership. Decision left hanging too long. Real work isn't technical. It's relational. Likability, trust, alignment, consistency. Invisible but they make the difference. Can patch systems, but can't patch silence. In beginning, you want to prove yourself. Want code to stand out, process to be smartest, architecture to be cleanest. Want people to notice. Then spend enough time in industry and start to see what actually lasts. Not clever abstractions, not big launch, not tech stack you once defended like religion. Simple things that keep working long after hype dies.