Помню, мне было четыре года. В детском саду был новогодний утренник. Разумеется, со сказочным Дедом Морозом и его не менее сказочной Снегурочкой. Сказка сказкой, но по завершению праздника я пытался объяснить родителям, что Дедом Морозом был на самом деле наш завхоз Иван Ильич. К сожалению, у меня тогда не было прямых доказательств, однако имелось несколько косвенных улик: уж очень были похожи голос, глаза и обувь сказочного персонажа на аналогичные атрибуты дяди Вани. Тогда меня очень огорчило нежелание родителей слушать мои доводы. Они уговаривали меня, что Дед Мороз настоящий, а завхоз, которого почему-то не было на утреннике, просто в этот день заболел.

If you look at the source code of Takes or Cactoos for the first time, you most probably, like many others, will be triggered by the naming convention, which implies that most class names have two-letter prefixes: BkSafe, RqFake, RsWithStatus, TkGzip, and so on. To be honest, I haven’t seen a single Java developer who would be comfortable with this convention at first sight. I have, however, seen many who are in love with it now. This article is for those who are interested in moving from the first category to the second one.

It seems that type/class hierarchies in OOP may be designed in two extreme ways: either with full encapsulation of data in mind; or with just a few interfaces making raw data visible, and letting classes deal with it, parse it, and turn it into smaller data elements. You may be surprised, but I’m suggesting the second option is more elegant. It seems to me that we don’t lose object orientation, but rather gain a lot of flexibility, reusability, testability, and so on.

You most probably know about Elegant Objects (EO), an alternative object-oriented paradigm, which claims that objects must be immutable, have no static methods, never use NULL in their code, use no annotations, and so on. We, the EO adepts, claim many things, but not so many people believe us. Those non-believers say that we are trolls, at best. Their main argument is: everybody works differently, why should we listen to you? I have no answer for them… well I had no answer, until I created jPeek and started researching object cohesion.

There are good and bad soldiers in any team. The job of a manager is to understand which is which. Then to promote the good ones and discharge the bad ones. There is one simple indicator I use to make this segregation. It’s a simple question I either hear from my people or don’t. Those who ask it are the bad soldiers. Their attitude and their behavior require immediate corrective actions. Some of them are curable, while others are not. This question tells me everything, if it’s being asked. I immediately understand that I am dealing with a loser if I hear it.

Being just yet another software developer in a large enterprise is a pain. You are surrounded by legacy code, inconsistent architecture, low quality standards (assuming they even exist), lack of coding discipline, broken or dirty unit tests, mediocre programmers, and so on. On top of that, the management is very chaotic: no strict plans, no task management, no objective metrics, no quality control, and no light at the end of the tunnel. You feel like a cog in the machine: arrive at nine, leave at five, be quiet, and paychecks will keep coming. If you are talented and ambitious, sooner or later you will start thinking about suicide resignation. But hold on!

По данным многих исследователей уровень тестостерона у американских и европейских мужчин неуклонно снижается в течение последних десятков лет. Тестостерон — это гормон, отличающий мужчин от женщин, а также более агрессивных и сильных мужчин от пассивных и слабых. Таким образом, массовое снижение этого гормона в крови мужчин говорит о том, что активных и доминантных становится меньше, а расстояние между полами сокращается. Возникает два вопроса: почему это происходит и кому это выгодно?

I’m not talking about those who are famous, well-paid, or the authors of big and popular products. They are not necessarily talented, even though their results are outstanding. Talent is something some of us have as God’s gift. Very few of us… otherwise it would not be called a talent. We all know what talent looks like in music, sport, poetry, or the art of acting. We can tell right off the bat who’s got it and who is faking it, no matter how hard they try. Can we do the same after a short interview with a programmer? I believe we can.

Altruism means selflessly giving others more than you take back, while egoism means selfishly taking more than you return. Modern theories of management and social life tell us that altruism means prosperity for the society and success to the project. In my book Code Ahead I claim the opposite: altruism hurts the society and kills projects. I truly believe that any group activity eventually collapses if it encourages altruistic behavior among its members, be it a project, a company, or a family. This is why one of the core principles of Zerocracy is #NoAltruism.

