Expiring vs. permanent skills(collaborativefund.com)
collaborativefund.com
Expiring vs. permanent skills
https://www.collaborativefund.com/blog/expiring-vs-permanent-skills
108 comments
> 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.
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.
And if you aren't convinced, SQLite (and postgres) implemented MongoDB as a feature ;-)
Which should be used very sparingly, unlike the actual MongoDB, which shouldn't be used at all.
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.
The worst imaginable outcome for a database.
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.
But it was replaced with a much better engine (WiredTiger) with write-ahead journaling and checkpoints around the year 2016.
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/
"MongoDB 4.2.6" http://jepsen.io/analyses/mongodb-4.2.6
"Jepsen Disputes MongoDB’s Data Consistency Claims" https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/
"MongoDB 4.2.6" http://jepsen.io/analyses/mongodb-4.2.6
I've worked at MongoDB for seven years right next to our EMEA/APAC support teams. We've never come across and instance where MongoDB was "mysteriously annihilating all the data". We would take any incidence of that whether it was a paying customer or not very seriously. If you know someone this has happened to I would encourage you to get them contact us.
Joe Drumgoole Director of Developer Relations, MongoDB
Joe Drumgoole Director of Developer Relations, MongoDB
Oh yeah, I have two of those myself.
jeebus
haha.
I use it for application plugin configuration values which allows plugins to do whatever they want but also provides some structure just in case sweeping changes need to be made.
Basically where schemas aren't important or will be defined by someone else.
I use it for application plugin configuration values which allows plugins to do whatever they want but also provides some structure just in case sweeping changes need to be made.
Basically where schemas aren't important or will be defined by someone else.
Agree 100%. I wrote a whole post about that. https://letterstoanewdeveloper.com/2019/11/11/learn-sql/
In a more general sense, you have to be able to peel back abstractions. Those can include data storage abstractions, network abstractions (no, a network call isn't free, even in the same AWS AZ), and deployment abstractions like Docker.
In a more general sense, you have to be able to peel back abstractions. Those can include data storage abstractions, network abstractions (no, a network call isn't free, even in the same AWS AZ), and deployment abstractions like Docker.
> 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.
I think this also goes toward the point of why they all do this... that SQL isn't what most developers like or want. SQL is an complex data manipulation DSL that most of the time is complete overkill for what you need and using something simpler and more specifically oriented toward your requirements makes more sense. Personally I was pretty good with SQL 15 years back but have moved on and don't regret not having needed it as the various non-RDBMS systems have more that met all my needs.
I think this also goes toward the point of why they all do this... that SQL isn't what most developers like or want. SQL is an complex data manipulation DSL that most of the time is complete overkill for what you need and using something simpler and more specifically oriented toward your requirements makes more sense. Personally I was pretty good with SQL 15 years back but have moved on and don't regret not having needed it as the various non-RDBMS systems have more that met all my needs.
> that SQL isn't what most developers like or want
"Most" developers? That's debatable. But I can tell you a lot of people I talked to who chose MongoDB didn't have a single good reason for choosing it. For some, it's the only DB they are familiar with ("I used it before"). Others had vague, badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB". Seasoned DBAs almost always shook their heads in disapproval (and ended up being proven right).
"Most" developers? That's debatable. But I can tell you a lot of people I talked to who chose MongoDB didn't have a single good reason for choosing it. For some, it's the only DB they are familiar with ("I used it before"). Others had vague, badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB". Seasoned DBAs almost always shook their heads in disapproval (and ended up being proven right).
I'm not 100% on "most"... but really most devs I've met prefer the NoSQL options and the devs who did really like RDBMSs seemed to eventually drift into DBA positions.
I'm not sure why you focused on Mongo... it is probably the poster child for a bad example of NoSQL. It focused on features and performance while leaving data integrity on the floor. Never understood it's success given its Jepsen reviews.
NoSQL excels when it is targeted. Like using Etcd for config management. Consul for discovery. Redis for shared, in-memory data structures. Cassandra for high throughput, write heavy systems. DynamoDB for no-ops, key-value storage. S3 for key-value storage with large storage reqs. Etc.... They don't do as well, like Mongo, when they try to be general purpose. RDBMSs rule the jack-of-all-trade-master-of-none zone.
I'm not sure why you focused on Mongo... it is probably the poster child for a bad example of NoSQL. It focused on features and performance while leaving data integrity on the floor. Never understood it's success given its Jepsen reviews.
NoSQL excels when it is targeted. Like using Etcd for config management. Consul for discovery. Redis for shared, in-memory data structures. Cassandra for high throughput, write heavy systems. DynamoDB for no-ops, key-value storage. S3 for key-value storage with large storage reqs. Etc.... They don't do as well, like Mongo, when they try to be general purpose. RDBMSs rule the jack-of-all-trade-master-of-none zone.
You have a point. I focused on MongoDB because it's indeed used for general purpose, where it doesn't fare very well and often ends up requiring hand-coded solutions to problems RDBMS solve out of the box.
> For some, it's the only DB they are familiar with ("I used it before")
I'm sure some of the reasons you use your RDBMS of choice over another implementation or a NoSQL system distill to, at some point, "I used it before". Familiarity is a feature. This is especially true if your org invests in tooling that improves the usability of a DB.
> badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB"
Why are these badly-argued reasons? I currently work on a codebase that is making heavy use of MongoDB. We are using it as a way to store protobufs which will change very frequently in structure (adding new fields, removing old fields, etc). Our software is built so that it supports older versions of protos which is already needed for backwards-compatibility in APIs. Because we're using Mongo I've written a simple connector that maps our protos into Mongo that allows documents in a collection to map well into proto access semantics (default to emptiness). If a frontend developer wants to save some new field into a database they:
We are also planning on making use of things like `watch()` which is possible to do in some hacky ways in postgres but it's very easy to do with this architecture.
I've never had as smooth an experience with PG/MySQL/SQLite, even with ORMs.
> Seasoned DBAs almost always shook their heads in disapproval
I'm assuming that seasoned typists shook their head when business people started to buy computers to typeset their own documents. I'm sure they were also proven right in the early days as documents were poorly formatted or took long to produce. But, it wasn't that way for long.
Any time you have a field of people that is hyper optimized on maintaining a single workflow/tool/thing it will take a lot of effort to replace. There being a large amount of effort to replace a tool does not mean it shouldn't be replaced.
I'm sure some of the reasons you use your RDBMS of choice over another implementation or a NoSQL system distill to, at some point, "I used it before". Familiarity is a feature. This is especially true if your org invests in tooling that improves the usability of a DB.
> badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB"
Why are these badly-argued reasons? I currently work on a codebase that is making heavy use of MongoDB. We are using it as a way to store protobufs which will change very frequently in structure (adding new fields, removing old fields, etc). Our software is built so that it supports older versions of protos which is already needed for backwards-compatibility in APIs. Because we're using Mongo I've written a simple connector that maps our protos into Mongo that allows documents in a collection to map well into proto access semantics (default to emptiness). If a frontend developer wants to save some new field into a database they:
1. Add the field into the proto
2. Validation field in service (optional)
We are also planning on making use of things like `watch()` which is possible to do in some hacky ways in postgres but it's very easy to do with this architecture.
I've never had as smooth an experience with PG/MySQL/SQLite, even with ORMs.
> Seasoned DBAs almost always shook their heads in disapproval
I'm assuming that seasoned typists shook their head when business people started to buy computers to typeset their own documents. I'm sure they were also proven right in the early days as documents were poorly formatted or took long to produce. But, it wasn't that way for long.
Any time you have a field of people that is hyper optimized on maintaining a single workflow/tool/thing it will take a lot of effort to replace. There being a large amount of effort to replace a tool does not mean it shouldn't be replaced.
I totally agree that the most unpopular, foundational stuff is essential.
I do think there are some timeless bits of technical knowledge, that will serve you no matter what high-level tech (the ones you mention, and other) is fashionable.
In roughly descending order of importance, I'd put forward: the shell (bash, zsh, ...), gnu coreutils, modal text editors (ed, vi, vim, emacs), fundamentals of linux sysadmin, git, the networking stack up to HTTP (starting at least from IP).
these are all good examples of tools that have aged very well, provide a disproportionate amount of power relative to their learning curves, and have a very good shot at being timeless.
They all also have the dual-benefit of not traditionally being taught in schools. I guess it's assumed you can pick it up along the way, which is true, but these are all complicated enough by now that they merit detailed study from time to time. In any case, because most people in the industry come from universities, they don't natively have these skills, and they can be an edge for you.
I do think there are some timeless bits of technical knowledge, that will serve you no matter what high-level tech (the ones you mention, and other) is fashionable.
In roughly descending order of importance, I'd put forward: the shell (bash, zsh, ...), gnu coreutils, modal text editors (ed, vi, vim, emacs), fundamentals of linux sysadmin, git, the networking stack up to HTTP (starting at least from IP).
these are all good examples of tools that have aged very well, provide a disproportionate amount of power relative to their learning curves, and have a very good shot at being timeless.
They all also have the dual-benefit of not traditionally being taught in schools. I guess it's assumed you can pick it up along the way, which is true, but these are all complicated enough by now that they merit detailed study from time to time. In any case, because most people in the industry come from universities, they don't natively have these skills, and they can be an edge for you.
When I interview people I focus on those things you mentioned and so don’t bother trying to quiz them on anything domain specific to their past experience or our future expectations for them.
I will upvote this, but it can unfortunately be seen as discriminatory towards the poor folk who have built their careers maintaining windows servers. :)
although, like oil and water, it's probably unlikely they'd apply for a position at a *nix-based shop.
although, like oil and water, it's probably unlikely they'd apply for a position at a *nix-based shop.
Chorus: "You grill them on irrelevant details?!?"
A friend and I were joking today that we could probably create a career out of helping people/companies fix their git issues. I've been to several employers now where most of the developers have an anxiety attack when they get merge conflicts. Being good at this is really great, though I'm not sure how to capture that on a resume, because basically everyone lists git these days.
heh I've noticed this, too. There are a group of us at work that are known as "git surgeons", maybe that's the modifying noun you're looking for!
In general, claiming status as a <technology> <noun> will get you positive attention, as long as it doesn't come off too arrogant (e.g. expert, master, w/e)
e.g. git guru, nix nerd.
It reminds me of this excellent article [0] that I like to share with all the engineers I work with, every year or so. In that case, you'd be a "taco bell programmer".
But it's maybe too self-effacing depending on your opinion of taco bell :)
[0]: http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...
In general, claiming status as a <technology> <noun> will get you positive attention, as long as it doesn't come off too arrogant (e.g. expert, master, w/e)
e.g. git guru, nix nerd.
It reminds me of this excellent article [0] that I like to share with all the engineers I work with, every year or so. In that case, you'd be a "taco bell programmer".
But it's maybe too self-effacing depending on your opinion of taco bell :)
[0]: http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...
> because basically everyone lists git these days
True! And apparently you cannot skip listing it. I recently changed jobs and was told one red flag in my CV was that I didn't list git as a tool I was familiar with. This wasn't a recruiter on a buzzword hunt, but the actual technical screener. I had explicitly removed all filler because I thought interviewers wanted to focus on the important bits... (got the job anyway, thankfully).
True! And apparently you cannot skip listing it. I recently changed jobs and was told one red flag in my CV was that I didn't list git as a tool I was familiar with. This wasn't a recruiter on a buzzword hunt, but the actual technical screener. I had explicitly removed all filler because I thought interviewers wanted to focus on the important bits... (got the job anyway, thankfully).
Yeah, I was going to say the same thing. They are all soft skills. I'll add a few hard skills for STEM jobs that are not necessarily specific to any field:
- Number sense. The ability to notice inconsistencies from hundreds of rows and columns of a spreadsheet, for instance, is critical to both projects and career. Being able to carry out back-of-envelop calculation is a crucial skill too.
- Statistical sense. I'd even venture to say it's a survival skill. Too many people make statements that this: I saw a pattern of cloud every time when an earthquake happens, therefore, if I see the pattern, I can predict that there is going to be an earthquake. Or how many people are fooled by Simpson's paradox in their daily jobs?
- Mathematical maturity. How many engineers missed the gravy train of the machine learning because they couldn't or were afraid to understand basic college maths, like linear algebra, vector calculus, or mathematical statistics?
- Mathematical modeling. We don't really need to find out the boundary condition of a system of PDEs, but the ability to model a system mathematically is of huge value.
- Intuition of your field. For backend engineers, for instance, the understanding of the basic theory of distributed systems, the understanding of performance modeling with queuing theory, the understanding of common data structures and algorithms in OS/databases, the understanding of concurrent and parallel programming, and the ability to code up anything reasonably prescribed, of course.
- Number sense. The ability to notice inconsistencies from hundreds of rows and columns of a spreadsheet, for instance, is critical to both projects and career. Being able to carry out back-of-envelop calculation is a crucial skill too.
- Statistical sense. I'd even venture to say it's a survival skill. Too many people make statements that this: I saw a pattern of cloud every time when an earthquake happens, therefore, if I see the pattern, I can predict that there is going to be an earthquake. Or how many people are fooled by Simpson's paradox in their daily jobs?
- Mathematical maturity. How many engineers missed the gravy train of the machine learning because they couldn't or were afraid to understand basic college maths, like linear algebra, vector calculus, or mathematical statistics?
- Mathematical modeling. We don't really need to find out the boundary condition of a system of PDEs, but the ability to model a system mathematically is of huge value.
- Intuition of your field. For backend engineers, for instance, the understanding of the basic theory of distributed systems, the understanding of performance modeling with queuing theory, the understanding of common data structures and algorithms in OS/databases, the understanding of concurrent and parallel programming, and the ability to code up anything reasonably prescribed, of course.
Came here to say this (mostly).
You mentioned a bunch of computer science stuff. There's a lot in pure software development/engineering that's rather permanent, as well. Was working on a project 7-8 months ago where we had a node codebase and a C++ one, and needed to share behavior. Rather than write it twice, I figured there had to be a way to share code directly, because I knew many node extensions have bits written in C. And of course there was -- but it required knowing about things like ABIs, reactors and event loops, linking and compiler internals, etc.
There's all kinds of timeless hard skills in software dev. Knowing how to modularize things properly, how to create the right abstractions, how to name things well, how threading really works.
You mentioned a bunch of computer science stuff. There's a lot in pure software development/engineering that's rather permanent, as well. Was working on a project 7-8 months ago where we had a node codebase and a C++ one, and needed to share behavior. Rather than write it twice, I figured there had to be a way to share code directly, because I knew many node extensions have bits written in C. And of course there was -- but it required knowing about things like ABIs, reactors and event loops, linking and compiler internals, etc.
There's all kinds of timeless hard skills in software dev. Knowing how to modularize things properly, how to create the right abstractions, how to name things well, how threading really works.
[deleted]
Within the field of software development (as contrasted with computer science), there are also skills which persist beyond fads:
• unit testing
* source control
* documentation
* FOSS contribution mechanisms and licensing
* security concepts like defense in depth, threat modeling
Even if you learn such skills in conjunction with a specific technology, they won't expire. For instance, once you get accustomed to writing unit tests under one framework, you can easily switch to another — the hard parts are understanding how to get a good ROI on the time you spend writing tests, how to write robust tests, how to write testable code, and so on.
• unit testing
* source control
* documentation
* FOSS contribution mechanisms and licensing
* security concepts like defense in depth, threat modeling
Even if you learn such skills in conjunction with a specific technology, they won't expire. For instance, once you get accustomed to writing unit tests under one framework, you can easily switch to another — the hard parts are understanding how to get a good ROI on the time you spend writing tests, how to write robust tests, how to write testable code, and so on.
To add to your list:
* debugging
* profiling
* logging
* debugging
* profiling
* logging
Wait, MongoDB is still hot? I thought it was debunked years ago and was essentially a laughingstock.
MongoDB (NASDAQ: MDB) is >$10b market cap today.
Anecdotally, I've worked at multiple places that (For Reasons™) launched on Mongo, built a relational schema on top, and still exist today.
Anecdotally, I've worked at multiple places that (For Reasons™) launched on Mongo, built a relational schema on top, and still exist today.
Your anecdote rings true according to my experience. Did people in many of them end up complaining a lot about Mongo too, but "hey, it is what it is, and it's what we use now"?
A consequence of this is later, junior devs have their experience shaped by this kind of places, and end up choosing Mongo for their next piece of software, perpetuating the cycle of... life?
A consequence of this is later, junior devs have their experience shaped by this kind of places, and end up choosing Mongo for their next piece of software, perpetuating the cycle of... life?
It's still hot and used in successful businesses, regardless of its technical merits and pitfalls. It's pretty trendy, too.
HN is a strange echo chamber. The same place where more than one person told me "Java is not good for general purpose development". Oh, well.
HN is a strange echo chamber. The same place where more than one person told me "Java is not good for general purpose development". Oh, well.
That's the HackerNews echo chamber of received opinions in action.
That's why whiteboard interviews are sticking around; Someone who knows the fundamentals can constantly grok new frameworks or tech. Even if a new hire has never used Git, if he has ever studied graphs it will be obvious to him. The opposite isn't always true.
White boarding ability is really trending down lately.
Being able to perform a skill in an abstract matter verbally is the opposite of what the job entails usually so it makes a poor proxy.
Agree with you that fundamental skills are key. I don't think we have figured out how to measure them.
Being able to perform a skill in an abstract matter verbally is the opposite of what the job entails usually so it makes a poor proxy.
Agree with you that fundamental skills are key. I don't think we have figured out how to measure them.
> Meanwhile, what I learned in university is all the unpopular stuff...
The stuff you listed is specifically what interest me. Most languages are quite comparable anyways, just different syntax but not fundamentally different.
The stuff you listed is specifically what interest me. Most languages are quite comparable anyways, just different syntax but not fundamentally different.
I've thought about this too as a student and in relation to professional skills.
I call the concept "Engines vs Powerups", due to having played a number of racing games as a child where you can spend prize money from races on improvements to your car or other items between levels.
It's a spectrum, too! Computer languages fall in the middle. Knowing PHP is a lot more durable than knowing Drupal, but PHP probably won't stay relevant as long as Spanish will.
One thing I'd share, is that I've gotten a lot of mileage out of skills that were once hot and are now useless. In fact, part of how I got my first well-paid software job at Groupon was because I was comfortable with Backbone.js and CoffeeScript! Neither are used much at all anymore, but I learned a lot of other things at Groupon that have helped me since and they opened the door.
https://alchemist.camp/learning-machine/engines-powerups
I call the concept "Engines vs Powerups", due to having played a number of racing games as a child where you can spend prize money from races on improvements to your car or other items between levels.
It's a spectrum, too! Computer languages fall in the middle. Knowing PHP is a lot more durable than knowing Drupal, but PHP probably won't stay relevant as long as Spanish will.
One thing I'd share, is that I've gotten a lot of mileage out of skills that were once hot and are now useless. In fact, part of how I got my first well-paid software job at Groupon was because I was comfortable with Backbone.js and CoffeeScript! Neither are used much at all anymore, but I learned a lot of other things at Groupon that have helped me since and they opened the door.
https://alchemist.camp/learning-machine/engines-powerups
It's always worth knowing and working on the basics!
Also, with the "what's hot" frameworks, just because something's no longer flavour of the month doesn't mean it stops working. It's perfectly OK to build something using whatever last-month's tech you're conversant in and if it does the job, what more do you need?
Also, with the "what's hot" frameworks, just because something's no longer flavour of the month doesn't mean it stops working. It's perfectly OK to build something using whatever last-month's tech you're conversant in and if it does the job, what more do you need?
Aren't bootcamps aimed at people with little to no development experience? Your first dive into a full web stack - regardless of which stack that is - will give you all sorts of skills that never expire. I consider it like a CS101 but for the web - would you say that CS101 teaches you stuff that expires?
Yes and no. My CS101, CS304P, was taught in Pascal and just involved general, basic programming. It didn't so much expire as was largely irrelevant, except as a foundation for the next round of things: algorithms, data structures, formal math, assembly, machine architecture, and so on; these were then foundations for the rest of the education. Bootcamps are like taking CS101, then saying, "We're done. You can go get a job and pick up the rest as you go along." (Which is of course possible, but only for those who are very dedicated.)
[deleted]
Would you mind explaining how learning proofs has helped you? I'm currently studying computer science on my own, so I would appreciate any tips.
The ability to read and write proofs lets me confirm truth independently, without needing to blindly trust someone's claims. As a quick analogy, if you know how to do arithmetic by hand, you can check whether an electronic calculator is faulty.
In my opinion, here are the most important mathematical topics in computer science which are related to proofs: Basic algebra, inequalities, functions, set theory, Boolean algebra, predicates, quantification (for-all & there-exists), weak&strong&structural induction, formal definition of big-O notation, preconditions & postconditions, loop invariants, termination, recursion, regular languages, Turing machines, computability.
Example: If you don't know the true definition of big-O, you can still identify common patterns by counting the number of nested loops. But there are non-standard cases (e.g. Euclid's GCD algorithm) and contrived pathological cases where you must appeal to the formal definition in order to prove anything.
Example: Somebody hands you a red-black tree data structure plus algorithms, in either pseudocode or real code. How can you justify that their work is correct and won't corrupt data? You need to do proof by cases, structural induction, and big-O analysis.
Example: You design a new algorithm for analyzing graphs which doesn't resemble anything in published literature. You can't just reuse other people's analyses, so you have to write your own.
Without understanding how to do proofs, you're doomed to either cobbling together high-level libraries or creating things with subtle flaws. You'd be unable to synthesize new knowledge or fill in small gaps, due to not grasping the underlying theory.
In my opinion, here are the most important mathematical topics in computer science which are related to proofs: Basic algebra, inequalities, functions, set theory, Boolean algebra, predicates, quantification (for-all & there-exists), weak&strong&structural induction, formal definition of big-O notation, preconditions & postconditions, loop invariants, termination, recursion, regular languages, Turing machines, computability.
Example: If you don't know the true definition of big-O, you can still identify common patterns by counting the number of nested loops. But there are non-standard cases (e.g. Euclid's GCD algorithm) and contrived pathological cases where you must appeal to the formal definition in order to prove anything.
Example: Somebody hands you a red-black tree data structure plus algorithms, in either pseudocode or real code. How can you justify that their work is correct and won't corrupt data? You need to do proof by cases, structural induction, and big-O analysis.
Example: You design a new algorithm for analyzing graphs which doesn't resemble anything in published literature. You can't just reuse other people's analyses, so you have to write your own.
Without understanding how to do proofs, you're doomed to either cobbling together high-level libraries or creating things with subtle flaws. You'd be unable to synthesize new knowledge or fill in small gaps, due to not grasping the underlying theory.
Thank you for writing this. To be blunt I don't understand about half of the terms you used, but I eventually will. Have you ever read Euclid's Elements? I recently took one of the few classes left in the country that uses Euclid, and I've been thinking about what a computer science student could glean from it in 2020.
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.
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.
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.
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.
If you look at all the people who achieved military success the great majority of them had the right skills at the right time. Grant and Sherman were field generals who understood how to adapt the new tactics and technology. Eisenhower and Zhukov were staff officers who knew how to juggle the interests of many competing stakeholders. Eisenhower in particular was very light on "expiring skills"
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
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
Was this meant to be on https://news.ycombinator.com/item?id=24141628 ?
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.
Lambda and serverless is pretty much built on containers - only Cloudflare Workers isn't.
I think AWS lambdas and Fargate are using firecracker[1].
[1] https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
[1] https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
Feel the same. I don't want to waste my time learning intricate details about cloud providers.
I agree, this is why I choose to focus on portable and provider agnostic solutions.
Recently i learnt that each and every lambda event source has completely different model / structure. Which is hilarious and shows that internally AWS has huge issues to maintain standards.
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.
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.
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.)
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.)
This is the best answer.
See, the lesson I took away from drawing-for-cartography-for-military-commanders wasn't what the article hoped for.
What that made me think is: Skills that, in the present seem like millennia-old permanent skills might in the future turn out to be expiring.
Sure, everyone knows javascript-framework-du-jour is an expiring skill.
But is handwriting? Mental arithmetic? Cooking? Differentiation?
What that made me think is: Skills that, in the present seem like millennia-old permanent skills might in the future turn out to be expiring.
Sure, everyone knows javascript-framework-du-jour is an expiring skill.
But is handwriting? Mental arithmetic? Cooking? Differentiation?
Well, go back even just 30 years (though increasingly less common by then) and you had several generations of slide rule users in the engineering and science fields. People knew how to use logarithm tables (even I was taught them in the mid-90s in high school, but outside a single no-calculator math course, I never used them after).
I think some of the math topics (mental arithmetic) will remain valuable, but as you press into different intermediate and higher skill levels you'll see some things disappearing (like the aforementioned slide rules). The act of differentiating will remain useful, but more useful is understanding how to establish the model for your system which includes differentiation and integration. So we may see a decline in the mechanical skill, but an increase in understanding/applying it.
I mean, look at a lot of contemporary machine learning approaches. Most of the practitioners probably don't understand a lot of the mechanics of the math inside the models, but do understand the applications. That's not bad, it's just different. A few people need to master the internals to make progress on them or implement them, but most can get by and make useful (hopefully) applications without that level of understanding.
I think some of the math topics (mental arithmetic) will remain valuable, but as you press into different intermediate and higher skill levels you'll see some things disappearing (like the aforementioned slide rules). The act of differentiating will remain useful, but more useful is understanding how to establish the model for your system which includes differentiation and integration. So we may see a decline in the mechanical skill, but an increase in understanding/applying it.
I mean, look at a lot of contemporary machine learning approaches. Most of the practitioners probably don't understand a lot of the mechanics of the math inside the models, but do understand the applications. That's not bad, it's just different. A few people need to master the internals to make progress on them or implement them, but most can get by and make useful (hopefully) applications without that level of understanding.
I actually consider my Emacs skills permanent. I have made small adjustments over the year, mostly removing stuff from my configuration as the defaults improved. The basic stuff I decided to go through in my youth is the same.
I try to improve my understanding of my surroundings, and I consider that a sort of permanent albeit developing skill too. Biological systems, political systems, social systems, individual human beings (I'm curious, I want to understand people I know).
I try to improve my understanding of my surroundings, and I consider that a sort of permanent albeit developing skill too. Biological systems, political systems, social systems, individual human beings (I'm curious, I want to understand people I know).
I can forget about books with no problem. Sometimes after being 3/4 through a story a small feeling sets in that you somehow know the content and then you read something that makes it clear you already read it. It isn't even a sign of quality, happens with interesting and boring books. Perhaps it is different with nonfiction but I doubt it. Certainly didn't work with my french textbook.
What I think you cannot unlearn is some motor skills like cycling or skiing. Learned skiing at the age of 4-6 and then never came to it for nearly 15 years. Was afraid I would have to relearn everything but it was absolutely no problem as if I never did anything else the last decade. Maybe age of learning is a huge factor here.
What I think you cannot unlearn is some motor skills like cycling or skiing. Learned skiing at the age of 4-6 and then never came to it for nearly 15 years. Was afraid I would have to relearn everything but it was absolutely no problem as if I never did anything else the last decade. Maybe age of learning is a huge factor here.
I unlearned skiing. It had been about 18 years since I last skied, but I have been an avid snowboarder during the intermediate. I simply did not have the muscle memory needed to manipulate the skis, I knew what I wanted to do in my mind, but could not figure how to tell my body how to do it.
Some permanent skills in my trade:
Programming -- in general, not just language specific. Many people simply can't do it, and I don't see it going away in my lifetime.
Quantitative problem solving.
Scientific reasoning.
The laws of physics won't change any time soon, being able to interpret them is a skill.
Being able to see my way through fabrication of a complex prototype using the materials and techniques that are available and practical for the job at any given moment.
Being able to entertain people creatively.
Programming -- in general, not just language specific. Many people simply can't do it, and I don't see it going away in my lifetime.
Quantitative problem solving.
Scientific reasoning.
The laws of physics won't change any time soon, being able to interpret them is a skill.
Being able to see my way through fabrication of a complex prototype using the materials and techniques that are available and practical for the job at any given moment.
Being able to entertain people creatively.
I actually think that being able to learn an expiring things deeply enough that you start to see the permeant skills underneath is really important.
Being able to look at something and quickly separate the core important concepts that are being used from the syntax and implementation details seems super important for long term success in a field.
Being able to look at something and quickly separate the core important concepts that are being used from the syntax and implementation details seems super important for long term success in a field.
> 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.
Depends on the software. In modern IT-oriented software, or webdev which is basically the same thing, where we have made a sport of rewriting things for the sake of rewriting them, yeah that's totally true.
But Someone with 1990s Excel wizardry will still be an Excel wizard today. I'm sure the same is true of a lot of professional software out there where "professional" != "IT".
Depends on the software. In modern IT-oriented software, or webdev which is basically the same thing, where we have made a sport of rewriting things for the sake of rewriting them, yeah that's totally true.
But Someone with 1990s Excel wizardry will still be an Excel wizard today. I'm sure the same is true of a lot of professional software out there where "professional" != "IT".
Just wait until it's decades. I look at some of the Windows C++ code I wrote in the 90's and it's unrecognizable. Until I look at the sarcastic comments and think "yep, that's me".
Learning a particular trade might expire, but learning how to learn will never be futile.
Coincidentally, that's also one of the course I'm taking on Coursera.
Coincidentally, that's also one of the course I'm taking on Coursera.
Every field has "the fundamentals," and mastery of the fundamentals is what separates the exceptional from the merely good.
John Nash's "Non-Cooperative Games" has a grand total of 5 references in its bibliography. A modern PhD thesis will have hundreds.
John Nash's "Non-Cooperative Games" has a grand total of 5 references in its bibliography. A modern PhD thesis will have hundreds.
[deleted]
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.
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.
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.
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.
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.
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.
Exactly, I've felt sometimes when presenting a counter intuitive conclusion that starting with a result that violates initial impressions ends up requiring /more/ supporting evidence than starting with several less controversial facts that when combined result in a controversial fact, like that mercury is the closest planet to the earth (for certain definitions of closest)
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.
This isn’t unique to business...academic papers have abstracts that do this; math proofs have the statement they’re proving up-front.
Really this is just the scientific method.
"often using the same time or more" means often saving time when the whole shpiel isn't needed, which is the point.
Time management ia important when your time is highly valuable with opportunity cost.
Time management ia important when your time is highly valuable with opportunity cost.
I stand by my post. Been doing this for 40 years.
> There’s a big time savings in giving the conclusion first, then backing through only the needed part of the explanation.
"Results may wary"
This is one of those things I've discovered has no right answer. Some people will appreciate you getting to the point first, and others will hate it. Sometimes it will save time, other times it makes things more protracted.
And some people are prone to dismiss the conclusion without hearing the rationale. Definitely don't start with the conclusion when discussing with them.
Whether the conversation is live vs asynchronous also makes a significant difference in this.
"Results may wary"
This is one of those things I've discovered has no right answer. Some people will appreciate you getting to the point first, and others will hate it. Sometimes it will save time, other times it makes things more protracted.
And some people are prone to dismiss the conclusion without hearing the rationale. Definitely don't start with the conclusion when discussing with them.
Whether the conversation is live vs asynchronous also makes a significant difference in this.
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".
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.
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.
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.
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
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
After graduating and spending some years in the real world, I am quite astonished that this is more often than not a rule in the academia. Going through courses deeply rooted in computer science without learning clean coding skills and interpretation of computer programs (clean code and SICP) is crazy.
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).
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).
Can you concretely explain how these domains share the same skills?
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.
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.
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.
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.
[deleted]
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".
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".
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.
I see that especially in the world of relational databases.
We used to call these 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... , 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.
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... , 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.
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.
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.
> 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".
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".
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.
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.
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
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.
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.
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!
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
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.
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.
In back end side it happens less frequently.
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.
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.
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.
I think this is another one of those substance-free articles written by GPT-3 to prank us
Sprinter vs. Marathoner Skills
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.
This is what I would call pretentious signaling behavior if there would be such a term.
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.