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.
We have a list of books in the books object. How do we remove a single book from it, given that we know its ID? We can do books.removeById(42). Alternatively, we can find it with books.findById(42) and then call b.remove(). Which option should we prefer, and why? The second choice is the better one. Not only because it’s more object-oriented, but also due to several practical advantages.
Automated tests help us write code faster. Unit tests immediately tell us when we break something. Integration tests calm us down, reducing the fear of shipping a failure to a user. But who are “us”? Programmers. What about our employers? How do automated tests help them? Automated tests protect their investments.
A few weeks ago, @horw released a new GitHub plugin that fixes GitHub issue titles: issue-title-ai. Once an issue is created, the plugin asks ChatGPT—or DeepSeek, or Claude—to improve its title. We’ve already integrated the plugin into objectionary/eo and a few other repositories. Works like a charm. What’s wrong with the titles the way they are, you may ask? Why do we need to ask ChatGPT to make them “better”? Because we want every issue—either a bug report, a feature request, or a question—to be formulated as a complaint. It seems that very few of us can do it on the first try. The help of AI is appreciated.
Wikipedia says that Bug Driven Development (BDD) is an anti-pattern. Raja Shankar Kolluru perfectly explains why. However, Florian Rappl argues that it’s not. Ben Winding believes that it’s better than TDD. In simple words, BDD is kind of like trying to build a plane while it’s flying, based on passenger complaints. Nobody builds planes like that (well, maybe Boeing and Airbus). However, a software team that practices BDD might demonstrate higher productivity.
Every ticket—a bug report or a feature request—is a short-term contract. You, the reporter, hire them to make a fix or implement a feature. They, the team of developers, do it for you—provided you pay, or their motivation is intrinsic—for example, in open source. The discussion that happens along the way may help clarify the requirements of the contract. It may also help the team convince you that the bug doesn’t deserve a fix. Also, it may help them deliver the fix to you and convince you to close the ticket. However, the discussion may also distract both parties if it loses focus.
Someone has submitted a bug report to your repository. You fix the bug. You close the bug report. Stop. This is wrong. You shouldn’t close it. Instead, you should ask the reporter to review your fix. Then, maybe, they will close the ticket. If they don’t, you make another fix, until they do.
What do you think is the most typical reason for delays in pull request reviews? A study at Google confirms that it’s the size—the more changes, the slower the review. Another study shows that it’s the emotional tone—anger and dominance expressed in comments are linked to a lower likelihood of a pull request being merged. A more recent study finds that it’s the author’s reputation: we merge PRs faster if we know the author. All of the above is true. In our projects, though, what often slows down PR reviews is the message: “CI failures are not related to my changes!”
How long should it take to know if your code is safe? Martin Fowler once said: 10 minutes. Ten years later, five hundred developers agreed. I disagree—with all of them. First, ten minutes is not enough for a proper build, even for a small software system. Second, ten minutes is too much for a build that we run from the IDE after every one-line edit. We need a finer-grained classification of builds: from bullet-fast to thorough and dead slow.
My first attempt to contribute to an open source repository was a miserable failure. I picked a Java repository I was already using (Glassfish Jersey), created a unit test for an existing class, submitted a patch (there were no pull requests at that time), and… it was merged. I got excited and submitted another unit test in a new patch. No surprise, the repository owners asked me to stop fooling around: apparently, they didn’t need unit tests just for the sake of it. I quickly lost interest in making changes to anyone else’s code bases and started working on my own stuff instead. Don’t repeat my mistake! Becoming a contributor to an existing code base is a much faster path into the open source world and is far more rewarding. Here are some things to keep in mind to make your journey to success even faster—especially if you are just a beginner making your first pull requests.
Можно бесконечно смотреть на три вещи: как горит огонь, как течёт вода и как политические новости сменяют друг друга в любимых Telegram-каналах. Последнее увлекает особенно сильно. Потому что, в отличие от божественной непостижимости узоров пламени, в информационном хаосе разобраться, конечно же, можно. Я, например, регулярно получаю анонимные письма от самых активных из тех, у кого это прекрасно получается. В своих письмах они подробно и убедительно анализируют геополитическую повестку, находят виноватых (обычно это евреи) и, в целях безопасности, требуют уничтожить письмо сразу после прочтения. Менее буйные писем не пишут, но, если их спросить, без тени сомнения расскажут, что происходит и кто виноват.
How would you design a class that abstracts, say, a file on a disk with certain properties? Let’s say you need to be able to check whether the file exists on the disk or has already been deleted. Would you create an object first and then call the exists() method on it, or would you call Disk.fileExists() first and only then, if TRUE is returned, make an instance of the File class and continue working with it? This may sound like a matter of taste, but it’s not that simple.
One of the most frequently asked questions I hear from junior programmers (no matter their age) is: What should I focus on now to build the best career I can? There are multiple options, including creating a startup, getting a PhD, contributing to open source, working for Google, and many others. In my opinion, the most common mistake is trying to get rich fast. Obviously, money matters and is the ultimate metric of career success, but trying to get it too early is nothing more than gambling with your life at stake. Instead, I suggest focusing on winning some “medals,” which can later be converted to cash, not the other way around.
If you, like me, are not a patent attorney and don’t understand patent law, but your boss asks you to turn your recently written piece of code into a patent, read on. The boss most probably won’t ask you to write the entire patent. Instead, he will ask you to prepare a quick summary of the invention (usually, a few slides) and then a hired lawyer will turn it into a full-scale patent application. If you understand the purpose of patents, the mechanics of patent offices, and the format of a patent claim, you will do just fine.
А знаете, какое самое популярное по числу просмотров видео на YouTube? Вот это. 14 миллиардов просмотров за менее чем семь лет. И таких видео много. Задаюсь вопросом, о чем эта песня? Чему она учит? Какой вообще в ней смысл? С моей точки зрения, сформированной когда-то давно сказками Сергея Михалкова, Самуила Маршака и Агнии Барто, в этой песне смысла нет. Но ведь он должен быть, раз её посмотрели и оценили по достоинству сотни миллионов родителей и детей! Нет, не должен. Всё просто: что сейчас нравится миллионам, то и является эталоном качества. Но ведь так было не всегда.
Я не историк и даже в школе историю не любил. Не любил, но верил, что так все и было: и Французская революция, и восстание Спартака, и война Аттилы с Римом, и охоты на мамонтов с последующими иллюстрациями на стенах древних пещер. Все это было именно так, как рассказывали нам учителя истории (они в моем детстве почему-то часто менялись). Позже, когда появился Internet, я узнал о Новой Хронологии и стал скептиком — перестал верить на слово тому, что говорят историки. Стал в любом описании событий прошлого искать альтернативные версии. Еще позже я узнал, что это называется конспирологией и в порядочном обществе осуждается, Пелевин не даст соврать.
There is a big difference between distributed and collocated teams: the communication in distributed teams is asynchronous, which essentially means that when you ask something, a response doesn’t arrive immediately. Moreover, it may never arrive. This can be very uncomfortable for those who are used to the office work setup, where most communications are synchronous: any question is answered immediately, one way or another. In open-source repositories, everything is asynchronous. Here is a simple rule that may help you decrease the level of frustration in GitHub projects: ping them every time you need an answer or attention to be paid to your code.
Say, you are a student, and I’m your teacher. Your task is to conduct an experiment or a study and then write a research paper about it. You can do it on your own and then present me with the results in the end. Sometimes it may work, but most probably it won’t. I will have many comments, suggestions, and plain simple disagreements with your research questions, results, or conclusions. Just like in software engineering, the Waterfall approach is not an effective one. Instead, an incremental and iterative workflow may yield way better results: you take a small step forward, we discuss it, you rewrite, we agree, and you take the next step. The ultimate objective is to write a paper that will be published in a good journal or presented at a decent conference. Well, yes, a passing grade is also an objective.
Уже несколько лет мы проводим в России научную конференцию, приглашая в ее программный комитет ученых со всего мира. Последние два года, по понятным причинам, отказов много, особенно от западноевропейских ученых. Однако, интересно вот что: если раньше отказы содержали субъективный негатив вроде “I don’t want to participate in a Russian conference” (я не хочу участвовать в российской конференции), то последнее время они все звучат примерно так: “I can’t speak at your event” (я не могу выступать у вас на мероприятии). При всем уважении к драматизму ситуации, мне все же интересно, понимают ли уважаемые ученые, что те свободы, которыми так гордится европейская цивилизация, несовместимы с выражением “I can’t speak”, особенно из уст людей науки?
I do enjoy ChatGPT a lot. The blog post you’re reading now was written by me and then given to ChatGPT to fix its grammar and polish the writing style. Until recently, since 2014, when I wrote my first blog post, I used the service of a few proofreaders, who charged me $20-40 per hour to rewrite all of my 350+ texts. Now, I pay a few dollars a month to OpenAI. However, while the value of this generative AI is obvious, I also experience serious harm from ChatGPT, especially when reading papers written by my students with its help.
I’m helping organize the ICCQ conference this year for the fourth time, with the in-cooperation support of the IEEE Computer Society. Based on this short-term experience, I can assert that reviewing research papers is a skill that even some reputable and experienced academicians either don’t possess or are too lazy to apply. We often encounter sketchy, subjective, and disputable reviews that don’t assist authors but only frustrate and discourage them. In this short blog post, as an absolute amateur in the subject matter, I will try to summarize how to review an academic research paper (thus mostly helping other newbies).
Almost every empirical research paper contains two essential sections: Results and Discussion. The former presents the facts collected through the research method, while the latter interprets them to answer the research questions. When interpreting the data, you must address the most obvious concerns that readers may have. For example, in the Results section, you might state: “85% of respondents refused to participate in our survey” (this is a fact). Then, in the Discussion section, you might say: “We believe that programmers are innately lazy and irresponsible” (this is an interpretation). You might also add, “Perhaps not all of them were lazy, but just busy.” While the Results section leaves no room for doubt, summarizing findings “as is,” the Discussion section engages in an open debate with an imaginative reader.
Let’s say you are conducting research to discover programmers’ opinions about their work environments: whether they appreciate their office spaces or not. Preparing a survey with a few questions is essential. Their responses will reveal their thoughts and feelings. After working with several student groups, I’ve noticed a common mistake in questionnaire design—they are too obvious with their questions, simply asking, “How do you feel about this?” There’s a more effective approach.
An email, a document, a research paper, a presentation, and even a JavaDoc code block consist of paragraphs, which are “self-contained units of discourse in writing dealing with a particular point or idea.” Visually, paragraphs are supposed to be separated by a vertical space that is a bit larger than a vertical spacing between lines. To achieve this, for example, in HTML, we wrap paragraphs in the <p> tag, while in LaTeX, we use \par or just an empty line between them. However, some people insert what are called “soft line breaks” inside paragraphs—this is a bad practice that I suggest you stay away from.
Every empirical research paper must have a section titled “Method” (or “Methodology,” or “Study Design”). In this section, you describe what was done to obtain the data presented in the following “Results” section. You explain the recipe, which may be replicated later by another researcher, leading to the same (or very similar) results. You tell the reader what ingredients you used, how you mixed them, and—most importantly—why.
Кому из нас не хочется быть яркой индивидуальностью? По крайней мере, считать себя таковой. Однако не каждому это под силу. Современное развитое общество победившей свободы совести поощряет стремление каждой личности к индивидуальности, доводя этих несчастных личностей до психологов, коучей, психиатров и антидепрессантов.
In almost any research paper, it is mandatory to have a section titled “Related Work” (or “Related Works”), where you refer to the results previously obtained by other authors or yourself. By including this section in your paper, you are not only paying respect to those who laid the foundation for your results, but also motivating and guiding your readers. Most of them may not be aware of existing studies or the importance of the problem you are solving. You must put these guys into context.
A friend of mine recently asked me what five things he should do in order to grow his technical career in a big company. He is not interested in being a big manager, or a CEO. Rather, he wants to be a software expert, an architect, an owner of a technology, and eventually a “Fellow.” I’m not sure I was qualified to give such advice, but I did anyway. This is what I told him. Maybe this will also work for you.
Служба Безопасности Украины (СБУ) арестовала Игоря Коломойского. Ему вменяют незаконный вывод более 500 млн гривен за границу в 2013–2020 гг. Коломойский — президент Объединенной еврейской общины Украины, вице-президент Федерации футбола Украины, экс-глава и член Европейского совета еврейских общин, президент Европейского еврейского союза (EJU), а также основатель Приватбанка, самого крупного банка Украины, имеющего свыше 22 млн клиентов. Что же происходит, какие версии?
Almost every document you may write in LaTeX format will have a list of references at the end. Most likely, you will use BibTeX or BibLaTeX to print this list of references in a nicely formatted way. It is also highly probable that your .bib file will contain many typographic, stylistic, and logical mistakes. I’m fairly certain that you won’t find the time to identify and correct them. As a result, the “References” section in your paper may appear sloppy. I suggest using the bibcop package, which identifies mistakes in the .bib file and auto-fixes some of them.
The release of ChatGPT 3.5 has changed everything for us programmers. Even though most of us (including me) don’t understand how it works, some of us use it more frequently than Stack Overflow, Google, and IDE built-in features. I believe this is just the beginning. Even though, only Microsoft knows what will happen next, let me try to make a humble prediction too. Below, I list what I believe robots (with Generative AI on board) will do in the future. The further into the future, the lower on the list. I tried not to repeat what GitHubNext is already saying.
Несмотря на технологические чудеса от Boston Dynamics и OpenAI, человек продолжает убивать себе подобных. Казалось бы, после Второй Мировой войны и создания ООН в её завершение, мы должны были отречься от агрессивных инстинктов. Ожидалось, что мы пойдем по пути мира и созидательного труда. И мы действительно пошли. Но не все. Кому-то поручили создавать Интернет и искусственный интеллект, а кто-то продолжил “бороться за свободу и независимость”. Стоит признать, стратегия сработала: iPhone, Blockchain, ChatGPT и десятилетия стабильности доллара США — тому подтверждение.
In order to reveal errors of higher complexity, automated tests are turned into integration tests that involve external resources in test scenarios, instead of their mocks. While this approach improves test coverage, it slows down the entire build pipeline. This compromises the very idea of automated tests, which are meant to be a safety net and help programmers edit code safely. Splitting the tests into “fast” and “deep,” and then allowing humans to run the former while servers run the latter, might be a good solution to the problem.