When you review a pull/merge request from someone, do you check out the branch and run the build? I usually don’t, but some people do. Their obvious reason is: running a build, or even testing the product manually, helps find more important errors. Just looking at the source code may not reveal all visual defects recently introduced to the HTML/CSS, for example. It’s better to check out the branch, start Apache, open the site in Chrome, and see what’s broken. Then, make a screenshot, attach it to the pull request, and return it back to the author. But I disagree with this, and here is why.

Which one is better: books.del(42) or books.book(42).del()? I do both and I rarely can tell which one is better. The first option is shorter, while the second one is more object-oriented. The first option is more difficult to extend, while the second one is more verbose and requires more lines of code, which means a higher chance of making mistakes. Which one do you prefer?

Here is the question I keep hearing almost every time I speak at a conference about object-oriented programming and my non-traditional understanding of it: “How do I convince the whole team to start doing everything so differently?” (asked here just recently). Indeed, it’s easy to change your coding habits and your software design if you are alone. What do you do if you are a member of a larger team where everybody is very happy with the Spring Framework and procedural programming? How do you change their coding habits? An even better question is: How do I not get fired while doing it?

I’ve been thinking about this since 2007, somewhere around the time S3 was launched by Amazon. I even tried to implement it a few times, but failed right after the design phase. I’ve heard about a startup, which tried to do it too, but also failed. I’m still not sure whether it’s possible to do, but it could definitely become a best seller in the market of cloud data management. Wait, you may say, what about Google Cloud SQL, AWS RDS, Microsoft Azure, Heroku PostgreSQL, and many others? They are not even close to what I mean.

Недавно один из читателей моих политических опусов пристрастно спросил меня, для чего я это делаю? Чего добиваюсь и зачем пишу? К чему призываю? За кого я и с кем? К чему подталкиваю читателей и каких действий от них жду? Его также очень интересовал вопрос, где все-таки моя Родина: в Москве или в Киеве? Ответ, казалось, его удивил и разочаровал.

I owe my pretty high Stack Overflow reputation to this question in particular, which I asked a few years ago: How do you print an ISO 8601 date in Java? It managed to collect a lot of upvotes since then and 20+ answers, including my own one. Seriously, why didn’t Java, such a rich ecosystem, have a built-in out-of-the-box simple solution for this primitive task? I believe this is because the designers of the Java SDK were 1) smart enough not to create a print() method right in the class Date, and 2) not smart enough to give us an extendable set of classes and interfaces to parse and print dates in an elegant way.

At the very end of one of my recent meetups I was asked a question: “Are you a happy person?” I mumbled something about being happy from time to time, but later gave this question more thought. Am I happy? Not really. Well, sometimes. What makes me happy? And why are so many of us unhappy so often? It seems that there is an answer, and a recipe for happiness.

Российский либерализм принимает все более агрессивные очертания и выходит на улицы, инстаграмы и ютубы. “Мы обязательно победим” — главный лозунг борцов с несправедливостью. Пока что их главное оружие — это беззубые мирные демонстрации, многотысячные лайки и профессионально смонтированные видео каналы. Многие из них нам даже симпатичны. Однако подлинных оваций заслуживают их режиссеры. В непримиримой кибер-войне им удается побеждать армии “кремлеботов”, превращая посредственностей в народных героев. Под занавес Россию, видимо, ждет Майдан, трансфер власти, передел собственности, амнистии, аресты, и … окончательная победа добра над злом. Ожидается, что “мы победим”, и коррупция вместе с чиновничьим беспределом навсегда исчезнут. Может быть, и “победим”, но исчезнут ли?

I got an email a few days ago. “I’m not a programmer. I’m a mom of two kids: 9 and 14. They both seem to be interested in computers, but they mostly play games. What would you recommend I do to help them make a career in tech?” I’m not an expert in parenting, but I’m getting similar requests rather often. It’s great to see that some people realize the difference between playing GTA and Java coding. It’s very sad to see that they don’t know how to motivate their kids. I don’t know either, but I can try to make a guess.

