Structure and organization of a software system
Over the years, I have encountered dozens of developers who passionately advocated for TDD. They spoke about "confidence in code" and "clean architecture." Yet, when I looked at their projects, I saw bloated teams, slow development, and tons of code that no one understands. In 2014, the creator of Rails publicly buried TDD. The creator of the methodology acknowledged its limitations.
In Kazakhstan, there's an epidemic: everyone is a senior by the age of 25. LinkedIn is filled with titles, resumes shine, yet in interviews, a person can't explain why they chose PostgreSQL. "Well, it's the industry standard." The problem isn't with the people. The problem lies in a system where grades have become a bargaining tool for salary, rather than a reflection of real competencies.
С детства я люблю читать. Настоящее чтение требует концентрации: ты погружаешься в текст и не замечаешь ничего вокруг. Программирование это тоже про чтение. Код, документация, архитектурные решения, чужие баги. Лучшие программисты, которых я встречал, не гении алгоритмов, а усидчивые люди, способные часами разбираться в чём-то сложном.
Three years of development. Hundreds of abstractions. Architecture as a work of art. Zero users. Familiar? I've seen dozens of such projects from talented programmers and even technical directors. They call it "quality," but in reality, it's fear. Fear of criticism, fear of evaluation, fear that someone will see imperfect code. I analyze the mechanics of self-sabotage and how to escape it.
While some shout that AI will kill the programmer profession and others stubbornly ignore the trend, Boris Cherny is building tools that define the future of development. He advanced to Principal Engineer (IC8) at Meta, wrote a book on TypeScript for O'Reilly, and then created Claude Code, leading its development at Anthropic.
Complexity rarely appears by accident. It is acquired—sometimes for real reasons, but more often to look professional, hide mistakes, and diffuse responsibility. Microservices before the first paying customer. Kubernetes for two services. "Universal platforms" that fit no one. Behind this is not an engineering necessity, but the fear of looking naive.
A few years ago, I told my colleagues that focusing on algorithms and exotic language features was a dead-end path. They didn't understand me, and during interviews, I was bombarded with questions about merge sort. But I continued on my path: front-end, back-end, DevOps, mobile, architecture. Now the market is beginning to understand the value of this approach.
Microservices are not a silver bullet. A story from personal experience: how blindly following the hype led a team with 20+ microservices to failure, and why a timely assembled modular monolith turned out to be the only salvation for a project that had already been written off.