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-каналах. Последнее увлекает особенно сильно. Потому что, в отличие от божественной непостижимости узоров пламени, в информационном хаосе разобраться, конечно же, можно. Я, например, регулярно получаю анонимные письма от самых активных из тех, у кого это прекрасно получается. В своих письмах они подробно и убедительно анализируют геополитическую повестку, находят виноватых (обычно это евреи) и, в целях безопасности, требуют уничтожить письмо сразу после прочтения. Менее буйные писем не пишут, но, если их спросить, без тени сомнения расскажут, что происходит и кто виноват.