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.