Success is a Journey, Not a Destination

Photo by Anastase Maragos on Unsplash

Let’s admit it, we programmers are being paid for our time. Just as the construction workers who’ve been digging holes not far from my house for the past two years (btw they’re building a ̶w̶a̶l̶l road).

Let’s define programmer productivity. Everyone who has worked in any seriously large enterprise knows the simple formula for success:

productivity = lines_of_code x bugs_fixed

Bugs Fixed

Human brains are really bad at working with state, we can only hold about five items in our working memory at a given time. State in programming usually refers any data in memory — e.g. fields/variables in OOP. Working with mutable state is very similar to juggling. I don’t know too many people who can juggle three balls, let alone five.

OOP makes good use of this weakness. Almost everything is mutable in OOP. Thank god that OOP takes the matter of developer productivity seriously! In OOP all of the mutable state is also shared by reference! This means that you not only have to think about the mutable state of the object that you currently are working with, you also have to think about the mutable state of 10–50 of other objects that it interacts with! This is akin to trying to juggle 50 balls at the same time, and also has the added benefit of acting as a really good exercise for our brain-muscle.

Bugs? Yes, eventually we will drop some of the balls that we’ve been juggling. We will maybe miss some smallish details from the interaction of those 50 objects. But who cares, really? Bugs should be reported by customers in production, that’s how any seriously large enterprise works. Then the bugs go into the JIRA backlog (serious enterprise-grade software as well). A few years from now the bugs will be fixed. Problem solved!

God, I love using my mobile banking app. It is very advanced, the bank values my business and they take my privacy seriously. The bugs are just features (I was told)!

So-called “functional” programming erroneously isolates state and makes the state immutable. This has an unfortunate consequence of reducing complexity, and thus reducing the number of bugs. Having fewer bugs in the codebase means that we will have fewer bugs to fix. Contractors won’t be able to keep charging their clients for those bug fixes. Developers working in any seriously large enterprise will start looking bad in the eyes of their managers, while seriously jeopardizing their chances of success within the organization.

Lines of Code

We should also be able to show continuous progress to our management. And what is the most effective way to show progress? Lines of code, of course! Had we all switched to functional programming, we’d make the management very upset and suspicious. The “declarative” code would have made our code more concise, and the lines of code would decrease drastically. Up to 3–5 times less code to achieve the exact same goal, this is unacceptable!

In other words, our productivity would plummet in the face of serious enterprise management, and our jobs once again would be put in jeopardy. It is in our best interests to stay away from the “functional” programming.

The same advice applies to the contractors who charge their clients for hours worked. Here’s a simple formula for success:

lines_of_code = time_to_write = $$$pure_profit$$$

This formula for success, of course, also directly applies to the serious software contractors who get paid for the lines of code:

if (1 == '1') {

doStuff();

} else {

// pure profit

}

Spaghetti is Our Bread and Butter

Unlike Functional Programming, OOP offers us a consistent way to write spaghetti code — a real boon to developer productivity. Spaghetti code equates to more billable hours, which translates to pure profit for the serious OOP engineers. Spaghetti doesn’t only taste delicious, it is the bread and butter of OOP programmers!

Object-orientation is a true boon for contractors and employees of serious enterprise alike.