The title of my blog is “The pain of being an elitist”. It has been rumored that this is my way of flaunting my arrogance. I guess some people don’t get the joke (about myself). Although I may strive to be elite, it is not because I am seeking validation. As evidence, let me point out that there are many things that I suck-at. For instance, when it comes to basketball, I make short people feel awesome about themselves*. You’re welcome. Don’t rub it in. There are others too, but that one stands-out. So no, I am not really vain and feeling smug about it.
*note: Just because I’m 6’4. (or 1.93 meters), doesn’t mean I’m athletic.
Elitism isn’t about self-adulation and vanity. It is about the quest for quality. The world needs quality and not everyone is providing it. I’m just trying to be the best at what I do and help others to do the same.
To this end, I believe that all programmers should feel honor-bound to provide the best programming solutions that are possible. Programming is like house building. If you’ve ever watched the TV series “Holmes on homes” (on DIY), you know what a rickety disaster can be made, even by people who seem very knowledgeable and skilled. You have to know your trade and you have to care. Both of those are critical. I guess I’d call that elitism 101 (basic/foundational/fundamental to any elitist).
Beyond the basics, there seems to be many paths. Several of my friends and colleagues feel that a talented programmer should produce elegant solutions. It seems to reason that: really smart people should produce stuff that seems complicated and superior to other solutions. You should look at their programs and go “jeez, I couldn’t have come up with that. It is so amazing!” So, when your company throws a bunch of really smart people at a problem, they seem to expect something amazing like flying tanks with lasers and stuff, that can go invisible or travel time. Anything less, is just disappointing.
I believe that this kind of thinking is a fallacy.
[The most complicated] solution is not necessarily [the best solution]. What I truly believe is that, depending on the situation, “the best solution” can be any of the following:
- Very fast
- Stable and fault-tolerant
- The most secure
- The simplest
- The most sophisticated/elegant
- The cheapest
- Very nice looking
- Highly maintainable
- Completed very quickly
Of these, I must confess that my two favorites are maintainability and speed and they lie in direct opposition to each other. The rest are great too and I’d love to have these attributes on every program that I write. However, you will notice that there are several other opposites like [simplest vs sophisticated], [fast vs maintainable] and [“the cheapest” vs all of them].
So, when your goals are in opposition to each other, how do you pick? This is where we separate the (elitist) boys from the men. Your ego may push you in the direction of seeking approval from your peers (eg, what will impress others). Flying tanks would be very impressive, indeed. However, since Einstein is in short demand and all, maintenance on those flying tanks is going to be a real bugger. Ergo, a simpler solution is often going to be a better solution.
*gasp*. “What was that blasphemy that was just uttered?” you think to yourself. “Did Tim just suggest that [simpler] is better than [more-complicated], ever? Such madness! Perhaps Tim is just saying this, because he is actually not smart and therefore, he is trying to pitch the idea that dumb (like Tim) is better than smart (like me and you).”
Hahaha. You crack me up. No, I am not suggesting that simplicity is best, because I myself am simple-minded. Have you ever heard that it is more difficult to [make something complex seem easy] than to [make something easy seem complex]? People tend to over-complicate things, naturally. I don’t know why, but they do (and so do I, sometimes). It is pretty hard to un-complicate some things. Think back to mathematical proofs, like simplifying some whacky complicated polynomial or matrix problem? Simplifying them was pretty tough. Then, once they were simple, then your sister says “jeez, even I could solve that”. Bravo sister.
The very nature of simplicity is that it is the opposite of 1) flexibility/features and 2) performance. Programming languages, by nature are meant to be ultimately flexible and so are frameworks. Therefore, it is nearly impossible to remove the complexity or difficulty from programming and still accomplish anything useful. You can only rearrange it or distribute it differently. It is still in there somewhere. Just pray that you never have to step-debug into it. Your only choice is, where you choose to stow the complexity so it is not in the way.
The reason that this matters so much to me is because, throughout my career, I have seen WAY more hours burned on maintenance than on writing an app in the first place. Maintaining a goat rodeo is so slow, time-consuming, risky and expensive. Therefore, writing an app so it is more maintainable (looks simpler) is ultimately a choice that could save your company/customer the most money. By the rules of capitalism, that makes it the best choice.
Be forewarned, as I said earlier, making a difficult thing seem easy is one of the hardest things you can do. For me, this has been my grail, my Everest. To truly be elite, my programs need to seem simple and understandable. So, don’t be fooled by all of the Barney stickers. They are concealing all of my wicked-awesome rocket science and stuff.