It’s been 20 years since I made my first website. I've been burned by the hype time and again. If you haven’t already I bet you will too. Below are some reasons why I’ve learned to ignore the hype.
So here we go!
It's so easy for what is popular today to turn into vaporware tomorrow. The project you are coding right now could require a complete rewrite down the line. Are we ever prepared for when that happens? Never! We probably won't be the ones cleaning up the mess, after all. Even when we do care, it's hard to make software development sustainable. When choosing a particular tool it's important to consider how hard it will be to transition away.
Sometimes it can take a while to learn a new tool. Is the ramp up time worth the reward? If you don’t have the time don’t feel like you are being left behind. Most likely someone else at another company is still coding on the same stack you are. #jobsecurity
If it ain’t broke don’t fix it. This ole adage may apply. Sometimes it’s OK to stick with tried and true methods that work. Does the hypey thing really make your work life easier in the long run?
The hype divides us. This may seem a bit abstract, but it's an observation I've made over time that the hypey things tend to separate us into camps and force us to compare one thing to another, not necessarily in the most productive way. Even if we code with different JavaScript libraries, there's plenty of common ground to go around. United we stand. Divided we fall.
It's easy to do what's popular, however the popular thing might not be the most performant, the most sustainable, or the easiest for an entire engineering team to understand.
It's much harder to do what is right, however what is considered a "best practice" can be subjective. It is important to back up your coding practices with analytical data, making the decision process objective. I find a short checklist helps start the decision making process:
Does this new thing
- allow you to write code that is human readable?
- produce code that is optimized for the environment it runs in?
- help reduce the size of the application?
- allow for the code to be portable and/or extensible?
- ensure longevity for the code I am writing?
- provide methods to easily test it's APIs are working?
It's hard to sift through all the Top 10 and this vs. that posts to understand what is important, what can make or break the next application you develop. The hype divides us. Instead of getting on that hype train take the time to learn web standards. If you are on the front end, learn vanilla JS. Learn different software development patterns and figure out what works. You'd be surprised nowadays how many browser APIs make features in JS libraries obsolete or seem superfluous.
Top comments (19)
Junior Dev = How can I write this code?
Senior Dev = How can I make this code better?
Tech Lead = How can I avoid writing this code?
Or me as I went through these stages:
Junior dev = How can I write this code? How can I make this code better?
Senior dev = How can I write this code? How can I teach people to make this code better?
Tech lead = How can I teach people to write this code? How can I teach people to make this code better?
I would say senior should look for ways to not reinvent the wheel and not use a hammer to nail a screw.
Tech lead should know which one of proposed hammers to use when there is no other option.
Totally agree! Wrote something similar just the other day (dev.to/iamzoka/simplify-web-develo...).
It's like developers just want to use the new shiny thing without thinking about consequences or what will happen down the road.
I’m constantly on the cutting edge, playing with new browser API well before they make it into spec at times. That’s fun and all but it doesn’t mean those API make it into my everyday workflow. There is a time and place for experimenting with bright shiny new things.
Exactly. That’s what personal projects and playgrounds are for.
Glad to read this! 👏
Sometimes I think I'm alone fighting with this!
I'd say, make things simple for your goal, no matter the trends!
There's nothing wrong with "boring" tech choices, especially when you have a problem that you really care about solving.
Could not agree more! I'm playing with new toys all the time but using them in a real project is something I've become very suspicious of.
I've run into problems with abandonware too many times to count.
Completely agree!! I think we should always keep our eyes open to know what’s going on.. use them only when it makes sense..
The second point is the skill itself :)
For work projects I always use tried and true technologies. Too many times I've had to work on a legacy project built with some early version (or even alpha!) of a framework or library.
On side projects I explore new stuff I find interesting and worth looking into.
When you said "this vs. that" - where did "this" point to? Just asking for a friend! ;)
(I am a great friend of making libs like jQuery obsolete by using small vanilla js functions, which are used by the site instead loading the whole library wherefrom 5% are used)
New shiny tech is my toy in my free time. At work there are decisions to make based on use cases, requirements, architecture, technological dept and many more. When it's getting serious there is no hype (besides in the sales and marketing department).
Agree. Just imagine how many hours worldwide will be lost due replacing classes with hooks... not that I like classes anyway ;-)
At one position I had worked at, I was part of that transition crew. We would find new and fun ways that things were overdeveloped, overly complicated in the projects we were tasked to migrate.
We would look at each other, nod, and say, "Developers be developin'!"
Usually, just the bare minimum of documentation would cover a lot of issues.
And a Zen Dev thinks also about the individual or team who will work with the ZenDev's choice at some far point in the future. While solving the problem, why not also be good to our future selves....
I agree, too much GIF, but nice opinion whatsoever.
An affirming as well as enlightening post. =)