Friday, April 24, 2015

Doing The Right Thing For Wrong Reasons

There are very few things I would do rather than programming. I discovered that back in 1987 and it is still as true now as it was then. I love the creative part of it for sure, but what I love the most are two factors: the objectivity of the result - it can be measured, analyzed and proven better or worse than an alternative; and (gasp) the aesthetics of the programming language and runtime design.

First is simple: I really need to be able to tell whether any given way of achieving a goal is the most optimal and efficient. The notion of different styles of programming as equally-valid means of achieving a given goal troubles me, because given the set of qualities: scalability, availability, maintainability, complexity, time to market, etc. - all collectively known as total cost of ownership (TCO) - your way of getting there and mine are guaranteed not only to be different in style, but also to have different TCO. See, I am suspicious of both natural self-promoters and nurtured entitled types (your output is precious before you've done anything), which is why wherever I see different approaches, I want to get an objective measure of the value of each approach, and programming is one of the few activities that allow for ways to tell a BS from a well-done piece.

The second - the aesthetics angle, is defined by how easily I can feed my obsession with finding the best way of doing things. I care a lot of how I get where I am heading. This manifests itself in my learning slower but deeper, achieving higher clarity of understanding, and improving my ability to articulate the net value (assets minus liabilities) of a given technology, approach, pattern, etc. If I sense that there is a better way of doing things, I want to find it now. If I find that I wrote code that is not most efficient (not just in performance, but also clarity, expressiveness, maintainability, extensibility, and so on), I feel embarrassed and cheated.

This leads to some of my idiosyncrasies in how I work. I loath going back to less efficient ways of doing things. For example, after I discovered C++ in 1991, I could never imagine going back to plain C, which I loved very much until then, ever since I found that C could be as much fun as Assembler with much higher productivity. When I saw JavaScript for the first time back around 1996, I gave it no more than one year before it would be replaced with something real. Boy, was I wrong about the staying power of a monopoly-holding programming language of the slowest-ever-evolving OS: a web browser. Same with how I now dread going back to TFS or SVN after experiencing Git, which I kind of didn't want to learn because in 2011 I felt TFS was pretty great.

At around 2001 I fell in love with C#/.NET 4.5. These days, with its LINQ and pseudo-functional veneer, async/await, extension method, IEnumerable + yield and deferred execution, beautifully-implemented Generics, phenomenal performance - C# and .NET stack are my absolute favorite, which, from a practical manager perspective can be both an asset, as I know them really well (I know what "volatile" is for and how .NET 4.5 has finally implemented claims-based access rights security management), and a liability. A liability here is that being the connoisseur of the Microsoft stack, I lack the "do what it takes" attitude so often valued in the corporate world. It all means that my work is more artisan than industrial. I think I'd rather build a beautiful thing than change the world. Sometimes I get lucky, and get respectable if not world-shattering number of installations of my pet products - 1.1 million as of now. Sounds pretty good, right? But it took me 1.5 years of nights and weekends work to get there. Sounds kind of expensive doesn't it? But the quality is such that my products average only 1 support request per 2-3 weeks. Not bad again, I think, for a product that gets installed a few hundred times a day on every possible configuration of PCs ranging from Windows XP to 8.1. So you see, since I'd rather learn from Schubert or Picasso than Zuckerberg or Jobs, I am probably good for your team only if its values are such that it has more foodies than coke & pizza eaters.

I imagine observing me working could give a strange impression: a very quick delivery of large and complex, high-quality components (60% of this was written in 7 days), offset by somewhat deliberate pace of learning, caused by the obsessive need to learn in-depth and understand motivations of people who created the subject of my study.

So there it is: I exist just outside of the "change the world while making the bundle" cliche philosophy and values of the Silicon Valley (the place, the TV series is laright). But if you run besides me while I take on my next obsession (today it's The Cloud/PaaS) you are very unlikely to be ahead of me in 3 years from now, even if you got 3 years head start.

No comments:

Post a Comment