Can I add two incredibly cynical things to the list?
First, never use version X.0 of anything. Let the early adopters find the egregious bugs.
Second, if some tool suddenly becomes wildly popular don't look at it immediately. Make a note in your diary two years down the line to have a look at it. Separating hype from quality takes time and, just like with version X.0, your time is better spent letting other people do that for you.
Agree except I check back for a few months not years. Taking risks on new things is fine though. Otherwise we wouldn’t have iPhone with new parts etc but things do need vetting
The iPhone is a great example of not looking at anything hyped for two years. It took two years to become suitable for anyone except Apple fanboys. Version 1 had basically no internet - it couldn't do 3G - you couldn't copy n paste, you couldn't even add third party software. Version 2 was pitifully slow. Version 3, the 3GS, was the first really usable product. It came out ten days short of the second anniversary.
Addendum to your "Second": if some tool becomes wildly popular suddenly, it's usually shit. (This reinforces the "make a note to look at it two years down the line").
This is great advice, for a stable-job kind of person (i.e. looking for a good work-life balance). If you're hired, preferably in an already established company, then follow this advice and you'll stay away from trouble forever <3.
But life is dull with no trouble at all! You'll end up writing monolithic backends using Perl in 2020 😅. Not that there's something wrong with Perl per se, but we have better options for that today.
Also, when trying to bring something new to the market, or if you're really into continuous learning, using new techs can help your company/personal brand.
You'll be among the first to have know-how in a hopefully rising tech. As the hype grows, you'll have a very good position to negotiate from.
Of course, using x.0 (or betas/alphas) most of the times means actively participating to the product/library. This means effort, but also good opportunities to learn stuff.
"Separating hype from quality takes time" - yeah, but at the same time if you do go by the quality of experience and learning, there's no harm in being part of the process that separates hype from quality. If all you care about is the grind of delivering someone else's ideas, sure ... you can get by on letting others be at the forefront of a new technology.
It's a risk, sure, to get involved with something that burns out as a hype but if you're a technologist then even that has a positive spin since if you do it often enough, you already have what it takes to not be tied down on a particular 'thing'.
Definitely this is by far the best generally valid advice, everyone should create their own overhyped tech nonsense, disregard what anyone else is doing unless someone else validates it first and happily live in their own bubble which they rule. If presidents can do it, so can everyone else.
Can I add two incredibly cynical things to the list?
First, never use version X.0 of anything. Let the early adopters find the egregious bugs.
Second, if some tool suddenly becomes wildly popular don't look at it immediately. Make a note in your diary two years down the line to have a look at it. Separating hype from quality takes time and, just like with version X.0, your time is better spent letting other people do that for you.
Agree except I check back for a few months not years. Taking risks on new things is fine though. Otherwise we wouldn’t have iPhone with new parts etc but things do need vetting
The iPhone is a great example of not looking at anything hyped for two years. It took two years to become suitable for anyone except Apple fanboys. Version 1 had basically no internet - it couldn't do 3G - you couldn't copy n paste, you couldn't even add third party software. Version 2 was pitifully slow. Version 3, the 3GS, was the first really usable product. It came out ten days short of the second anniversary.
Great advice, thankyou 🤗
Addendum to your "Second": if some tool becomes wildly popular suddenly, it's usually shit. (This reinforces the "make a note to look at it two years down the line").
This is great advice, for a stable-job kind of person (i.e. looking for a good work-life balance). If you're hired, preferably in an already established company, then follow this advice and you'll stay away from trouble forever <3.
But life is dull with no trouble at all! You'll end up writing monolithic backends using Perl in 2020 😅. Not that there's something wrong with Perl per se, but we have better options for that today.
Also, when trying to bring something new to the market, or if you're really into continuous learning, using new techs can help your company/personal brand.
You'll be among the first to have know-how in a hopefully rising tech. As the hype grows, you'll have a very good position to negotiate from.
Of course, using x.0 (or betas/alphas) most of the times means actively participating to the product/library. This means effort, but also good opportunities to learn stuff.
"Separating hype from quality takes time" - yeah, but at the same time if you do go by the quality of experience and learning, there's no harm in being part of the process that separates hype from quality. If all you care about is the grind of delivering someone else's ideas, sure ... you can get by on letting others be at the forefront of a new technology.
It's a risk, sure, to get involved with something that burns out as a hype but if you're a technologist then even that has a positive spin since if you do it often enough, you already have what it takes to not be tied down on a particular 'thing'.
I'd rather spend my time creating my own overhyped nonsense instead of figuring out what other overhyped nonsense is any good.
Definitely this is by far the best generally valid advice, everyone should create their own overhyped tech nonsense, disregard what anyone else is doing unless someone else validates it first and happily live in their own bubble which they rule. If presidents can do it, so can everyone else.
You forgot /s
Yeah, I hate it when that happens ;)