A few years ago I wrote a blog post about the daily stand-up meetings many software teams are doing regularly. Since then, the article has been getting comments from both sides. Readers either 1) strongly agree with me or 2) accuse me of having no idea what morning stand-ups are for.

My point was: only weak managers need such meetings to coordinate the team, while strong ones use more formal instruments to organize the flow of information. However, as someone noted, morning meetings are not supposed to be used by managers to coordinate anyone, but “to discuss progress, impediments and to plan.” I’m not buying it.

В минувшее воскресенье в Москве прошел, по словам недопущенного к выборам в Мосгордуму депутата Любовь Соболь, “самый крупный за новейшую историю” несанкционированный митинг. Митингующие требовали, по ее же словам, “простых и понятных вещей”: выборов, свободы, и уважения. На пути угнетенного народа стоят Путин, Собянин и прочие “негодяи” из власти. Нужно еще немного поднажать и зло отступит, темницы рухнут, и свобода нас примет радостно у входа. Мы тоже так думали в 2004-м году, украшая себя оранжевыми лентами в Киеве. И потом снова в 2014-м на Евромайдане. И ошибались.

Yesterday I was working with a slide deck for one of my future talks about Java and object-oriented programming and got stuck at finding convincing arguments for the transparency of logic. I was going to say that it is important for programmers to be able to understand how everything they do works, even if they don’t see it or never want to see it. But then I realized that maybe not everybody thinks that way. Maybe some programmers prefer to stay in the dark about the majority of things, as long as the code in front of them “just works.” Hence this blog post, to ask you which side you are on.

If you are a manager in a software team, your job is to make your people get things done. This is obvious. The question though is how exactly you make it happen. How do you make them do what you want, according to your plans, achieving your objectives, to your quality standards, and within the borders of your requirements and expectations? Some of you may say that these are our objectives, our mutual plans, our quality standards, and our requirements. This may be true, but initially they are still only yours. How do you make them theirs? There are two ways: a traditional one and an inversive one.

“Территория заблуждений” с Игорем Прокопенко на Рен-ТВ — с недавних пор моя любимая телепередача. В ней нет ни здравого смысла, ни проверенных фактов, ни объективных взглядов, ни единой попытки трезвого анализа. Зато в ней есть лаконичное, выпуклое, однобокое и решительное изложение точки зрения ее авторов. Хочется верить, что она полностью совпадает с точкой зрения всей властной вертикали, которой служат эти журналисты. Именно для этого я ее и смотрю: чтобы точно понимать, во что именно хочет власть, чтобы я верил.

While I was working with a previous article about Test-Driven Development (TDD) I read many blog posts and a few books on the subject and found out that I disagree with a few of them; even some that are pretty important. It seems that most software experts simply misunderstand how software development works. Maybe because they are not really programmers, but are instead book authors and conference speakers.

I wrote some time ago about thread-safety in OOP and how it can be achieved with decorators. It was also said that it’s very important to make sure objects are thread-safe (in Ruby and in Java), especially in web apps, which are multi-threaded (well, in most cases anyway). Well, here is SyncEm, a primitive Ruby gem which makes the above possible with a single decorator.

Remember the famous article Who’s Got the Monkey? The gist of it is simple: good managers always make their subordinates responsible for their own results. When they attempt to send the monkey back to the manager’s shoulders by making excuses, the manager has to be on the alert and not accept the monkey, always keeping workers fully accountable and responsible for what they are doing. It’s a terrific principle, but it doesn’t work for most managers. Here is why. Let me tell you a story.

Just a few days ago a friend of mine, who is not a developer but a co-founder of a software startup, asked me to help his programmers with a technical problem they got stuck with. I said “Why not?” and asked them what was going on. They told me that their PostgreSQL server was running slow because it was doing this and that, and when they restarted it it was repeating this and that… Long story short, I had no idea what they were talking about, even though I was a user of PostgreSQL for many years. My first reaction was: “Have you posted a question on Stack Overflow yet?” They answered: “We still hope that that won’t be necessary.” I replied, surprised: “Huh?”

