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.

For each accepted explanation of a phenomenon, there may be an extremely large, perhaps even incomprehensible, number of possible and more complex alternatives. The principle of parsimony, also known as Occam’s razor, suggests we prefer the simplest one. For example, “I can’t open the door and can’t attend the meeting” is a description of a problem, which could be reduced to “I can’t open the door” without losing any information, which might be important for those who are waiting for me in the meeting room. I suggest applying the same principle to bug reports.

A few days ago, DeepMind (acquired by Google in 2014) released AlphaCode and self-published a paper explaining how their artificial intelligence (AI) can “understand” a programming contest task written in English and then write a Python, Java or C++ program, which would work in about 30% of cases. Earlier last year OpenAI ($1B-funded by Microsoft in 2019) released Codex and published a paper, claiming that their AI can also solve around 30% of the programming tasks it was tested with. Wired, the Financial Times, The Verge and many others have already announced the victory: AI will replace programmers and we are all going to lose our jobs.

A few months ago I got an opportunity to teach a single course for 3rd-year BSc students at Innopolis University (Russia). The title was “System Software Design.” The size of the group was about 150 people and the duration was 8 weeks. I was supposed to give them sixteen lectures, two lectures per week. And I was asked to examine their knowledge by the end of the course. Pretty much a normal job for a university teacher. And you know, in my opinion, I failed most parts of it. Here is what I learned.

Since the time of Kernighan and Ritchie we share binary code in libraries. You need to print some text with printf() in C++? You get libc library with 700+ other functions inside. You need to copy a Java stream? You get Apache Commons IO with copy() and 140+ other methods and classes. The same happens in all languages I’m aware of, like Ruby, Python, JavaScript, PHP: you need an object, or a class, or a function, or a method—you have to add the entire library to your build. Wouldn’t it be more elegant to deal with individual objects instead?

It’s a well-known problem nowadays: how can we measure the performance and productivity of individual contributors who do non-routine creative work? The best examples are research and development (R&D) teams, which usually consist of software engineers, designers, scientists, architects, quality experts, product managers, and so on. Such professionals deliver results that are hard to get down to simple numbers. Many authors argue that the very idea of measuring individual performance is toxic and may only lead to negative consequences. We tried to challenge this point of view and did an experiment in our team, which demonstrated that individual performance can indeed be measured, even if people’s work involves creativity, and results are hard to predict. We designed a system of Calibrated Achievement Points (CAPs), which are rewarded to those who deliver visible and tangible results of different kinds. This article explains how CAPs work and summarizes the results of the experiment.

Here is a very simple management framework, which we have used in our teams for the last two years. We came to it experimentally, trying to merge some Agile principles, PMBOK ideas, and common sense. Our experience so far is positive, even though the proposed rules of work are not really about project management, but more about keeping an eye on the situation and making sure it’s not falling apart. This is the best most modern teams can afford anyway.

Logging is an inevitable part of debugging. Well, at least in modern high-level programming languages and architectures. It wasn’t thirty years ago, in Assembly, but it is now. Sometimes we trace variables, but rarely. More often we just print them to console. Moreover, we don’t just print them using println or whatever it is we have for console printing; instead, we send messages to a logging framework, which deals with the console or any other logging destinations, like files. The beauty of such frameworks is that we don’t need to remove logging after debugging is finished—we just configure the framework to suppress all debug-level messages in the production environment. Some logging may happen inside unit tests. Do we also leave them there or maybe not?

Making constructors pre-process the arguments before encapsulating them seems to be bad practice. However, very often it’s necessary to do exactly that: perform some manipulations with the objects provided as arguments and only then assign them to the attributes of the constructed object. For this purpose I suggest using prestructors, which could be methods or stand-alone objects.

Recruiters, you know what we programmers think about you, don’t you? Read this and this, to get the full picture. You are still here because we still don’t have good tools and we still enjoy being enslaved. One day this will be over and you will stop exploiting our drawbacks, will lose your “Senior Recruiter” jobs, and start doing something useful and meaningful. However, until this day comes, here is some advice, to help you be a less annoying better head hunter.

First, let me clarify what kind of conference we are talking about. There are two types: professional and academic. The difference is huge. My understanding is that professional conferences are for practitioners, while academic ones are for researchers. ICCQ, which we organized this year, was an academic conference. I haven’t had any expertise in organizing such things, and had to go through it all for the first time. Here is a more or less detailed description of the journey. Feel free to learn from it and make a better conference yourself. We will try to make a better one next year, ICCQ 2022.

