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.

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