Expiring vs. permanent skills
collaborativefund.com
collaborativefund.com
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.
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.
although, like oil and water, it's probably unlikely they'd apply for a position at a *nix-based shop.
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...
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).
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.
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?
• 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.
* debugging
* profiling
* logging
The stuff you listed is specifically what interest me. Most languages are quite comparable anyways, just different syntax but not fundamentally different.
Anecdotally, I've worked at multiple places that (For Reasons™) launched on Mongo, built a relational schema on top, and still exist today.
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?
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.
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.
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.
The worst imaginable outcome for a database.
But it was replaced with a much better engine (WiredTiger) with write-ahead journaling and checkpoints around the year 2016.
"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
Joe Drumgoole Director of Developer Relations, MongoDB
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.
"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 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'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.
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.
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.
- 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.
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.
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.
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.
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.
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
[1] https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
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.
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.
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.)
Coincidentally, that's also one of the course I'm taking on Coursera.
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).
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?
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.
John Nash's "Non-Cooperative Games" has a grand total of 5 references in its bibliography. A modern PhD thesis will have hundreds.
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.
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".
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.
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.
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.
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.
Time management ia important when your time is highly valuable with opportunity cost.
This isn’t unique to business...academic papers have abstracts that do this; math proofs have the statement they’re proving up-front.
"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.
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.
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).
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.
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.
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".
I see that especially in the world of relational databases.
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.
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.
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".
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.
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.
In back end side it happens less frequently.
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.
This is what I would call pretentious signaling behavior if there would be such a term.