Early Adopters — Early Majority
I could have given this post a different title, something like “Why I don’t care about your hipster framework” or “3 simple steps to avoid JavaScript fatigue”. This is not one of these type of posts.
So you’ve been back on Twitter after a couple of days off and now feel that you’ve fallen back years behind. Just when you thought you had the slightest clue, you realize that you’re back to square one. Somebody had released that new thing and everyone’s talking about it. Your timeline is full of references and discussions referring to Github issues and Medium blog posts. Somebody’s already asking for a developer with experience in said new tech.
Take a second to think about the following. What’s your motivation? Is it to keep up with people you don’t personally know and who don’t know you? Is it to be able to claim knowing <insert any tool, library, framework>? Is it the endless search for the silver-bullet? Or is it the fear of feeling left out on the job market when you don’t know everything that’s out there?
Think about this.
Probably it’s a mixture of reasons that all play into this. Things get even worse when someone inside your team suddenly decides to introduce a shiny new solution on the strength of a tweet or two.
Now I could insert the “Don’t believe the hype” video by Public Enemy here, add a couple of words on why you shouldn’t worry too much and be finished with this. I’ll do something different.
Being a late adopter is absolutely ok. There is no problem with not knowing every library and framework out there. There are too many and our time is simply limited. It’s one thing when you’re starting out and thinking that every new library on Github with 1000+ stars is the solution to a longstanding problem. It’s another when you have client projects and real world problems to solve and have seen those hype cycles over and over again. Every couple of weeks someone or something supposedly solved a problem.
I personally don’t have the time to keep up with every new release. You can say that I’m definitely not an early adopter, especially when it comes to introducing new things into production. It might take up to a year until something trending get’s into a real live system. Now I’m sure you’re thinking “up to one year?” Yes, up to a year between hearing about the hype, testing and experimenting with given solution and finally introducing it into a customer project. Now of course this is not a set in stone rule and it depends on what we’re introducing. Is it a new tool or a large framework? A trivial tool might be introduced straight away if it solves a current problem. A major framework not so.
To give you an idea, we had been experimenting with React in 2014, building examples and reading blog posts. All this, while we were building a very large data driven application with Angular in the front-end for 18+ months at this point. We needed the evaluation phase and the right problem or project to introduce React. Finally, in 2015 we introduced React to solve a pending problem and from there on built a couple of client products with given framework.
Same thing with Elm. I’ve been reading the documentation, building examples and going through different guides for some time now. I’ve also given an internal talk on Elm, just to give everyone an impression of the language and the possibilities. See it as an initial introductory. The next step is to build an internal tool with Elm, to see where the possible use-cases and limits are. And only then, can we decide to introduce it into a real world product. It needs to justify an outcome and add benefit to our current stack, without introducing new problems.
There are simply too many libraries being released to really catch up, and we don’t really have the time. We never tried out a single flux implementation due to lack of time, but simply waited until a solution had gained momentum (redux in this specific case) and then tried redux out.
The term YAGNI — You ain’t gonna need it — describes this approach quite nicely. You will not need that new thing released 2 hours ago probably. We will fallback to a solution once a specific problem arises, the options are obviously out there.
Remember when I asked what’s your motivation a couple of paragraphs above?
I’m interested in solving problems. Not technical problems in the first place, but problem’s my customers or users have first and foremost. The tools are a vehicle to implement the solutions that benefit our users and customers. Time is limited, so we do need to prioritize here. Either gain deeper knowledge and learn the fundamentals including using libraries for recurring tasks, choosing tools on a per problem basis or learn more and more tools just in case they could solve a problem we don’t have right now. The point is that we are in the business of solving problems.
How do technical decisions take place in your team?
Ask yourself, how does a solution get introduced into an existing codebase? Is there a discussion with all the stakeholders? There’s a difference between knowing about all the new libraries and how they function and knowing when to use them. This is where many of the problems in current front-end development come from. Adding everything that’s trending is a recipe for more problems. Same goes for things like server side rendering, who decides on these things? I would guess this is a business decision.
To round it all up. Yes, learning is a major part of the job, so is understanding what we’re building. Treat the existing eco-system as a pool of solutions you can refer to when problems arise. Avoid any dogma and don’t take everything being said as the “only way right way”. Keep an eye on what’s happening, this is absolutely useful but also consider every decision wisely. It’s not about knowing every trending solution, it’s all about knowing when to apply that solution.
Being early majority is absolutely fine. Somebody has to be.
If you have any feedback please leave a comment here or on Twitter.