Smart Enough, Yes. But Daring Enough?
Recently I have read Paul Graham’s essay “Beating The Averages” in which he talks about how he and his team were able to outperform the competition by making a few key decision about technology. Decisions like going web first, writing their software in the Lisp programming language or choosing Linux OS to run on their servers.
This got me thinking that it can’t be that they made those decisions just because they smart because there is plenty of smart people all over the place working on software. It also can’t be that they were the most pragmatic ones because choosing such a different technological stack back then meant that you had to build a lot of supporting features yourself; features that others got for free just because they choose another tech stack.
They did not made the decision to write their codebase using Lisp just to recreate the Java stack but to be able to do things that Java did not enabled them to do. Nor choosing Linux over Windows Server, nor choosing web first over a desktop app.
Even nowadays that do not choose a certain technology like Java because “is bloated” but choose a scripting language and attempt to build the same abstractions and functionalities that a Java framework has without having the underlying capabilities of a language like Java that enables such high level abstractions to be easily built.
Having out ruled smartness and pragmatism from the list, I realized that Paul and his team were the most daring ones and that was their competitive edge over others. They bet heavily on the new ways to write software for the web instead of bringing the old practices to the new format.
One of the ways their bet paid off was their ability to deliver software faster to all customers, at once, by pushing the new features to the server and not when their customers installed the new version of the desktop app even if it meant writing some extra functions to deal with problems already solved in Java.
Then, it begs the question: are you daring enough? Daring enough to bet on the technology that seems to be the right one even if it is not the most pragmatic decision, even if it is the decision that might lead to some extra work to copy a few of the features other languages or frameworks provide outside the box, even if it gets pushback from your peers and even your manager?
Dare to bet on that which will give you a competitive edge.