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.