To Measure or Not to Measure

  • 1124 words
  • five minutes to read
  • comments

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?

Veil Objects to Replace DTOs

  • 484 words
  • two minutes to read
  • comments

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.

EO the Career Killer

  • 934 words
  • four minutes to read
  • comments

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!

Open Source Arms Race

  • 892 words
  • four minutes to read
  • comments

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.

Prefixed Naming

  • 607 words
  • three minutes to read
  • comments

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.

Fat vs. Skinny Design

  • 780 words
  • three minutes to read
  • comments

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.

Object Cohesion: Why It Matters

  • 613 words
  • three minutes to read
  • comments

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.

One Question You Should Never Ask Your Boss

  • 479 words
  • two minutes to read
  • comments

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.

Embrace the Chaos!

  • 474 words
  • two minutes to read
  • comments

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!

Talented Programmers, Who Are They?

  • 851 words
  • four minutes to read
  • comments

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 Kills!

  • 958 words
  • four minutes to read
  • comments

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.

Does Code Review Involve Testing?

  • 1059 words
  • four minutes to read
  • comments

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.

How Much Cohesion Is Enough?

  • 530 words
  • two minutes to read
  • comments

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?

Revolutionary Evolution

  • 1073 words
  • four minutes to read
  • comments

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?

SQL as a Service

  • 708 words
  • three minutes to read
  • comments

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.

sixnines availability badge   GitHub stars