Claude helped me write this. Mostly quotes and fact-checking. I catch myself wanting to stress the “mostly,” and that is the whole subject of this essay. It’s September 2026. By September 2027 I don’t expect to be using Claude to write blog posts. Because I don’t expect there to be blog posts by me to write. I won’t be a writer. I won’t be a programmer either. And I don’t know what a man is for, after that.
How to get promoted? How to get a salary raise? How to stop writing code and start managing other losers who still write it? How to become a team leader, a boss, a Vice President, a CTO, and a CEO? Is it a matter of luck, or can some tactics help you get to the top of the career ladder? Let me share a few lessons I’ve learned.
Management gurus keep saying everyone must own the business result. BCG wants every company to build an “ownership mindset” at all levels. Each employee must feel responsible for the firm’s outcomes. Patrick Lencioni, in The Five Dysfunctions of a Team, calls “inattention to results” the worst sin a team can commit. He wants us to give up our own goals for the shared number. They want the bottom line to belong to all of us. I disagree.
Since the release of Opus 4.7 in April, I don’t write code by hand anymore. I only talk to Claude Code. Not because I’m lazy or don’t like coding, but because he is a better programmer than I. Also faster and much cheaper. However, for most tasks I can’t let it fly solo in an “auto mode.” Because his standards are lower than I would expect even in a junior developer. He is like Mowgli: smart and strong, but rude and clumsy. My job is to teach him elegance, my way. And unlike with most developers, with him I can do this.
People have been arguing about how to indent code for as long as there’s been code, and nobody has settled it. Java’s Checkstyle aligns continuations under the open paren, ESLint and Prettier each invent their own rules, Go’s gofmt uses tabs and shrugs, RuboCop hands you a menu, Python’s PEP 8 picks four spaces and leaves the rest to taste. Every tool has its own dialect, and teams waste hours fighting over the details. I suggest a simple rule of monotonic indentation for source code of any programming language:
Between any two adjacent lines, indentation may increase by exactly one unit.
This rule should resolve most disputes about code formatting style. It is easy to add as an extra check to any existing style checker, or to deploy on its own as a small standalone tool.
Someone submitted an issue to one of our open GitHub repositories a week ago, suggesting a new feature. We didn’t respond, since we didn’t notice it. Today, someone else submitted an implementation of the feature in a pull request. I rejected it and explained that the feature request must first be accepted by the project architect, and only then would it be worth making a pull request. The author of the PR got offended. He won’t be back. Good. A year ago, we would have been sad to lose an enthusiastic contributor. Today, we don’t care.
When I was five years old, I inherited the shoes of my older brother. Not because our family was poor, but because the shoes were good. My grandma told me that when she was a fiancée her dowry consisted of a few skirts. Not because she was poor. She wasn’t. Because the skirts were good and rather expensive. Now, in 2026, to get a new pair of shoes or a new skirt, I just buy them at a mall down the street. I don’t hesitate to throw away the old ones. The same will happen with the software, thanks to AI coding agents.
It seems to be popular to design websites as Single Page Applications (SPA). Instead of showing a new HTML page on every click, an SPA sends a lightweight skeleton with JavaScript. The JS makes HTTP requests, receives JSON, and injects data into the DOM. On each user action, the page doesn’t reload—only the DOM changes. Such an architecture, once a response to slow browsers and unreliable networks, is now a bottleneck. The page is built of fragments, each requiring its own HTTP request. No matter how fast each request is, the multiplication diminishes all optimization efforts.
Writing code documentation is a pain. Not writing it leads to even bigger pain—we can’t comprehend the code. However, writing it and then forgetting to update it causes the ultimate pain: it lies and confuses us. How about we cure all three pains at once: prohibit all comments! How do we know what the intent of the code is if we don’t have any comments? We ask an LLM to explain it to us. What if the LLM fails to explain and confesses its inability? Then, we automatically fail the build and blame the author of the code. Thus, we introduce a new quality gate: Code Interpretability Score. The build passes only if this score is high enough.
In 1995, Brendan Eich was hired by Netscape and asked to create a language for their HTML browser. Rumors say, he designed Mocha in 10 days, later renamed to LiveScript, and then to JavaScript. It was planned to make it similar to Scheme, a LISP-syntax language. Instead, to please the crowd of C++/Java coders, it was made syntactically similar to Java. In 2008, Brendan made a tragic mistake: he donated $1,000 in support of Californian anti-gay marriage law. In 2014, he joined Mozilla as a CEO and the crowd remembered his anti-diversity gesture. He had to step down and founded Brave Software, the developer of the Brave browser. Somewhere around that time they started to kill JavaScript. Still doing it pretty good, thanks to recent ECMAScript updates and TypeScript.
Let’s say, you are a startup founder, like myself. Try to hire a sales guy. Offer him a commission-only payment scheme. Listen to his reaction: he will demand that you pay a fixed salary too, on top of commission. Try to convince him that commission-only is a more reasonable and motivating setup. Goto 1. After a number of iterations you realize that the mission is impossible. Sales people are good at selling and the best thing they sell is the idea that their time must be compensated. Even if they don’t sell the product to your customers. If you don’t buy the idea, they go find another loser who will. Something similar happens when you try to pay programmers by result. They easily convince you to pay for their time. And you do.
I don’t like monolithic repositories. They keep multiple projects together, often written in different languages, by different teams. Unfortunately, Google, Facebook, and Yandex favor them. Primarily, according to them, monorepos reduce integration overhead. They do, but at the cost of quality. In smaller repositories we can develop better code.
You’ve made a pull request, but it won’t merge. A reviewer says it’s not good or the tests don’t pass. No matter what, you can’t get it into the master branch. You keep fixing the branch, keep convincing the reviewer, keep hating the tests. Stop. Try smarter tactics.
In 2020, in the Junior Objects book I wrote this: “Windows is not suitable for programmers. If you meet anyone who will tell you otherwise, you must know that you deal with a bad programmer, or a poor one, which are the same things. Your computer has to be MacBook.” Now, five years later, I still hold the same opinion. This blog post is supposed to be less opinionated and, because of this, more convincing. The point is still the same: you either use Windows or you are a professional programmer.
In Soviet Russia, prisoner camps were divided into two categories: red and black. In a red camp, the power belonged to the prisoners who cooperated with the administration and helped it maintain discipline. In a black one, the power was in the hands of criminals who resented the rules, in permanent confrontation with the administration. It seems that in software companies we may also categorize employees into red and black. A red employee enjoys obeying the rules and climbs up the career ladder by making the boss happy. To the contrary, a black employee, while understanding the inevitability, despises the necessity to obey. Their career growth is driven by making the customer happy. Which one are you?
Type annotations are what make statically typed object-oriented languages like Java run faster and safer. Without annotations, every variable would effectively collapse to Object, forcing runtime casts. The code would work, but slower and with more runtime errors. Some type annotations may be inferred instead of being explicitly specified by a programmer. Not all though. In Java, for example, a number of hard-to-resolve challenges prevent us from inferring types of all objects. This is not a fundamental limitation of OOP itself. It’s a result of design trade-offs in Java and similar languages. In a perfect object-oriented language, all variable types would be inferrable.