The time of objectivity is fading out. Meritocracy is now a rude word. Metrics in management will soon be considered as harassment. Productivity is already a false objective. It’s time to start taking advantage of this era of nonsense. The era of impostors is coming! Don’t miss the opportunity to become a great one. Here is a quick summary of key techniques to make you highly successful in any argument you may have in your flat democratic organizations of the future without any skills, knowledge, education, or real achievements. Just pure love and emotions.

There are three things in EO (and the 𝜑-calculus which we based it on): data, atoms, and objects. There is a dataization function, which puts all three together in order to make an EO program alive. Here is how it works together with Java, for example.

You have an objective, a budget, and a team. You are a manager and you want the project to be done. You get your team together in a meeting room to discuss the plan. You tell them what needs to be done and ask them how fast they can do it. Then, you do the motivational dance and beg ask them to commit. They nod and go back to their cubicles. Of course, after a few months of “hard work” all the milestones are missed and you get back to the planning meeting. And, yes, you pay their salaries anyway.

You got into a company that believes in democratic values, doesn’t measure performance, doesn’t judge, doesn’t control, doesn’t force, and doesn’t blame; however, at the end of the year they tell you that your performance was not as high as expected. Why? “Just work better, my friend, we count on you!” Bad luck, you are in a teal self-managing organization. They’ve already killed the management, but still didn’t dare to kill the managers. They don’t know how to measure, but still have people who are supposed to do it regularly, in order to distribute monetary rewards. What do you do before you quit? Here is a survival recipe.

We are in trouble. On the one hand, most managers are weak and incompetent. Their mistakes destroy our motivation, decrease productivity, and lead to business failures. As a result, many of us believe that managers are evil. On the other hand, there is a new idea that self-managing organizations are the future. Its proponents are trying to convince us that chaos is better than management mistakes. They want us to believe that subordination, hierarchy, control, and order are new bad words to be prohibited in a respectful society. We must stop them!

How do you create objects in your object-oriented language? Let’s take something classic, like C++, Java, or C#. First you define a class, and then you make an instance of it. The first step is known as abstraction, and the second one as instantiation. A similar pair of operations exist in functional programming: declaring a function is abstraction, while calling it with specific arguments is application. The question is: why does OOP need classes and objects, while FP survives with just functions?

What do you think an object is in OOP? No matter what language you are programming with, you will most probably agree with Bruce Eckel, the author of Thinking in Java, who said that “each object has a state and operations that you can ask it to perform,” or Benjamin Evans, the author of Java in a Nutshell, who claimed that it is “a collection of data fields that hold values and methods that operate on those values.” However, hold on… What if I told you that an object may have no “operations” and still be a perfect “equivalent of the quanta from which the universe is constructed,” as David West suggested in his great book Object Thinking?

Последние примерно 400 лет, со времен Локка, мы живем под флагом свободы, равенства и братства. Сейчас уже трудно представить себе человека разумного и при этом всерьез отрицающего важность свободы личности, ценность человеческой жизни, добродетельность социального равенства, драгоценность мира, дружбы и любви. Казалось бы, эти понятия — основа нашей морали. Они были с нами всегда и останутся навеки. Однако, предлагаю посмотреть глубже и разобраться в том, что же такое свобода, и во благо ли она нам.

In 1974, Liskov and Zilles defined a strongly-typed language as one in which “whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function.” Strong type checking, without doubt, decreases the amount of type errors, which leads to higher quality. However, the question is: do we really need types in order to strongly enforce typing?

A few days ago I asked my Twitter followers to vote in a simple poll. They did, screaming in comments that only a stupid incompetent manager would ask programmers to send daily reports, while everything they do can easily be tracked in tickets, Git history, and so on. Indeed, why on earth would a sane manager ask software engineers, already very busy with coding, to spend time on writing these ridiculous reporting emails? Let me try to give you a good reason.

Encapsulation, as you know, is one of the four key principles in object-oriented programming. Encapsulation, according to Grady Booch et al., is “the process of hiding all the secrets of an object that do not contribute to its essential characteristics.” Practically speaking, it’s about those private attributes that we use in Java and C++: they are not visible to the users of our objects, that’s why they can’t be modified or even read. Booch et al. believe that the purpose of encapsulation is “to provide explicit barriers among different abstractions,” which leads to “a clear separation of concerns.” However, does it really work as planned? Do we really have explicit barriers between objects? Let’s see.

