
“How” ages faster than “why” - mooreds
https://hackernoon.com/how-ages-faster-than-why-712e25c9eb3b
======
bungie4
Sweeping statement from somebody whose been doing this for 35+ years. Learn
core technologies. Not things built from those core technologies. Ya, you'll
still have to learn the secondary stuff, but at least you have a really good
idea what will NOT be around in 10 years.

~~~
squirrelgod
What are some examples of core technologies?

~~~
mooreds
I saw an amazing presentation at a ruby meetup about database indexes for
developers (for example). Will see if I can dig it up.

~~~
mooreds
Here you are. The slides aren't as good as the tall (as you'd expect) but
still may be helpful.

Other core technologies (in my opinion): cookies, http, TCP/IP, caching.

~~~
mooreds
Ack, forgot the link: [https://speakerdeck.com/heimir/databases-for-
developers](https://speakerdeck.com/heimir/databases-for-developers)

------
niftich
This could be one of those insightful posts that elegantly state an
observation in a lasting way, and one that we'll repost every few years or so
as an adage on programming. But there's a few reasons why I think it falls
short:

\- It doesn't explore any of the reasons why the APIs -- the "how" \-- age in
a backwards-incompatible way. Not all cases are equal: a clean break is the
surest way of dooming the old and ushering in the new, but this rarely means
that old code was broken beyond all belief: even if the underlying framework
made some simplified assumptions, the code probably worked okay most of the
time, especially if we assume intelligent, competent developers familiar with
with the underlying patterns, using a framework for its merits. A good
hypothesis is that frameworks aren't solely there to help _you_ solve problems
with less code, but also to help others' understanding of the same codebase.

\- Yet even the article insinuates that we can't assume the previous all the
time, because many developers _understand_ design patterns by first coding
themselves into a situation where they would be sorely needed -- this happened
to me, for example. The same way the article's hypothetical developers acquire
_enduring knowledge_ , I didn't understand why I'd need dependency injection
until I experienced firsthand the frustrations of handling dependent objects
the naive way, and found myself re-invening it independently. This leads to
the possibility that not all frameworks are picked solely for their design
choices, but instead popularity, code availability, ecosystem health, press,
advertising, or word-of-mouth may be factors.

\- If so, this still doesn't account for why new frameworks rise and all the
time, which would logically begin disadvantaged by having smaller ecosystems,
less popularity, less name recognition. What is there to gain by starting a
new one? This is really a variation of point #1: there's a lot of subject
matter to be explored here, and yet it's left unsaid.

~~~
codr4life
\- Maybe api:s aren't meant to last, maybe rewriting more is the piece missing
from the puzzle. Always leaving evolution up to others doesn't really work if
we all do it at the same time, and your brain is as good as mine when it comes
to recognizing truth.

\- Picking frameworks is a bit like picking presidential candidates, the whole
game is rigged from the start. Once upon a time software was about solving
problems, about working creatively based on your own experience. We can still
learn from each other, and share code; but I feel the push towards
standardizing on over engineered, general purpose code is misguided; like
we're staring at fingers pointing at the moon, arguing which finger is the
perfect one.

\- New frameworks arise because needs aren't being met by the current status
quo, hence we need innovation to get out of here. Where did this obsessive
focus on popularity come from, anyway? I couldn't care less who did what, as
long as we keep moving forward.

------
maxxxxx
That's why people shouldn't chase the latest frameworks but instead understand
some fundamentals. Those don't change that much over time. If you just move
from Angular to React or whatever other thing is hot right now every year for
20 years but don't understand what fundamentals they are based on you have the
proverbial "20 times 1 year experience" instead of 20 years experience.

~~~
dualogy
> _If you just move from Angular to React or whatever other thing is hot right
> now every year for 20 years but don 't understand what fundamentals they are
> based on_

That person would have to be (and remain so for 20) spectacularly, blissfully,
implausibly obtuse ... given the minimal cognitive capacity needed to hop from
each of the 20 upcoming Angular/React equivalents to the next every year will
likely both suffice and entice to "osmotically absorb" said "fundamentals"
behind them all over time, even when never spelled out.

I think quite a few of us grasp the principles of this or that tech first
informally by trial/error and experimentation, later when reading "the spec"
or the "fundamentals book" or whatever always flip-flopping between "I know, I
figured it out the hard way, smart me hehe" and "I know, I know, tell me what
else is new!!"

------
Silhouette
In a very meta kind of way, this is a great case study in the general way that
humans acquire new skills and understanding. Grossly oversimplifying the
research that's been done into this, we start with very specific things, and
progress towards more general cases as experience and skill grow, until
ultimately we (hopefully) reach a level where the fundamentals become
intuitive.

Sadly, the next horrible insight a lot of people reach in the context of
programming specifically is that while experienced, skillful developers can do
everything the newbies can and more, for a great many commercial applications
the newbie who has only the specific skills useful for a few months will cost
far less than the expert but still produce acceptably good results. This
explains a great many things, from the ageism and burn-out that are
unfortunately all too common in our industry to the generally poor quality and
often short lifetimes of a lot of software that gets shipped.

I'm hoping the next insight after that is how you fix those problems and
achieve a step-change in the benefits our whole society derives from software
by being able to use the extra skill and experience of the better developers
in a viable way, but sadly I have yet to reach that level of enlightenment
myself.

------
zitterbewegung
I agree that how ages faster than why but I would like to add that how ages
slower than people think how ages.

~~~
stephengillie
Could you be more specific?

~~~
TazeTSchnitzel
I'm not the person you're replying to, but: technology stacks live for a long
time. What's hot changes, but what was hot yesterday and the day before will
still be in use for many projects, including new ones, for a long time. And
equally, it takes a long time for something to become greatly popular.

~~~
acqq
You're exactly right. One simple example:

Numpy for Python, Building from source:

[https://docs.scipy.org/doc/numpy-1.10.0/user/install.html](https://docs.scipy.org/doc/numpy-1.10.0/user/install.html)

"Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN
77 compiler installed."

It also nicely demonstrates how with the new levels of abstractions we
preserve the "hows" but hide them from a lot of the users.

------
jpgvm
This is very true.

However "why" can be very wide ranging. Sometimes it can be theoretical,
sometimes it's simply due to emergent phenomena that is unescapable for
various reasons

Sometimes "why" is because of anothers "how". A good example of this is how
the "why" of many things can be explained by "how" C does it.

------
sametmax
Yeah but you can't usually understand "why" before getting some "how".

------
khana
This is an important point to make imo. The human brain works better at
knowledge retention on the "why" category more than the "how" indeed.

~~~
codr4life
Why is making connections to prior experience, turning knowledge into wisdom,
and gaining a unique perspective on truth. It's a completely different game
than stacking facts on top of each other. Why is creative, and what is created
can never be taken away; how is useless once obsolete.

