Availability is a metric that demonstrates how often your website is available to its users. Technically, it's a ratio between the number of successful attempts to open the website and the number of failed ones. If one out of a hundred attempts failed, we can say the availability is 99 percent. High-quality websites aim for so-called "six nines" high availability, so named by the number of 9s in the ratio: 99.9999 percent. We created a service that helps you measure this metric and demonstrate its value to your users: SixNines.
I've been blogging and writing for almost three years now, and a few times a week I get emails or Facebook and Telegram messages from people I don't really know. They ask questions about Java, management, object-oriented programming, and other things they believe I understand and can help them with. Well, my contact details are published right in the header on my blog—what else would I expect, right? True, but even though I always reply to them, I never answer their questions.
There are two opposing mindsets: "If it works, it's good" vs. "If it's good, it works;" or "Make it work" vs. "Make it right." I'm talking about the software source code. I've been hearing this almost every day in blog comments: Why do we need all those new OOP principles if our code works just fine without them? What is the point of introducing a new way, which is supposed to be "better," if the existing, traditional, semi-object, semi-procedural, not-so-perfect approach just works?
Puzzle-driven development (PDD) is a methodology we've been practicing on our teams for more than seven years. Using PDD, we delegate the responsibility of task decomposition to its performers, eliminating the role of a project manager. We've been using our proprietary software for that. A month ago, we made it public, open source, and free. It is available as 0pdd—a GitHub-based chat bot.
You definitely know the SOLID acronym. It stands for five principles of object-oriented programming that, if followed, are supposed to make your code both legible and extensible. They were introduced almost 30 years ago, but have they really made us better programmers in the time since? Do we really understand OOP better thanks to them? Do we write more "legible and extensible" code? I don't think so.
Let me say right off the bat that the features we will discuss here are pure poison brought to object-oriented programming by those who desperately needed a lobotomy, just like David West suggested in his Object Thinking book. These features have different names, but the most common ones are traits and mixins. I seriously can't understand how we can still call programming object-oriented when it has these features.
During nearly every presentation in which I explain my view of object-oriented programming, there is someone who shares a comment like this: "If we follow your advice, we will have so many small classes." And my answer is always the same: "Of course we will, and that's great!" I honestly believe that even if you can't consider having "a lot of classes" a virtue, you can't call it a drawback of any truly object-oriented code either. However, there may come a point when classes become a problem; let's see when, how, and what to do about that.
This is a real story, and it's not only about Google. I'm getting emails from recruiters at Amazon, Facebook, and smaller Silicon Valley startups. They find me somehow, most likely through this blog, my books, or my GitHub account. They always start with "We're so impressed by your profile" and finish with "Let's schedule an interview." I always reply with the same text, and they always disappear, only to come back in a few months under a different name. Let me explain my reasons; maybe you will do the same and we can change this situation in the industry.
I've said before that your StackOverflow reputation is very important to us when we make a decision on how much we should pay a software developer. However, there were many complaints about this metric. Take, for example, the ones here and here. In a nutshell, so many of you disagreed and said that the number of StackOverflow up-votes was nothing more than a measurement of the amount of time someone spent answering stupid questions asked by clueless programmers. Let me disagree and explain why your activity on this platform is so important to your career.