The Best Programming Advice I Ever Got (2012)

I had a similar experience and similar results. Someone wrote code to perform 1000 queries to pull back 1000 rows in a specific order rather than issue one query and let the Java collection order the results. Amazingly, another person wrote more logic to add a switch to skip this step because it literally took 10 minutes for the app to start when connected over VPN. The fix was trivial and startup time went from 10 minutes to 300 milliseconds. Being the new guy coupled with the fact they had actually lived with this for years, I was immediately hated.

There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life.

In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question.

When my electrician has a power supply over here and needs power delivered over there, we all know he's going to use wires, and he knows the right gauge to use. He's got a book somewhere with the answer, and there's a regulation somewhere that says what he's required to use. But I just trust him to use the right cable, because that's his specialty, and I've never seen him make something that was an order-of-magnitude worse than was required, or that I could do on my own.

Respecting boundaries is a lot easier when you can trust that other people are generally competent. This will continue to be a problem for the next 100 years until we figure out the right way to make good software.

There is an entire world to be dissected in the final few paragraphs. The essence of the error the author made (and we know he made an error because he ended up in the head boss's office being chewed out) is to imagine that a successful project is founded on good technical grounds; not true, or not only at least.

The author's presumption here is that the advice was bad, and he learned the opposite lesson (don't accept social boundaries). But the advice WASN'T bad, because the organization doesn't consist of just code product, it consists of a set of programmers, managers, executives, users, customers, etc.

The important question this article raises is: WHY do people write code? What makes someone want to write good code? What motivates them to do work? What motivates them to wish to cooperate with others in their effort, to communicate their problems and insights, and contribute to the greater health of the product?

This, more than anything else, kills projects. The smartest people on earth can accomplish nothing if they petulantly refuse to cooperate, and in order to accomplish that you need to pay attention to more than what is merely technically best, you also need to pay attention to the people in your organization. What do they WANT? If they are anything like a normal human being, they want - to appear successful, to be valuable, to have their skills be seen as valuable, to have their ideas and work be appreciated by others.

We can, of course, dismiss this as "ego" or "politics", as the author does, mere cruft that gets in the way of the ur-goal of the organization, a beautiful product. But if we do so we're really ignoring what people want - and that is NOT to merely be a gear slowly ground down in the service of the greater good, eventually worn out and replaced by a newer, better gear.

Such advice, that we should ignore the very normal (and yes, egotistical) motivations of ordinary human beings at work, is perhaps not the best advice you could get.

People keep saying, “this is bad advice.” But this an article on software corporate politics, with a facetious title.

It depends what one's goals are. Improve the system? Build good working relationships? Make yourself or your team look good?

In many cases similar to the one you described, the other programmer has already heard what you are trying to tell them and chosen to disregard it, for reasons good or bad. You have outlined a good starting point, but if you stop pushing, you are likely going to maintain the status quo.