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.

How does your team review ideas, project proposals, or paper drafts? Imagine I’m on your team and I need a budget allocated to a new project. I craft a proposal, elucidate the motivation, assess the risks, develop a plan, and then what? Do I create a PowerPoint presentation, present to my teammates for half an hour, answer their questions for another half hour, hear their honest feedback, after which they vote and a decision is made? If this is how things are organized within your team, you risk stifling creativity and motivation.

Если верить историкам, сначала были империи, императоры и рабство. Затем империи пали, потому что им стало стыдно, и наступили темные годы средневекового феодализма, который в какой-то момент всем просвещенным людям наскучил, и “под вопли новооткрытых краснокожих” наступило Новое время, а затем и Возрождение. Рабство не сразу, но отменили, демократию тоже не сразу, но внедрили. Всем бывшим рабам раздали равные права, напечатав для них законы и конституции. Царей и императоров либо повесили, либо переименовали в “конституционных”, освободив таким образом личность от гнета других личностей, а зря…

At times, it might appear practical to execute additional initialization steps for an object after its constructor has completed. However, I’m of the belief that such requirements signal underlying design flaws, such as object mutability, base class fragility, violation of layering, and unfocused abstraction. A constructor should be good enough for all scenarios. If it’s not, refactor the object.

Method overloading is a common feature in many programming languages that allows a class to have two or more methods with the same name but different parameters. According to Microsoft, method overloading is “one of the most important techniques for improving usability, productivity, and readability of reusable libraries.” I disagree. In my opinion, method overloading may lead to less readable code and more bugs, because maintaining two or more implementations under the same name gives rise to concealed semantics, which inevitably result in misunderstandings and functional defects.

When you find a bug in an open-source library that you use, what do you do? You submit a GitHub issue (or whatever ticket tracking system they use). In the issue, you describe the problem in the best possible way, preferably providing a working code example that the author of the library can run locally to reproduce the bug. If you don’t provide them with an executable snippet of code, they will most likely ask you to do so, unless the bug is trivial. I suggest simplifying the workflow and giving them what they want right in a pull request: send them the bug in the form of a disabled unit test.

According to a study conducted by Dariusz Jemielniak in 2007, the majority of programmers perceive their own managers as highly incompetent. We don’t expect our bosses to be coding-savvy—this level of technical competence is not a requirement for an average manager. Additionally, we don’t expect them to excel in Gantt Chart wizardry or adhere strictly to risk management protocols—these are management practices that are not commonly observed in software teams today. Instead, what we do expect from them is the ability to gauge our productivity: recognizing and rewarding the best performers while taking action against those who are less motivated. Unfortunately, this is a management competence that they lack… or perhaps, fortunately.

I don’t know what programming language you use, but my experience of recent coding in Java, Ruby, JavaScript, PHP, Python, C++, and Rust tells me that the principle, which I will try to convince you to adhere to—is universal for all languages. It’s about the naming of test files. It may look to you like a question of low importance, but let me try to demonstrate that it’s not. How do you name your files with test classes? How many of them do you create in the src/test/java directory? Where do you place a class that is used only in a test but is not a test by itself? To most of these questions, the answer most of you would give is “Whatever!” So let’s try to find a better answer.

It often happens, especially in Java, that a few places in the method are potential exception originators. Usually, we make a large method-size try block with a single catch at the bottom. We catch all the exceptions, usually even using grouping. This helps us minimize the noise, which is the exception catching. However, such large try blocks jeopardize maintainability: we are unable to provide proper error context inside catch blocks.

Sometimes we rethrow exceptions. In Java we do this more often than in other languages, because it has checked exceptions. Sometimes we must catch and rethrow a few exceptions that originated from different places in a method. Java 7 introduced grouping of different types of exceptions in a single catch block. But even without the grouping, it is possible to just catch IOException or even Exception and provide a single catch block for all types and all originators (methods that throw). Recently I realized that this is a bad practice. Here is why.

My first academic paper was accepted and published in 1998. My most recent one was rejected by SPLASH just a week ago. I’m writing two papers right now and co-authoring about ten others. So far, my results are very poor: way more rejections than I expected. The key lesson I’ve learned so far: the reason most papers get rejected is not because they are essentially wrong. Instead, reviewers reject them because they have no enthusiasm for decrypting a poorly structured text, even though it may contain potentially interesting thoughts. In this blog post I suggest how to structure a research paper. Take it with a grain of salt though.

A few months ago I made a small Java library, which is worth explaining since the design of its classes and interfaces is pretty unusual. It’s very much object-oriented for a pretty imperative task: building a pipeline of document transformations. The goal was to do this in a declarative and immutable way, and in Java. Well, as much as it’s possible.

I suggested this idea a few weeks ago on Twitter and got mostly negative reactions. That’s why I wrote this blog post, to elaborate on the subject in an attempt to convince you. Here is the rule I’m suggesting: always submit changes to the code separately from the changes to its unit tests. Simply put, in one pull request you modify the tests, maybe marking some of them as “disabled.” You merge this pull request and then make the second one, modifying the code and most probably removing the “disabled” markers from the tests. You don’t touch the body of the tests in the second pull request.

A few years ago I created xcop, a simple command line tool that can check the style of an XML file. It’s similar to Checkstyle (for Java) and Pep8 (for Python), but for XML. It’s pretty easy to use xcop: just run it with a few command line arguments and it returns the list of errors found in your XML file, if there are any. However, some of the arguments may be convenient to have as defaults and instead of passing them through the command line on every execution, we could store them in some configuration file. The question is: What is the best format for this file? YAML, JSON, or TOML? None of them! I suggest plain text.

Automated tests are the ones that are usually called unit tests or integration tests, or just any tests that are being executed automatically. That’s the difference between them and manual tests. What is the purpose of automated tests? First and foremost, they reduce the amount of routine work: we don’t need to remember how to test a module, the tests remember. We just click a button and a suite of tests, which may consist of hundreds or thousands, runs and reports errors, if any are found. Saving time is important, but it’s not the only and, if you ask me, not the most important purpose of automated tests. A more important one is their role as a safety net.

When I make a slide deck for a new presentation, invent a new domain name, think about a name for a new Java class, itemize bullet points in an academic paper, even write an email—I try to follow a simple principle which helps me make my content more solid. Well, at least I believe it does. Maybe it will help you as well. The principle is simple: at all costs, try to squeeze the content into one word, one sentence, one paragraph, or one page.

Reflective programming (or reflection) happens when your code changes itself on the fly. For example, a method of a class, when we call it, among other things adds a new method to the class (also known as monkey patching). Java, Python, PHP, JavaScript, you name it—they all have this “powerful” feature. What’s wrong with it? Well, it’s slow, dangerous, and hard to read and debug. But all that is nothing compared with the coupling it introduces to the code.