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 StackOverflow 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.

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 StackOverflow 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.