The Joy and Benefit of Being an Early Adopter in Programming
Published: 2016-03-07 10:01:51

<p>Yesterday I wrote about <a href="../the-zen-of-missing-out-on-the-next-great-programming-tool">the benefits of being a late adopter</a>&nbsp;where I outlined&nbsp;the benefits of <em>not</em>&nbsp;jumping too quickly to adopt&nbsp;new programming languages/libraries/build tools, etc. It is important that programmers think about the tradeoffs on their time.&nbsp;That essay was a call for developers to avoid letting their anxiety and fear of missing out guide them to make bad choices, but I want to look at the other side of the coin. There are a lot of&nbsp;great reasons to be on the bleeding edge with your technology choices.</p>
<p>So much of programming is about choices. Because of the bevvy of open source code options and professional software services popping up, our day to day is more about choices than ever. Yesterday I promoted the choice of letting the circus pass through town without running off to join; practicing discipline in order to stay productive and make the right long term choices. But now I want to talk about when and why you might want to jump in feet first.</p>
<h2>The benefits of jumping in</h2>
<ol>
<li>When you get in on a project early, you get to see it evolve in real time and become more familiar with the problems and solutions being presented along the way. You will get a greater context of why the choices have been made and could develop a deeper understanding in the long run.</li>
<li>There is often a simpler and less featureful interface early on. Perhaps that is because key features are missing and will soon need to be added, but there will be less to learn and fewer new concepts to wrap your head around. When you join late to an evolved ecosystem, there is often a lot of evolved functionality and build chains that incumbent developers take for granted.</li>
<li>There are real opportunities to contribute and shape the direction of the project, either through suggestion, coding or documentation. You may get to have a say in the decisions and ensure your use-cases are considered.</li>
<li>You will have a great opportunity to get to know the developers and form good industry relationships. Smaller chat rooms and lists associated with early projects present a much more intimate chance for knowledge sharing and communication.</li>
<li>You will get an opportunity to get to know the API and play around with it for real. This gives you the opportunity to use it in small projects if you want to delay writing important code with the new paradigm. Getting your hands dirty early on means more time since initial exposure and even if you do not start using the tool a lot right away, you will give yourself a lot more time to work out the problems in the back of your mind.</li>
<li>The excitement of being involved in the new hotness. Regardless of productivity and outcomes, if you are not excited about what you are doing, you are going to have a bad time and getting involved in new things can keep you motivated across all of your programming goals.</li>
<li>You get to be involved in the latest, greatest thing early on and are ahead of the game once the stubborn stragglers come to join. However, this comes with a lot of major uncertainties I want to cover next.</li>
</ol>
<h2>The lottery of new technology</h2>
<p>It is all well and good to want to get involved in the inevitable shift in programming, but predicting this sort of thing is not so easy and you cannot be too quick to declare a winner. This is the biggest danger of pouring too much of your commitment into an idea while the landscape is shifting so much. We do not need to be analytical about every excited choice we make and we do need to take risks&nbsp;and&nbsp;bet on technologies and learning a lot of new things, but we need not be foolish.</p>
<p>Before picking sides make sure that these new ideas&nbsp;fit&nbsp;<em>your </em>brain. There are a lot of options floating around and you do not need to get involved with something that will not make you a happy and productive programmer. Once we have determined personal fit,&nbsp;we can ask a few questions about the technology. If we like the answers we come up with, we can dive in with a lot more confidence.</p>
<h2>Key questions</h2>
<p>Is this a clear improvement over existing options or just another option? It is hard to displace existing technology with anything that is not clearly better. Yes, you should learn a variety of ideas, but do not jump around making lateral moves. Pay attention to opportunities to get involved with bigger and better ideas.</p>
<p>Is this technology backed a lot of initial support and excitement or a major vested interest that has shown clear willingness to make use of&nbsp;it? <a href="https://facebook.github.io/react/" target="_blank">React</a>, which has been very successful, has been so, in large part, because of the straightforward and transparent commitment Facebook has made to it. <a href="https://angularjs.org/" target="_blank">Angular</a> and other Google projects, while also popular and backed by a major company, have struggled to demonstrate transparent commitment and vested interest. <a href="http://famous.org/" target="_blank">Famous</a>, a less successful&nbsp;project in the space that was not without its share of backing early on, failed to drum up enough interest to become widely adopted. <a href="http://emberjs.com/" target="_blank">Ember</a> remains very relevant because of an open and trusted core team and an early history of making good choices, but React has emerged as the basic front-runner in the space.</p>
<p>Do you have a personal need for this hot new thing? If you have a burning struggle and find a great solution, you have a lot of good reasons to adopt it. That does not mean you should get tunnel vision, as there may be something else available or around the corner a better fit, but you will have a better time if you have an immediate need for a tool than an abstract future need. If you are struggling with <a href="rubyonrails.org" target="_blank">Ruby on Rails</a>&rsquo; patterns and relatively pedestrian performance in a current or impending project, you should open your search and examine the landscape and choose a new technology and even then you do not necessarily you should weigh your options between long-lived performant languages of which there are many. If you are only generically concerned about performance and scalability as an eventual problem, I do not think you will have as pleasant a time adopting a new (or old) technology.</p>
<h2>In conclusion</h2>
<p>There are a lot of good reasons to get involved early with certain technologies, but with a vast array of choices, pay a lot of attention to the risks and tradeoffs so you can make good choices. Early and late adoption of technologies is not a dichotomy. A good mix of new and traditional tech will expand your mind and enhance your long term potential as a developer. If you do not succumb to shiny-object syndrome and do not act out of fear and anxiety of missing out you will do well.</p>