There are twelve principles in the Agile Manifesto. The fifth one says: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” I disagree. Strongly. This formula suggests treating people in a binary way: they are either motivated and trusted or … what? They have to be let go? This mindset is very typical, according to my observations, and leads to poor management and project failures. Instead, our people management must be more iterative and much less rigid.

We all know what happens when a programmer decides how a web site or a mobile app should look. It ends up looking ugly. And why is that? I don’t know exactly, but my best bet is on the left-brained nature of programmers, who mostly are rigid and logical mathematicians. UI design, to the contrary, requires creativity and intuition, which reside in the right side of our brain. Some recent studies are skeptical about that, but my personal experience tells me that you should never expect a programmer to make a user interface right. Moreover, I’m one of those programmers: No matter what I draw, it’s either black-and-white, or ugly. But I still have to design my pet projects. Here is a list of the top lessons I learned for myself, which help me survive with my left-sided brain.

“A project manager’s work should not focus on dealing with problems; it should focus on preventing them,”—this is how Rita Mulcahy started a chapter about Risk Management in her great book PMP Exam Prep. Sounds smart, but how does a project manager know about the problems which are supposed to be prevented? This is what that chapter and Risk Management Tricks of the Trade for Project Managers (yet another great book by the same author) are dedicated to. What I learned from these books, and from my multi-year experience of identifying, analyzing and dealing with risks, is that the best format for specifying them consists of three parts: cause, risk, and effect.

Bitcoin was a big technical mystery for me. All the articles I’d read about it sounded extremely complex and absolutely indigestible. Until I got stuck with a task: I had to integrate Zold, our experimental non-Blockchain cryptocurrency, with Bitcoin. I had to study the architecture of Bitcoin and I found this short and simple video (I highly recommend you watch it). I managed to implement the integration and understand how Blockchain works. Here is my short summary. I hope it will be helpful.

Пишу эту статью по результатам своей поездки по небольшим российским городам, а именно: Пенза, Самара и Новосибирск. Удручающее впечатление, особенно после Москвы. Нищета и грязь. При этом совершенно нет ощущения, что населяют их глупые и ленивые люди, заслуживающие такой жизни. Скорее наоборот, “вроде не бездельники и могли бы жить”. В чем же дело? Почему, работая по две смены, люди в российском третьем городе едва сводят концы с концами, а на их улицах грязь и ямы? Чем отличаются они от Москвичей или, скажем, от жителей Цюриха?

Some time ago I wrote a blog post An Open Code Base Is Not Yet an Open Source Project where I suggested a few important qualities of a good open source repository/project. One of them was the well-written README file. Here I will try to give a few hints on how to create a good README file and what mistakes to avoid. I hope you find it helpful.

Apache Nutch is an open source framework written in Java. Its purpose is to help us crawl a set of websites (or the entire Internet), fetch the content, and prepare it for indexing by, say, Solr. A pretty useful framework if you ask me, however it is designed to be used only mostly from the command line. You download the archive, unzip it, and run the binary file. It crawls and you get the data. However, I’ve got a project where this crawling had to be embedded into my own Java app. I realized that there is a complete absence of any documentation for that. Hence this blog post. It explains how you can use Nutch from Java, not from the command line.

You want your startup to be visible on TechCrunch, right? But you don’t have $15-20K per month to bribe a reputable PR firm to get you there? No worries. This blog post will give you a set of simple instructions on how you can get the attention of those tech journalists who are currently busy writing about Musk’s and Zuckerberg’s innovative ideas. They will definitely write about your baby, I promise you. Just do what I say.

A few years ago I wrote about the independent technical reviews any software project must regularly go through in order to make sure everything is under control. I even said recently that there is no excuse for not doing them. Moreover, the more we trust programmers, the higher the necessity to review their projects regularly. Here is a short summary of what a report from a reviewer must include.

Zerocracy is a great platform to manage a software development project … if you understand how the world of wild animals, also known as pay-by-result freelancing microtaskers, works. If you treat them as you used to treat traditional full-time programmers, you will lose. You will lose your money, your time and will blame Zerocracy. I don’t want this to happen, that’s why this blog post with a short list of important principles/hints.

