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 imposters 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 EOLANG (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?

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.