eli james

Principles for Technology Choice

1:07pm, 2 June 2015

When I first started at this job, a friend warned me against losing my technical chops. “It’s great that you’re learning all these business-y things,” he said, “but if you forget what it’s like to code, you’re probably not going to be very good.”

I’m not sure if he’s correct for the general case, but I do think he has a point: I can’t afford to become non-technical at this stage of my career. Technical skills are pretty valuable this decade. (Plus, it’ll probably be a waste of my computer science education, and wouldn’t that be a pity?)

On a day-to-day basis, though, I have many ‘business-y’ things to worry about, and not that much time to get lost in my code editor. And I think what makes things worse is that I want to learn to build things that people love; this necessarily implies that I have to learn more skills than just technical ones.

To that end, I’ve developed a few principles to help me choose technologies to build on. These principles arose out of my realisation that I simply couldn’t keep up with all the latest software trends.

I’m listing these principles here to crystallise them, but I’m also posting them in the hopes of being useful to people. Perhaps they’ll make you think through your technology decisions. Or they’ll give you a good opportunity to laugh at mine. No matter. Caveat emptor.

Pick explicit frameworks and languages. There’s a tendency in some software tools to provide large, all-encompassing abstractions in order to make the programmer’s life easier. I stay away from such tools because they take longer for me to learn, they take more cognitive overhead to debug, and they require more effort to load context when returning to them as old codebases.

I know that this is a conscious tradeoff I’m making: I am willing to sacrifice some speed for more maintainability and legibility. This matters to me because I don’t have much time to maintain my code. Magic is unacceptable under these constraints.

However, I admit other programmers may choose differently.

Pick boring, well-tested technologies with large communities. As Marco Arment puts it: in an industry of quicksand, it’s worth it to find some solid ground to stand on. Technologies like Debian, MySQL, Redis and Memcache are not going to go away. It pays to spend a few months or even a year as a one-time cost to learn technology you’re likely to use for the next few decades.

Consequently, continually picking the same boring tools to use when building things amortises the cost of learning those technologies in the first place. Therefore, this principle consists of two parts: 1) learn mature, boring stuff because these things stick around. 2) refrain from using the latest, coolest technology when building things, unless absolutely necessary.

This principle doesn’t mean ‘never learn new things’. It just means that I should recognise the cost involved with continually learning the latest and greatest. My decision to pick boring, mature tools that I have learnt and understood frees me to learn other aspects of building products.

Pick technologies that are respectful of breaking API changes. Certain technology communities and projects are more willing to make breaking API changes than others. Whenever possible, pick groups that are less willing to do so.

This is both a philosophical choice (libraries and frameworks are supposed to save you man hours, not give you periodic pain for the benefit of the maintainer!) as well as a necessary one: I don’t have much time to relearn the technologies that I pick.

Don’t be too clever. I am not a very good programmer. In fact, I’m probably about average. There’s a saying by Kernighan and Plauger that goes: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Because of my constraints, I try to write code that is as dumb and as obvious as possible. This sounds nice in theory, but in practice means that I have to give up nice things like, say, meta-programming. On the flip-side, I have no problems with languages like Go (which shares the same philosophy on programming cleverness – and therefore gets a lot of hate).

Implications

These principles are mine, and are subject to change as my constraints and realities change.

In practice, these principles have lead me to avoid technologies like Ubuntu, Rails, MongoDB, Angular and SQLAlchemy, while picking boring, simpler tools like Debian, Go, PostgreSQL, Mithril and, urm, as little ORM use as possible.

What’s interesting is that these principles are meaningful only insofar as what they’ve made me give up. There’s nothing particularly wrong with Ubuntu, or Rails, or SQLAlchemy – it’s just that they imply tradeoffs I’m not able (or willing) to make.



Other essays

Saigon

Moving to the least developed ASEAN dragon.

Where is the Intellectual Capital of Asia?

And if one doesn't exist, should we be worried? Or is the idea of an 'intellectual capital' moot, anyway?

The Expat Horizon

The expat horizon is the time limit an expat can survive in a country alien to his or her own.