
Expiring vs. permanent skills - tonyedgecombe
https://www.collaborativefund.com/blog/expiring-vs-permanent-skills
======
nayuki
The article was about soft skills (a.k.a. interpersonal skills), but I most
clearly see the distinction between expiring vs. permanent skills in my field
of study, computer science + software development.

When I look at what's hot - in people's blogs, in bootcamp classes, and in
what people like to boast about - I see stuff like the React framework and
Node.js and MongoDB. Having been in the industry long enough, I've watched
these top trends change every few years.

Meanwhile, what I learned in university is all the unpopular stuff but that
which underpins the technologies we use today. For example: Mathematical
proofs, regular languages and automata, time complexity, computability,
balanced trees, assembly language, recursion, pointers, declarative rules,
SQL, various subsystems of operating systems, etc. This stuff gets mentioned a
lot less in popular discourse, but I find that my knowledge in these areas
accumulate over time instead of going out of date with each new fad. Moreover,
I find that this set of knowledge continues to help me understand and work
with new things that come out in this field.

~~~
dkarl
> SQL

Generation after generation of programmers takes one look at SQL and decides
it would be more convenient to believe that relational databases don't solve
any of their problems.

If there's one thing I would recommend to engineers at any point in their
career it would be to, if they haven't already, learn enough SQL and enough
about relational databases to feel comfortable using them for what they're
good for. You start to see a whole class of problems as solved. And there are
still plenty of cool problems to work on that relational databases don't solve
well.

~~~
cheez
And if you aren't convinced, SQLite (and postgres) implemented MongoDB as a
feature ;-)

~~~
StavrosK
Which should be used very sparingly, unlike the actual MongoDB, which
shouldn't be used at all.

~~~
jointpdf
I’ve heard (way) more than one story about MongoDB mysteriously annihilating
_all the data_. Launched into oblivion.

The worst imaginable outcome for a database.

~~~
TimTheTinker
It's worth mentioning that MongoDB used to have a terrible storage engine--and
it would do all sorts of stuff like this under stress.

But it was replaced with a much better engine (WiredTiger) with write-ahead
journaling and checkpoints around the year 2016.

~~~
jlokier
In 2020, MongoDB continues to fail consistency tests.

"Jepsen Disputes MongoDB’s Data Consistency Claims"
[https://www.infoq.com/news/2020/05/Jepsen-
MongoDB-4-2-6/](https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/)