I decided to publish this blog post in order to summarize the most popular concerns potential clients of Zerocracy express, when they start thinking about moving from a traditional management to microtasking. The blog post will be get new content regularly, and will be used as a reference tutorial for our sales front.

It is a very popular question I hear when I explain what Zerocracy is doing and how it turns traditional software development upside down to increase quality, motivation, and so on. “OK, but what is the financial gain,” they ask? “What is my return on investment? How much will I pay and why it will be cheaper than what I spend now? Give me the price list!” It’s a fair question, which is rather difficult to answer. There is a price list, of course, but it’s impossible to compare it with what you are used to see in a traditional software development.

I was talking to a few people recently, who wanted to join our team and help us sell the platform to potential customers—software companies. They all asked me for a “sales kit” document or a package of documents, which were supposed to answer their most important questions and help address the pain points of those potential customers. Anyway, instead of a fancy PDF document I decided to write up this blog post. Here it is, feel free to use this information when you sell Zerocracy:

How do you design a web application in Java? You install Spring, read the manual, create controllers, create some views, add some annotations, and it works. What would you do if there were no Spring (and no Ruby on Rails in Ruby, and no Symphony in PHP, and no … etc.)? Let’s try to create a web application from scratch, starting from a pure Java SDK and ending with a fully functional web app, covered by unit tests. I recorded a webinar no.42 about it just a few weeks ago, but this article should explain it all in even more detail.

How do you organize logging in your applications? I mean web applications or command line apps, or even mobile apps. I bet you have some global variable or a singleton, known as Logger, which has a few methods like info(), error(), and debug(). You configure it when the app starts, or it configures itself via something like log4j.properties, and logs everything to the console or a file, or even a database. I was doing exactly that, or something very similar, for many years, until I finally realized how wrong this approach was. In one of my recent Ruby applications I did it all differently, and since then I’m much happier than I was before.

Терракт в Новой Зеландии. Вчера. 50 трупов. Один убийца. Соболезнования выразили Владимир Путин, Дональд Трамп, Елизавета II, Барак Обама, весь Евросоюз в лице Федерики Могерини, и многие другие. Событие, безусловно, трагическое. Однако, сейчас интересно другое: почему подобные события привлекают наше внимание и внимание наших лидеров? Только ли в силу своего трагизма или есть другие причины?

I just got an email from one of our customers this morning. They are complaining that the project is not moving forward as fast as they would expect. Here is what they are literally saying: “Despite the fact that about 20 developers have been invited to the project, work is going very slowly and, worse, unpredictable. On average, the developer closes 3 tasks per week. It seems that all of the DEVs have a main job, and in Zerocracy they work on a residual basis. There are cases when a task (which should take 30 minutes for the developer) is not solved within 10-15 days. Moreover, we cannot do anything about it, because according to the policy, developer has 10 days to complete the task. Also, we do not have tools for additional motivation of developers. The reputation system doesn’t seem to work, because reputation does not affect anything and punishments are very small.” It’s a fair complaint, let’s see what we can do about it.

I’ve been writing so much about object-oriented programming and its pitfalls, claiming that most of the design patterns and “good practices” which we are accustomed to are actually wrong and hurtful, that I totally forgot to explain the bigger picture problem. Someone asked me some time ago in the blog post about “naked” data: What is the problem we are solving and why exactly does maintainability suffer if we don’t encapsulate our data enough? Here is the answer.

Демократия — это наихудшая форма правления. Власть принадлежит толпе, которая неспособна мыслить стратегически, состоит в большинстве своем из людей недалеких, принимающих сиюминунтые решения. Так во втором веке до нашей эры считал Аристотель. Более эффективной системой правления ему казалась та, в которой власть принадлежит тем, у кого заведомо больше авторитета ею обладать, а значит принимать более взвешенные и грамотные решения.

You remember my blog post about Why I Don’t Want to Live in Silicon Valley, don’t you? Read it first if you haven’t already. The gist of it is that Silicon Valley is a place with a lot of troubles. No one should want to live there, according to that previous post, right? That is what many of my readers concluded, but they were wrong. Despite the problems, the place is definitely unique and there are a lot of reasons why you may want to consider it as a great place to live, for a few years at least, especially if you are in the tech business.