However, either I have aged lately (I’m afraid that’s true anyway…) or something has changed in the way I look at code. In fact, with age, I think that I have started to be more critical with development in general and I look at it less as my favourite private playground and more as a tool that should be used to get somewhere with my client’s products (or mine, come to think of it!) as quickly as possible.
This critical perspective has been accentuated since I’ve been spending more time in a CTO position rather than a developer position. As a CTO you have to make a mind switch in which you’re putting your client’s interest ahead of your own framework or development preferences.
I remember very clearly when I read this awesome tweet (thanks Liran Tal for sharing it):
I laughed hard at first but then I remembered that I too spent a couple of days configuring webpack and Babel… When you’re a young programmer, you consider everything as a learning curve. But in the long run you realize that life is short, that you have many ideas that you would like to bring to life, and that 2 or 3 days are better spent coding rather than configuring your project for the n-th time or trying a new framework for each new project.
While exploring all of the amazing possibilities offered by our beautiful language, we should still pay attention to the ratio of our time being spent for features VS framework/ecosystem. I find the cost of decently learning React or Angular pretty high nowadays (and I’m not even speaking of going from Angular 1 to 2). According to some senior developers, it could take you somewhere up to 2 years to really master the main principles and start to use it wisely. Add to that the updates, ES5, ES6, ES7, the tools, the plugins and other package managers and I’d say that half of a developper’s life is going to be consumed to follow-up with the technology…
Great products and software have been written before with far less powerful technology. Let’s focus more on simplicity when possible and on bringing value instead of building over-sophisticated tools: often the simplest way is also the best.
Paul Brie, Head of JS
This article was orignialy published here.