
Why developers need to be able to identify technologies with staying power - axiomdata316
https://medium.com/netlify/leveling-up-why-developers-need-to-be-able-to-identify-technologies-with-staying-power-and-how-to-9aa74878fc08
======
projectramo
Here is the thing: what prevents me from learning a new technology is not that
I don't get the "big picture" concept which inspired it. Cognitive load-wise,
these concepts aren't difficult to grasp in the abstract.

What slows me down is the little implementation detail that is causing this
weird bug that I just don't understand.

And if it is a new technology, then stack overflow doesn't have the answer.

So, to take the example the author gives, when Rails was new, its not that I
didn't understand the MVC framework and how the roles were different. I didn't
understand that RVM had to be set to a default ruby version every time I
restarted the console.

~~~
sharadov
You nailed it, I'll pick up the technology, but then get stuck in some silly
bug which I can't find the solution to and abandon it after getting
frustrated.

~~~
DanielBMarkham
But that's actually the work: getting stuck, sticking with it, and reasoning
your way out of being stuck. That's programming.

Fair enough if you avoid certain situations because this is where you end up
-- I do the same thing -- but the work is the work whether it's a new language
or some oddball patch/upgrade that made things act funky in ways they didn't
before.

~~~
dmortin
There is a difference between learning a system and getting stuck on some
configuration detail. It's very frustrating when you want to understand a
system and you're stuck with some error which is not your fault, but it's some
bug in the new technology and instead of learning the technology you spend
time with hunting some configuration bug.

That won't help you learning the technology, because that bug will be fixed in
some configuration script and later users won't even encounter it, because the
tooling will generate the proper scripts for the first time. So it's often not
that kind of knowledge which proves to be useful later, but some
implementation detail which you won't ever encounter again.

~~~
bunderbunder
This is roughly my litmus test: Do I see a lot of examples of people running
into problems, and the solution turns out to be an obscure configuration (or
worse, a case where the default configuration is something that should never
be done)? Do I see evidence of a lot of cases where the right way to do things
is not the obvious way to do things?

Both of these are red flags. Sure, I can learn how to steer around all the
potholes. But so will everyone else who works on the project. Eventually
someone will miss some important detail, or go on a refactoring expedition and
end up removing a bunch of what appears to be excess complication but is
actually a carefully constructed workaround for some wart in the system (the
comment explaining this having long since been deleted - or maybe migrated to
the team wiki, where all good information goes to die - by someone who had
been watching a lot of Uncle Bob videos on YouTube at the time), and then
production bugs sneak in, and eventually people quite rationally start to
blame the technology.

~~~
davidjnelson
I agree it's a great idea to leave comments in code, for things that are done
in a non obvious way for good reasons.

~~~
xsmasher
The highest purpose a comment can serve is to explain why you're doing
something (which looks) stupid.

------
stupidcar
Stuff like this is what puts me off React:

[https://reactjs.org/blog/2018/03/29/react-v-16-3.html](https://reactjs.org/blog/2018/03/29/react-v-16-3.html)
[https://reactjs.org/blog/2018/06/07/you-probably-dont-
need-d...](https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-
state.html)

It's at v16, and they're still making major changes to the basic component
lifecycle, deprecating things, and then almost immediately having to write
articles to teach against anti-patterns that already arisen in the new APIs!

A programming model that is so unintuitive people still cannot use it right,
even after so many years, does not seem like a great bet to me.

~~~
djstein
I'm not sure if you actually have ever used React but every single major
version update is non breaking. The topics discussed in the link provided are
discussing how an internal library is being updated (Context API) and how
these functions are being depreciated in version 17
([https://reactjs.org/blog/2018/03/27/update-on-async-
renderin...](https://reactjs.org/blog/2018/03/27/update-on-async-
rendering.html)). The above depreciations are functions that typically should
not be used in a v16 React application anyway! Using them typically means
there lies a bug in your props updating logic.

~~~
flukus
> I'm not sure if you actually have ever used React but every single major
> version update is non breaking.

That would be fine if they were making major releases every 2+ years, when you
release a major version on average of 3 times a year it's incredibly unstable.
A typical upgrade will be jumping several versions.

~~~
gr__or
A major version change of React is different from a major version change in
Angular. I upgraded several React apps of variying sizes from 14 to 17 over
time and none of these upgrades took more than an hour.

Don't get confused by the version labeling scheme.

------
bsenftner
One can nit pick some of his points, but the general essay is right on point.
Developers need to understand what they are building on top of to be able to
navigate non-trivial problems.

I found this article from Saturday worth the read, as it explains what Docker
actually is, and why no one needs it:
[http://catern.com/posts/docker.html](http://catern.com/posts/docker.html).

The same goes for everyone working in the cloud; I've build my own clusters to
compare the effort and expense (rather than just accept the marketing line)
and running one's own servers, from one to hundreds, is exponentially more
cost effective than any cloud service.

People are not doing their homework, and the herd mentality owns the entire
tech industry.

~~~
twblalock
> People are not doing their homework, and the herd mentality owns the entire
> tech industry.

I've seen that, but I've also seen individual engineers and entire departments
refuse to move on from what they are using. When they eventually realize they
need to change, they are a lot further behind than they were initially, and it
takes a lot more work to catch up.

A lot of organizations are getting real value out of Docker (and Kubernetes
and NoSQL and React and all of the other trendy new things), and saying that
"no one needs it" is just as myopic and wrong as being part of the herd
mentality.

~~~
mmt
> A lot of organizations are getting real value out of Docker (and Kubernetes
> and NoSQL and React and all of the other trendy new things)

At the risk of nitpicking a word that may have been just used for emphasis,
how can you be sure the value is real, though? Perceived value can be tough to
tell apart, especially in a monoculture (called "herd mentality" earlier,
perhaps too uncharitably).

Also, even if the value is real, is it technical, or political/behavioral? If
it's the latter, that doesn't minimize theri value, but let's not pretend
their advantages are technical. We could, instead, discuss if using the new
tool is the best (or only) way to effect that change. It may be. It may even
be that _which_ tool it is doesn't matter, so long as it's different, as has
turned out to be the case in ergonomics and RSI.

We've certainly seen some negative "NoSQL" headlines. How many startups used
it to their eventual detriment, just following a trend and/or doing premature
optimization? I'm not saying it _can 't_ provide value, rather than mere
popularity and even _perceived_ value, especially initially [1]

> saying that "no one needs it" is just as myopic and wrong as being part of
> the herd mentality.

I think that's what's called a "shallow dismissal" and is discouraged by the
guidelines. The bare statement would be mere hyperbole and could possibly be
"just as" wrong, but it was in reference to an entire article, which lays out
the technical reasoning, which it's up to you to refute and point out they
myopia of.

[1] I am reminded of how "easy" MySQL replication was always touted to be..
except that people choosing it did so with an empty database. If it broke,
with a far-from-empty database, I found myself wishing for one of PostgreSQL's
much more "difficult" options.

------
EduardoBautista
This is why I choose Ember as my framework of choice. It's been there since
Backbone, since Angular, and now React.

React, in my opinion, is filled with "best practices" where they choose
complex solutions to simple problems. The dependency hell is also ridiculous
in React. I would like to see how many of these apps are having issues
upgrading to the latest versions of their dependencies in 5 years.

~~~
noir_lord
It's also why I chose Vue over React.

In terms of capabilities they are fairly similar _but_ the the existence of an
_official_ router and _official_ state management store means that the "things
that can break in horrible ways" surface is reduced.

I stuck with KnockoutJS for a long time because they had (for a JavaScript
project) incredible backwards compatibility and stability.

I've been programming long enough that "the new hotness" is of much lower
interest than "what capability does it give me I don't have and will I still
be able to build/deploy this in 3 years if I need to".

Also if something seems _amazing_ I'll wait a year, if it was amazing it'll
still be amazing in a year and I'll have 365 days of other people smacking
their heads on the not amazing parts.

~~~
Kiro
What's the official state management?

~~~
lhorie
vuex

------
acconrad
> _For example, Object Oriented Programming became Functional Programming_

What? No it didn't. An imperative language is the opposite of a declarative
language. OP might want to edit this one.

~~~
rpowers
It is pretty clear that the author meant OOP -> FP with respect to popularity
and NOT literally transformed from one to the other.

------
GuB-42
That's called experience. This is the reason why senior developers are
normally paid more and make the important decisions.

And what the article tells is that you should actually get interested in what
you are doing, if you want to become experienced and not just old. That should
be common sense, but I guess it is worth repeating from time to time.

However, if you don't have 30 years of experience, ranging from coding on a
C64 to modern JS frameworks, the Lindy effect (older technology tends to stay
longer) is a good shortcut.

~~~
swsieber
To build upon your comment:

It's not because older technology is inherently better, but it's because if
older technology is still relevant, it's survived the "will it be relevant in
the future" test once before.

------
IloveHN84
This obviously is a problem of new languages/high dynamical frameworks..

Why this isn't happening for languages such as C, C++, Java? Sure, new
standards are kicking in, but you can still program using old standard, it
will continue (more or less) to work.

Why do JS developers follow overhyped frameworks? I do not understand.. the
few times I've programmed in JavaScript, I've always used jQuery: it might be
old school, but it does its job well and bootstrap is still using it too.

------
mgrennan
I have developed a term for this. EARLY ADOPTER TECH DEBT.

~~~
ak39
Early Adopter Margin Call

------
blackrock
Which technology stack would you recommend going forward? And why?

Node.js? Vue.js? React? Angular? Elm?

I can't keep up with the Javascript tower of babel anymore.

And what happened to Django? Nobody seems to talk about it anymore.

~~~
deltron3030
> Which technology stack would you recommend going forward? And why?

With React you have the most options and biggest community, including ways to
shoot yourself in the foot. It's preferred by full stack JS guys who also use
node, so it could be great if you're a startup and can hire somebody who can
do everything.

Angular is popular with enterprises who know what they need (a stable
environment at scale with strict rules), who have a high budget for hiring
specialists, the whole framework is more complex.

Vue sits in between Angular and React, but more geared towards smaller
businesses and their needs. It's very popular with PHP devs, and full stack
devs who don't use JS exclusively. The main advantage is peace of mind,
knowing that everything works well togehter.

Elm is very opinionated, but also very different from those other frameworks.
In React or Vue you start thinking of components, in Elm you think about
functionality, and create components as they emerge from patterns, potentially
leading to a more cohesive and elegant result.

But that's not how designers used to work. Bridging the gap between designers
and devs, and how they currently work, is the main advantage of React and Vue
imo. Web designers (like graphic designers) are used to think in whole pages,
or layouts, and break things down from there (top-down). React and Vue and the
component first paradigm is a compromise, where devs aren't degraded into only
doing the implemetation, and designers aren't degraded into doing the styling
only. It still respects both roles.

Elm is basically the next level for designers, or designers who like to code.
It's how design that left the analog world behind could be.

------
mabynogy
"A trailblazzer doesn't follow a trail" as Terry Davis says.