"MongoDB 4.2.6"
[http://jepsen.io/analyses/mongodb-4.2.6](http://jepsen.io/analyses/mongodb-4.2.6)

------
vii
The example of Ulysses S. Grant being the best student in his class for
painting makes it clear that acquisition of these so called expiring skills is
associated with long term success. The list of non-expiring skills has good
intentions but the entries are weak and unjustified. It's odd that the article
keeps emphasizing getting along with people so many times as a non-expiring
skills when President Grant was famous for being strong-willed. It might be
inferred from his career that conflict even with authority is actually a
valuable skill, though you could argue it goes with the many bad behaviors he
exhibited which turned out to be not a disqualification for highest office.

To be successful in a competitive field like business or the military you gain
advantage by improving your mechanics. These skills, like wielding a sword,
drawing accurately as in the article or in software using a particular
programming language, allow you to succeed at specific tasks. This causes you
to be respected by other practitioners, which gives you practice in the next
level of skills for larger scale collaborations.

As tools change, you have to keep up. Leadership skills like motivating
people, facilitating decisions, and persisting through adversity are
generalisable across situations. However if you are unfamiliar with the
mechanics you will trust the wrong people, not know which questions to push
on, and persist in expensive mistakes. You can't skip these expiring skills.
They are an essential foundation.

~~~
wenc
Very true. To me, categorizing skills on the dimension of expiring vs non-
expiring seems to be implying the latter has greater value than the former.
This isn't true in all situations.

Foundational skills are just that -- foundational, in that they are a base to
build upon. The stronger your foundation, the stronger your base on which
other skills are attached. That said, the base itself it rarely enough. I'm
sure we've met people who've mastered the foundations but have never done
anything interesting in their lives. I have friends who were super good at
calculus and linear algebra (the foundations for engineering math) in college
but never amounted to much in their careers.

On the other hand, it is sometimes in acquiring so-called expiring skills that
we begin to see patterns of the foundations skills that would be useful.
Thoughtful programmers without CS degrees -- who have written code for years
-- often find SICP a revelation that validates or corroborates their
experience in the real world. On the other hand a college instructor who's
taught SICP for years and can recite it from memory may never know how to
apply it because he/she has never learn the "expiring" skills necessary to
execute in the real world.

Some people change the world on so-called "expiring skills" \-- because even
though they are only useful for a season, they might be very high leverage
during that season, and it gets you into the game. Once you're inside you can
pivot. I knew a bunch of folks (with no prior programming backgrounds) who got
their start from PHP (an expiring skill) and are doing well today.

I cut my teeth real-world programming with Perl (arguably a expiring skill).
It was very much non-foundational (I would never do things today the way I did
them in Perl) but it was my foray into real-life programming and it got me
gigs. I wouldn't have gotten into programming if I had studied programming via
a foundational CS curriculum.

------
gchamonlive
I am kinda experiencing this in my journey learning cloud solutions.

When I first started two years ago, all AWS solutions were really interesting
and I was deeply hooked. Managed systems were the way to go. And that is
explainable. We sysadm all lived the hassle of maintaining live production
systems, and the thought of delegating all this maintenance while focusing on
the core functionality is quite seductive.

Many caveats arise, though. Integration although native in AWS is not without
its inherent complexity. Costs are opaque. Performance is sometimes subpar.
And when something breaks it can take a while to debug a proprietary, closed
application, not to mention when you come across an actual cloud framework bug
or downtime.

I was painstakingly rediscovering the flexibility of self-managed systems.
Yes, there is more maintenance work, but the core skills related to managing
your own cluster of computers is timeless, while tying yourself to a vendor or
framework is a gamble that can bite you hard in the long run.

Edit: I am not advocating against using cloud solutions. The ideal scenario is
something between managed and unmanaged solutions, the best of both worlds,
but that has to be studied in a case by case basis

~~~
Izkata
Was this meant to be on
[https://news.ycombinator.com/item?id=24141628](https://news.ycombinator.com/item?id=24141628)
?

~~~
gchamonlive
No, containerized applications is a fraction of what AWS offers. It comprises
only beanstalk, ecs and eks as far as I know. What I am tracing is a reference
between expiring skill -- cloud specific -- and permanent skill -- cloud
agnostic.

~~~
starfallg
Lambda and serverless is pretty much built on containers - only Cloudflare
Workers isn't.

~~~
Chyzwar
I think AWS lambdas and Fargate are using firecracker[1].

[1] [https://aws.amazon.com/blogs/aws/firecracker-lightweight-
vir...](https://aws.amazon.com/blogs/aws/firecracker-lightweight-
virtualization-for-serverless-computing/)

------
Timpy
The example of artistic skill translating to military cartography was the most
interesting part of the article. Tell me HN, what are your expiring and
permanent skills?

I would cite knowledge of a particular software as a rapidly expiring skill.
You can learn a particular software and become an absolute productive genius
in it, but let a couple years pass without touching it and you'll return to
find the software has changed, and your relentless speed and muscle memory is
constantly crashing into the changes.

The most permanent skill I can think of is being able to gain knowledge from
books. Sitting down with a text and really being able to glean knowledge from
it. I don't think that skill is ever going to expire.

~~~
alexpetralia
Yes, I would generalize a bit more and say the most permanent skill is the
ability to learn & adapt.

Can you learn from your social faux pas? Can you learn how to collaborate more
effectively? Can you learn new software? Can you develop structure in highly
uncertain environments?

It is the rate at which one can adapt that I find to be most permanent. (In
other words, and with some irony, the thing which is the most permanent is the
capacity to change.)

~~~
gjvc
This is the best answer.

------
FooBarWidget
It's interesting that this article mentions "getting to the point". My
personal experience with this sort of thing, is that people who are impatient
to the point of saying "get to the point" after 5 seconds, have issues
themselves. For example they are stressed, and their desire for everybody to
"get to the point" is just a proxy for their desire to do something about that
stress. That "quick decision making" of theirs then comes back to bite them
later because being fast just means they haven't thought things through, and
their plan was full of holes.

Yes, some people are bad at explaining things, and could do it more
effectively and more efficiently. But the receiving end isn't altogether
"innocent" either: their state can hugely change the interpretation of the
message, sometimes in pathological ways.

~~~
paulsutter
There’s a big time savings in giving the conclusion first, then backing
through only the needed part of the explanation.

When people give the conclusion/recommendation last, it feels like they’re
either disorganized, have a low estimation of others, or are trying to control
the outcome with unnecessary persuasion.

The right recommendation usually can stand on its own and eliminates all that
buildup. Try it sometime.

~~~
exotree
This tells me you are either an executive who has forgotten how much work it
takes to convince you and your peers that a solution actually works or you are
an employee who has not had the experience needed to report up to an
executive.

Executives who typically want “conclusion first” for “time savings” often use
up the same amount of time or more “backing through the needed explanation.”
Does that mean you shouldn’t aim to be succinct? No. You should have talking
points prepared. But OP is mostly on the nose. This sort of demand for
conclusion sans explanation only to go back over what you would’ve explained
anyways is usually driven by external stress.

~~~
nostromo95
The point of conclusion-first isn’t necessarily to save time, it’s so I (as an
executive) can pressure-test / place into context all of your ensuing
explanation because I know what your end-point is.

This isn’t unique to business...academic papers have abstracts that do this;
math proofs have the statement they’re proving up-front.

~~~
nostromo95
Really this is just the scientific method.

------
system2
Pretty much article tells us to be nice people. I agree, at any workplace
those would apply. Blanket term for it is probably "team player". I was
expecting more of a technical analysis like "understanding coding basics".

~~~
hw8kw13
Given its analogies to fields not directly related to software engineering,
like military and finance, I suspect it’s targeting a broader audience than
developers.

------
k__
I didn't do a coding bootcamp, but I have the fear that teaching "expiring
skills" instead of "permanent skills" like it's done at university, will set
us back in the long run.

~~~
pedro596
Agree, a lot of guys complain about the "nonsense" that is taught at
universities, and sometimes they are right, but other times it is just the
core of things/other approaches/historical facts that don't have a clear
objective but are very important in the long run. Normally I find it hard to
learn those on my own through internet, not because they are not available but
because you don't clearly see what to do in the next day with them. While at
university you may not care much at the moment but you get to explore them
because otherwise you fail.

~~~
MaxBarraclough
At the same time, universities could sometimes do a better job of letting
students see why it's important to learn something. A great example is matrix
determinant, which at first glance seems like an entirely arbitrary invention.

The _3Blue1Brown_ YouTube channel does a great job with this, introducing the
determinant in terms of geometry. It puts the geometric meaning of the
function first, introducing the strange looking formula later on. _edit_ And
of course, it does all of this with excellent visualisations.

[https://www.youtube.com/watch?v=Ip3X9LOh2dk](https://www.youtube.com/watch?v=Ip3X9LOh2dk)

------
hosh
Over the years, I've learned things from different domains -- gongfu (martial
arts), Go (the game not the language), various computer languages, and most
recently, gardening.

It's been my experience that for every expiring skill, there is hidden, a more
essential, permanent (or rather, "timeless") skill.

The technical skill for drawing and recording the battlefield topography is no
longer relevant.

But you can bet that spatial reasoning and situational awareness / situational
reasoning and topography is still relevant for the military professional,
whether someone is drawing the maps by hand, or using modern navigational
devices.

Having to construct maps (mapping the actual terrain with an abstract
representation) helps construct a model in the mind, and doing so lays the
foundation for developing spatial reasoning. An artist's eye is trained to see
things as they are seen, not as they are interpreted, thus disciplining one's
perceptual skills, which enhances situational awareness.

One of the things I have learned from gongfu, is that once you have refined
the essential skill, it can be applied broadly in many other domains, outside
the one you initially learned. Those seemingly disparate domains I listed
(martial arts, Go, computer languages, gardening), all share essential skills
that allow me to transfer things that I learned in one domain into another
(with modifications).

~~~
rmellow
Can you concretely explain how these domains share the same skills?

~~~
hosh
In one example:

One of the things in martial arts is to use footwork to control space, and the
possibility space in which someone can move or respond.

There is a similar thing with Go, changing direction of play, or reducing
potential eyes, etc.

Those two are adversarial examples. The latter two don’t have to be.

With language platforms, the chosen semantics and primitives for library code
defines a possibility space. It can be created in a way to encourage or
discourage best practices when other people use it.

In gardening, we are really talking about an ecology. In a simple example, you
are taking into account the path the sun takes and the vertical space a plant
takes (canopy layers), which can encourage or discourage growth. Add things
like companion planting, water cycle, carbon cycle, ecological succession,
crop rotation, succession planting, integrated pest management etc. it is more
about shaping the possibility space of the site.

------
tehjoker
Soft skills are important, but everyone knew that already. Each field will
have certain skills that are fairly permanent that are things that distinguish
it from other fields. In computing, these things are understanding computer
architecture, knowledge of common algorithms, etc.

However there was one item that stood out for me in the article: "The ability
to distinguish “temporarily out of favor” from “wrong." The only way to do
this is with technical insight born of study and practice of engineering
fundamentals and also knowledge of history. History is something you can study
and can learn a great deal from. Everything that people say is the new hotness
came from somewhere and nearly always is a modern reflection of something that
has happened before. It doesn't give you the power to predict how things will
happen, but you can often predict the range of possibilities, and it's usually
not what is being hyped. The hype is usually driven by profit seeking and
careerism, and so the predictions are partly hollow.

I knew a guy that was working on CPU algorithms when GPUs were becoming
extremely hot. I was concerned that he was working on something that would
become outdated too quickly. He told me that these things go in and out of
fashion over a period of years, and to a certain degree he was right. Around
that time Intel came out with Knight's Landing, Knight's Corner, etc and
AVX-512. While it seems like that architecture is not exactly panning out
popularly, it did show that general purpose CPU architectures were able to
produce the kind of FLOPs that were competitive. It makes me think the cycle
will continue though GPUs continue to race ahead.

------
holidayacct
We should try addressing another issue, there shouldn't be expiring skills in
the first place. A lot of the tools and software that are being called
"expired skills" aren't even old enough or mature enough to expire in the
first place.

There are eight new frameworks for every new language someone invents every
few years, which is ridiculous. It can take decades for software to mature to
the point where it is reasonably stable and secure. It takes millions of
collective man hours to write the software, millions more man hours to fully
document it and then people spend their whole lives maintaining and defending
the software from attackers. People get burned out and all that effort gets
wasted so people can create a new "skill".

~~~
pojzon
We are too busy writing new stuff to think about whether something doesn’t
already cover our needs. Additionally alot of high profile programmers have to
„prove themselves” to the world by reinventing a wheel but supposedly „make it
better”.

I see that especially in the world of relational databases.

------
motohagiography
We used to call these virtues:
[https://en.wikipedia.org/wiki/Virtue_ethics#Lists_of_virtues](https://en.wikipedia.org/wiki/Virtue_ethics#Lists_of_virtues)

They are also covered in the notion of "durable skills," which have previously
been called "soft skills"
[https://en.wikipedia.org/wiki/Soft_skills#Future_Labour_Mark...](https://en.wikipedia.org/wiki/Soft_skills#Future_Labour_Market)
, which aren't very instructive, but good for post hoc explanations.

Employee skills and virtues are also different from manager, leader,
professional, or founder virtues, which are mainly about adaptability and
appetite for risk.

------
Spooky23
It’s a shame that Grant was just used as a prop for some business babble.

Grant was an interesting man, great with horses and possessed with a calm
focus in battle. But he battled depression and alcoholism and failure in other
aspects of life.

To open with him and pivot to “don’t be a jerk” is inane.

------
natchy
> Not being a jerk

I don't like that word. It seems like subjective name-calling. One might say
how they really feel at the risk of being a jerk, but that depends on how the
other party takes the feedback.

I think a better rule is "Not being hostile".

------
vrnvu
A similiar idea related to learning is how we build knowledge, how we actually
learn and what are those steps. Consider learning as a procedure to build a
tree of ideas and relationships between them that you want to use.

We can take a bottom-up approach where we start by learning the thoery and
then you apply it to build a product, to physics, to engineering...

The top-down instead focuses on obtaining a result first, you learn tools and
frameworks to solve a problem and you fill the holes you need as you encounter
them.

Permanent is theory, foundamentals. Expirating are tools, libraries and
frameworks.

Learning statistics + probability vs learning keras or tensorflow i.e.

------
nautilus12
Hence the value of liberal arts. And yet I have spent my whole career feeling
behind. The permanent skills didn't seem to serve me that well, or society
shifted to deemphasis them over pure transactional technical work

------
csneeky
I love that the article focuses on interpersonal skills... too often the knee
jerk reaction (as software engineers) is to view "skills" through the narrow
lens of engineering (various computer science topics, competency in a
language, mathematics, etc).

As I've grown I find soft/interpersonal skills to matter more and more and in
many ways, now that I'm a seasoned engineer, trump the hard skills in terms of
what impacts my career trajectory. I'd advise any junior/intermediate career
software engineer to take the advice from this article seriously.

------
exdsq
I was really excited to see something about logic vs react, or linear algebra
vs pytorch. While I agree with the soft skills, I’d be keen for a v2 with hard
skills too!

------
astroman455
Interesting, but the one thing I would want to add to this is that expiring
skills are often sort of gateways to permenant ones. By this I mean that
learning a coding language that is going to not be in vogue in 5 years still
has the potential to teach you perseverance, work ethic, and a new perspective
to think through. Very cool thing to think on generally though

------
SNosTrAnDbLe
What about code reengineering and working with legacy code. It is not just
maintaining old code but also knowing how to add and remove components well,
without breaking downstream and/or upstream systems. And if you do have to
break it, managing expectations and communicating those ahead of time.

------
fendy3002
Expiring skills happen many times on front end web. JQuery, then knockout /
backbone, then angularjs, then the current angular / react / vue / svelte
things.

In back end side it happens less frequently.

~~~
neogodless
I'm a small town guy who mostly works on small (town) teams, so I've often
done database, application, and client.

The very edges are mostly static albeit evolving... HTML has been improved,
CSS much more capable, and JavaScript has grown (and been repackaged) but
client development on the very edge isn't too different.

The database and the bones of SQL have not changed drastically (though you can
choose NoSQL and use JSON, which is very different!)

But to your point, the application layer actually has changed a lot. I started
out writing ColdFusion applications, then classic ASP, then .NET 1.1/2.0
through 4.8 and a pinch of .NET Core 2.0+. But also NodeJS and Python and
dozens and dozens I haven't touched.

However, the software development skills that are (semi-)permanent apply,
while the particular expiring flavors change with the seasons.

In some ways, JavaScript has been the most constant through my career, though
how I've used it has been all over the map, from little scripts in a HEAD tag,
to jQuery applications, to NodeJS server applications, to TypeScript client
applications.

~~~
fendy3002
Oh you're right. I forgot about asp classic and unsupported languages. My
professional experience begins with .net 3.5, java and php 5.6, so not much
changes for me.

------
woah
I think this is another one of those substance-free articles written by GPT-3
to prank us

------
hexman
Sprinter vs. Marathoner Skills

------
fogetti
Anyone who writes a blog and happily announces to the world that he thinks
there are idiots everywhere should not give advice in the first place IMHO.

This is what I would call pretentious signaling behavior if there would be
such a term.

