Before delving into this, learning is good ok? We’re all here to learn something (queue monthy python: Large group – “Yes, we’re all here to learn!” … One guy in the back – “I’m not”) but it’s easy to get derailed with details when there’s just so much exciting stuff out there.

New tech = initial bump

I’m assuming this happens to most folks and it gets worse the more to the left you are on the adoption curve of a new technique. You are psyched up and ready to get cracking – only to be immensely slowed down by just setting up a dev environment or getting “hello world” to compile / interpret / just run dammit. The early adopters are ok with this – or even thrive of going through the rough phases where everything barely holds together (I’m guessing because you have more influence then. You are actually making a difference).

But but but… being the early adopter of the newest and shiniest things have an opportunity cost – you’re going to spend much more time on getting the new thing to work and less time on things not related to the language / framework itself. And that’s ok if that is your thing – using the newest stuff. Maybe you’ll even make yourself a name should you write the first web-framework or templating engine in your new language. But it should be a conscious choice staying in the left on the adoption curve. I’ve often gone this road without thinking of the opportunity cost of doing so. My goal was often to make something cool, but just because I could it would often be using the latest upcoming languages. And that meant that the cool things I set out to make withered when the initial bump set in.

The initial bump

With the initial bump I mean that not only that you’re not experienced in the new language, things take longer time because less time have been put into get things to work. Documentation is not there yet, libraries break with new versions, you get errors just trying to setting up the dev enviroment, error messages are obscure and no one else seems to have all the problems you’re having.

The initial bump extends beyond just getting a working dev environment up and running. It also means less powerful IDE / editors, less tools (e g debugging, package management, build systems) and less frameworks and libraries with respectively less production time under their wings to choose from. In short, you’ll do more work because less time has been put into the thing you’re trying to run. And that costs – in time and focus.

The perhaps unglamorous alternative to this is using stuff you know well. Chances are that this is to the right on the adoption curve. But it’ll buy you something – time and focus.

Old tech = new domain?

By using the tools, frameworks and language you know best you’ll steer clear of the initial bump. And you’ve freed up time to explore another side of programming – getting to know a new domain and solving its problems not being slowed down by your tools.

It’s like learning to drive vs driving, at first you’re so occupied with the mechanics of driving that you can’t be bothered with the traffic ahead. Its first when you know the mechanics that you can focus on the actual driving from A to B.

Possibly leverage with a new language

If you’ve made a prototype using tools you know you’re in a much better spot of rewriting it in some other language / framework. You are now choosing tools based on your domain knowledge, this is a huge advantage – you’re running the tools and not vice versa.

Leverage old tech and iterate faster

Again, a speech about going fast. But really, I think that pragmatism and knowing when it’s good enough is highly learnable. But you got to set out doing so with a clear mind. Using the languages, tools and stuff you know best will let you focus 100% on going fast in a new domain. Churn out really dirty but working code just to experience and get the feel of what it’s like. It’s ok, set out milestones when you refactor and tidy up.

At least for me, when trying out a new idea its important to go fast from idea to prototype. Instead of getting stuck in the setup and loosing steam (and possibly even giving up on the idea before its even been test driven) – leverage everything you possibly can to get it to a working state. By using the tech you know you probably also know what frameworks and libs to use (and chances are that there’s plenty more of them out there since again you’re using a language with more adopters) you compound on your existing knowledge. You can make more critical judgments on claims of what works (for you) and what does not.

This also ties in with a lot of blogposts I’ve been reading on startups. Many of those who succeed launch fast and get it right afterwards – screw the details, we’ll figure those out later when we’re actually making some money. By using tools and products you know you’ll steer clear of the inital bump, and if you’re wise you stay to the right on the adoption curve, where there are powertools, battle proven VMs and industrial strength IDE’s. It’s ok – if you succeed you now have a luxury problem of switching languages and frameworks. With all that knowledge of what did and didn’t work.

Do share

Now I’m aware that by using older tech you are piggybacking on those that did take time to get things working and writing frameworks etc. And by doing so you might not have something as tangible as a fresh framework to share (or if you do its of less value beeing the nth framework of that kind and not the first or second).

But, you can share the domain problems you ran into and how you solved them. Hopefully that’ll feedback to those on the forefront of some new tech getting perspective on what they build might be used to solve – problems rarely change that much regardless of tech. So you know, at least send some love to those brave enough to not take this advice and to go head on with the left of the adoption curve.