Do you know the most typical mistake startup founders make when they pitch their ideas to investors? According to Jake Mendel from Silicon Valley Bank, they often focus on the solution they propose instead of the problem they are trying to solve. Inability to identify the problem is the common cause of startup failures. However, it’s not only them. Look at your project and try to answer “What’s wrong with the world now?” and then “How is this product fixing it?”

Do you use LaTeX for your academic and technical writings? You don’t? Well you should! It’s the most only professional instrument for making properly formatted PDF documents. MS Word and Apple Pages are for secretaries non-tech people, while LaTeX is serious. It’s perfect in so many ways, thanks to Donald Knuth (the creator of TeX) and Leslie Lamport (the author of LaTeX), but it lacks one very convenient feature: spell checking. The only solution I’ve found so far, which works perfectly for my documents, is GNU aspell.

Here is a short list of common courtesy rules for open source software development. Actually, they apply elsewhere also, but they are most visible when you do GitHub-based coding. I strongly believe that sooner or later all programming will be open source and these rules will apply to everybody. Consequently, it makes sense to start following them now, whether you are an active Apache contributor or a happy owner of the “Java for Dummies” book.

Расизм, антисемитизм, национализм, шовинизм, сексизм, гомофобия, и прочие формы внутривидовой ксенофобии представляются Конраду Лоренцу, автору книги “Так называемое зло”, наиболее серьезной из всех опасностей, угрожающих человечеству в современных культурно-исторических и технических условиях. Лоренц считает их результатом внутривидового отбора, действовавшего на наших предков десятки тысяч лет, а Эрих Фромм в своей книге “Анатомия человеческой деструктивности” — одним из главных препятствий на пути человеческого прогресса. Что делать и как это зло искоренить?

The question was asked on StackExchange nine years ago (just around the time the site was launched): “If not lines of code, then what is a good metric by which to measure the effectiveness of remote programmers.” The answers, not surprisingly, were all along this line: programmers are not supposed to be measured! I bet those who answered were programmers themselves. Indeed, why would a programmer be interested in being measured and being reduced to a mere number?

25-го мая в городе Миннеаполис (Миннесота, США) темнокожий 46-ти летний больной коронавирусом Джордж Флойд в состоянии фентанило-метамфетаминовой интоксикации, покупая сигареты, попытался расплатиться поддельной $20 купюрой, за что был задержан и вскоре убит белым полицейским. Это было зафиксировано камерами телефонов случайных прохожих и стало поводом для массовых беспорядков по всей территории США под эгидой BlackLivesMatter движения и с лозунгом “I can’t breathe” (я не могу дышать). Давайте разберемся, почему и зачем это произошло.

Here is a new idea I discovered just a few days ago while working with Codexia, a Ruby web app. I had to fetch data rows from PostgreSQL and return objects to the client. It’s always been a problem for me, how to do that without turning objects into DTOs. Here is the solution I found and gave a name: Veil Objects.

It’s time to answer one of the most popular questions I hear from junior programmers when they meet me at a software conference or online: What is the point of studying Elegant Objects (the new object-oriented paradigm I’ve been preaching for the last five years) if almost nobody is using it on real projects? Why swim against the current and learn something that may only harm my career, even if it does seem like a sound technical concept? Where is the profit in making myself an outsider? These are good questions; thanks for asking them!

Some companies massively invest in open source software projects, while others still remain skeptical and stay away from this trend. What’s in it for those philanthropists, like Google, IBM or Microsoft? Why spend money on something that doesn’t belong to them and is shared among all of us developers? Don’t they understand that the code they write may be used by their competitors? It seems they do understand, but can’t do anything about it.

Ни для кого не секрет, что эпидемия коронавируса — это искусственно созданная истерия, ни к вирусам, ни к эпидемиям никакого отношения не имеющая, а ее авторы преследуют цели, совершенно не связанные с охраной нашего здоровья в мировых масштабах. Я заблуждаюсь, и вы уверены, что дела обстоят именно так, как нам рассказывают Коммерсантъ и Голос Америки? Тогда дальше можете не читать, будет неинтересно. Если же вы, как и я, не верите в массовый психоз и хотели бы разобраться в его истинных причинах, давайте попробуем.