> A skill could be highly paid, but only useful in a narrow range of jobs, giving you few options if you change your mind about what to do.
Makes sense. If you focus on coding there isn't much it applies to (in terms of employment) other than coding for a living or working near coding-related things (CTO, manager, etc.) That being said, accounting also only really applies to a handful of jobs and nobody has ever said being an accountant is risky.
Unrelated, but jbreckmckye your email is in the URL.
Good catch, re: email in the URL. I'm likely to the blame the sender of the email for including PII in the Google Analytics UTM parameters, which is is a clear violation of GA's terms and best practices [1]. If it's 80000hours.org that sent the email and created the tracking params, then the OP should contact them and hope that they remediate this.
>According to this analysis, the most valuable skills could be summed up as “leadership” skills
>What are the most valuable combinations of job skills?
>David Deming found that the jobs with the greatest growth in employment were those that required both social and mathematical skills.
I think these are the key takeaways. STEM is very important, but it appears the market is saying we have a lack of leadership skills, which are not really emphasized in a typical education.
"Coding" is mechanical. "Judgement and decision making", "Critical thinking", "Complex problem solving", the actually difficult parts of doing long-term programming work, are at the top of the list.
I could not agree more. Programming isn't an employable d skill by itself. What you're actually doing for the business is problem solving, and in order to be good at that, you need to have people skills to a certain degree.
You listen to the managers, or are otherwise invested in the inner workings of the company. Using those skills of intuition, you gather the business objectives, and then write code to solve those needs in the manner most appropriate to the environment in which you work. Of course, often you're writing more than just code, and will contribute to documentation, and test with your users to gather feedback and improve your solution.
Good programmers spend less of their time writing actual code, and much more of their time understanding the problems their code is meant to solve.
Ultimately that's a job for the designers though. The coders job should be to just implement what they're told in a robust performant, but also pragmatic way.
Coding is not mechanical. Or to say, what do you mean by coding? The ability to write programs that successfully solve problems good judgement and decision making, critical thinking, complex problem solving...it sounds like coding is just a meaningless term without the others.
Coding, that is implementing something, is about as mechanical as it gets. What you describe as requiring judgement and decision making is engineering. It's not often part of software development these days, as companies focus almost exclusively on the mechanics of data structures and algorithms.
What do you mean by "implementing something?" Like, implement an algorithm whose logic is already known? Isn't that just translation? And anyways, how often does any programmer even do that?
I've received requirements that were just a decision tree for a certain process, and had to implement that in the context of an existing system. Thankfully, I don't do that kind of mind-numbing crap any more.
Ok, but we decide to call that coding/programming? It really puts the art in a bad light, like claiming carpentry was about sawing in straight lines or following IKEA assembly instructions.
A coder builds a solution to a problem. An engineer builds the right solution to a problem. Doing that requires as many soft skills as technical skills.
No. There are often multiple solutions to a problem. Finding one that works is easier than choosing the best among many that work.
You really didn't like the suggestion that the two words aren't synonyms. Sorry about that. I used to have a hard time understanding the difference between the terms "tactic" and "strategy" because there were so many examples where they seemed interchangeable, and perhaps you're feeling the same sort of hair-splitting is happening here.
Here's another way of looking at it. Coding is writing new code or improving existing code (maybe even improving it by removing it). Engineering might, for example, be a decision that it's more cost-effective to buy more hardware and spin up a second instance than to refactor code to enable the safe addition of a cache.
If it continues to frustrate you that different words are used to describe different responsibilities, you're free to call them both the same thing. My personal experience in the industry is that one is a superset of the other.
Coding is translating (encoding) an existing design into an arcane language at a high level of detail. A coder produces source code from a specification in the way that a secretary produces a typed document from a dictaphone tape. Like a secretary, a coder may be expected to have the domain knowledge and judgement to interpolate small details, but should not generally be making decisions.
Understanding business needs and gathering requirements is software analysis. Deciding what components to write to fulfill those requirements is system architecture. Determining the modules, algorithms, and data structures to use within those components is software design. Finally, writing down those algorithms and data structures in a way that satisfies the compiler is coding.
Most of us "software engineers," "software developers," or simply "programmers" wear all of these hats at various points in a project's lifecycle. But to wear the title "coder" is to explicitly mark your position as one with minimal critical thinking, problem solving, or decision-making.
Coding is nowhere near sufficient to create programs that solve complex problems, in the same way that typing is not sufficient to create a novel. If people explicitly designated as coders are making decisions and thinking critically, we should be as concerned as if typesetters were reworking character development.
I guess this definition of coding harkens back to the days when secretaries* would encode programs written by mathematicians by punching cards or weaving knots or configuring wires?
Because that hasn't existed in a long time, at least since the 70s. Much like typesetter don't exist anymore where designers use programs that allow the, to typeset themselves.
* many of these "coders" like future rear admiral Grace Hopper got fed up with this and did something about it, leading to the first compilers and programming languages.
Coding is one activity within the software development process, and I agree, I don't think those activities have been separated by job title in a long time. Most people do some of everything.
Which is why it's so strange that people would suddenly rally around this term, rather than "programmer" or "developer" or "software engineer" which encompass the full range of what they're doing, and instead choose to cheapen it by calling out the least intellectually challenging step.
You could argue that source code in a contemporary high-level language is a software design, and compilers/interpreters have grown sophisticated enough to eliminate the need for human grunt work.
System software that manages semantics of machine, user, job and developers resources confuses many younger developers. They imagine "coding about computing" is just knowing how to code in C. That is obviously completely false in all manners to real engineers addressing real use cases but a very common mistake. Now older I have known many engineers spun out constantly playing with new tools. Real system software projects have longer historical narratives involving human use cases and stakeholders anyone can read.
Most of these skills seem pretty vague. How would you quantify "Judgment and Decision Making" in a generic sense? Seems a bit too context dependant to make that generalisation.
Reaching a basic level of success in employment is way more holistic than these bar charts would indicate.
Statements like this are just silly:
> "A skill like “judgement” could make you highly employable, but be hard to improve, and so offer poor returns per hour spent learning."
How about this for a pretty generic plan:
- Know your trade: Understand whatever system you are using in depth.
- Understand how you create value within the specific business you are in.
- Have an O.K understanding of how your work interacts with others, and be O.K at explaining your understanding to others.
- Try to consistently interact with others in good faith and try to score runs for your project/business/whatever. Subjugate your own ego as much as possible and remain friendly when things get hectic.
I may severely dislike certain people but acknowledge their undeniable good judgment. Being reasonably honest, I'll tell as much if asked for a reference.
Anything that involves a word like "good" instead of something numeric is hard to objectively measure. But if your aim is not science but hiring, you learn to trust your gut and other unscientific instruments. (Human vision is very much flawed as a scientific instrument, but it helps do complex things nonetheless. Same with human judgment.)
>Most of these skills seem pretty vague. How would you quantify "Judgment and Decision Making" in a generic sense? Seems a bit too context dependant to make that generalisation.
You don't need to "quantify" it. You just need to be able to exercise it. It's one of the things that people you know when you see it (especially in hindsight) whatever the domain (so the fact that it's context dependent doesn't matter either).
I'll buy that. I am expecting a lot from a random/free study on the Internet!
But I think part of my gripe stands: the study is treating all these skills as independent when they actually seem pretty interrelated. There are also important confounding factors like industry which aren't given a mention.
For example 'judgement and decision making' in any professional field has to be built on a foundation of technical knowledge. And that judgement and decision making is probably not really transferable to other professional fields.
>For example 'judgement and decision making' in any professional field has to be built on a foundation of technical knowledge. And that judgement and decision making is probably not really transferable to other professional fields.
Is it though? Because we have the case of CEOs and upper management doing fine in widely differing companies and industries.
It's more about knowing who to trust and what the signs tell you, than about having any low- or even mid-level technical knowledge.
Taleb has this story: "“In one of the rare non charlatanic books in finance, descriptively called What I Learned Losing A Million Dollars, the protagonist makes a big discovery. He remarks that a fellow called Joe Siegel, the most active trader in a commodity called “green lumber” actually thought that it was lumber painted green (rather than freshly cut lumber, called green because it had not been dried). And he made a living, even a fortune trading the stuff! Meanwhile the narrator was into theories of what caused the price of commodities to move and went bust. The fact is that predicting the order flow in lumber and the price dynamics narrative had little to do with these details — not the same thing. Floor traders are selected in the most non-narrative manner, just by evolution in the sense that nice arguments don’t make much difference.”
>As well as looking at income, we rated skills on satisfaction, risk of automation, and breadth of applicability.
Translation: We cooked up data by adding our biases, but since we teamed up with a "data science fellow", thus our findings must scientific!
This is worse than the average feel good pop pscyhology that appears in NYtimes.
Reminds me of this good bit from an EJMR post:
"Any approach that claims to recover the distribution of individual utility parameters from aggregate data based on arbitrary distributional and functional form assumptions is dubious at best,"
Consider: "Reading comprehension": at a moderate level that's basically everyone in the industrialized world. At a high level, what are the jobs where this is going to be the skill that makes a difference, as opposed to prior training and learning ability re: the things you've read?
Consider: "Management of personnel": in a world in which middle management are the first to be laid off, it's hard not to think that the allegedly high incomes are unstable and/or only for the best performers.
Consider: "Service orientation." Uh, like in the service industry? Sure, that's "employable," for a can't-make-rent sense of the term.
Generally, the list seemingly fails to take into account the extent to which a skill is already saturated. It's striking, for example, that the top few are skills characteristically developed in advanced degree training in the humanities, law, etc., who haven't, shall way say, had the best few years in the job market lately, due to rampant overproduction...
High level reading comprehension is certainly beneficial for understanding complex matters and making decisions based on them. Does an average person in industrialized nations have reading skills at the level of a partner at law firms or a successful consultant?
My experience with reading comprehension is that it is moderate across the board in white collar jobs. But general writing ability is horrific. Almost half of the professionals I have worked with seem unable to put coherent thoughts into words.
Mine too---it's striking that writing is so much lower than reading comprehension. (Maybe that makes some sense, if employers care so little about writing that they routinely hire those who can't do it.)
>Consider: "Reading comprehension": at a moderate level that's basically everyone in the industrialized world.
And yet, even HN comments (by native english speakers) illustrate every day that this is not the case. Except if we have a very low bar for that "moderate level".
In any case, when they that you need "those job skills" they don't mean "you need them in the average level that everybody in the industrialized world more or less has them". The mean you if if you're good at them, you have an advantage.
>it's hard not to think that the allegedly high incomes are unstable and/or only for the best performers.
Isn't that the whole point of the list? It's not like they say "any kind of skill in Management of personnel". They say you need to be good (best performer) in it.
>Consider: "Service orientation." Uh, like in the service industry?
No, like everywhere it is applicable: "Service orientation, aka personality traits and a predisposition to be helpful, thoughtful, considerate and cooperative".
(Besides, there are extremely lucrative jobs in the service industry. Service industry doesn't mean being a waiter. It can also mean e.g. running or owing hotels).
Re: average level vs good at them: part of the problem is that they mix skills that almost everyone has to a certain degree (like reading comprehension) with skills that very few people possess (like coding).
Re: any kind of skill vs being the best performer: they're clearly not referring to best performer skill. Part of their analysis is based on "Time to enter [which] depends on how much training it takes to enter the jobs in which the skill is important." So the level of skill has to be something like entry-level skill for the lowest level of job using the skill. Otherwise the time to enter measure would be meaningless.
>Re: average level vs good at them: part of the problem is that they mix skills that almost everyone has to a certain degree (like reading comprehension) with skills that very few people possess (like coding).
If some skills are a boon to success, why would they be constrained to be one or the other type?
Some would be common in most (but not great in the majority, like reading comprehension skills), others would be rarer (like coding or managing people).
>Re: any kind of skill vs being the best performer: they're clearly not referring to best performer skill. Part of their analysis is based on "Time to enter [which] depends on how much training it takes to enter the jobs in which the skill is important." So the level of skill has to be something like entry-level skill for the lowest level of job using the skill.
"Entry-level skills for the lowest level of job using the skill" can still be compared relatively to others entering the same job -- so a ranking as being the best performer among your competition still makes sense.
Clearly they didn't mean you have to be best in the world, or among the top in your country in those skills. Just better than most you're competing against.
Equipment maintenance may not be low risk for automation.
If you look at modern automation trends in software, a key property is that they rely on throwing things away that don't work, and replacing them with known-good new "instances". The same approach is already used widely for physical goods as well - the "disposable society".
It's not difficult to image equipment "maintenance" being automatically performed by replacing major parts, instead of worrying about trying to diagnose and fix precisely what went wrong.
"Coding isn't one," they say in the title — but programming is there on the diagram (right above mathematics). Is there a difference between programming and coding?
Perhaps I have been unlucky in my past jobs, but the single most important thing that allowed me to be successful in my investment banking career was bowing down to my boss's ego, even when he/she was wrong. A few of my colleagues had perfected this "skill", and got promoted super quick. Talent, ability and reliability are all okay, but giving your interviewer/boss the impression that you will never show them up seems to make you super employable! I remember a particular interview, where me and my then boss were looking to hire a new market risk guy. The first guy we interviewed was super talented, and actually quite a nice guy - I thought he deserved the job - he even corrected our misunderstandings on a newish risk model. The second guy we interviewed, not so great. My boss gave it to the second guy; when I asked him why, he fobbed me off with a vague response, but it was clear to me that he felt threatened. Had the first guy acted a bit more average in the interview and pandered to my boss's ego, he would have almost certainly got the job. Personally, I have also had much more success in interviews/jobs by trying to be distinctly average. Eventually I was sick of playing that game so I started my own company and never looked back!
I have come to see this sort of thing as a symptom of the extreme advantage incumbents have in the marketplace. This is why most companies become straight up high palace drama. They can do this because they rule the kingdom and everyone will pay their tax (do business with them) like it or not. If you threaten the king and show you are smarter you are toast and will be killed.
Every established business I have worked with is like this.
Very true - it's really quite annoying and unnecessary. Funnily enough, even when ex-employees from such firms establish a start up, much of this culture comes with them. I know I had elements of it engrained in my psyche, much to my detriment. It took a good 6 months to train myself to not feel threatened by my own employees. I like to think I'm mostly rid of this mentality now and can celebrate/cultivate the strengths of my team!
Funny how the advice to hire people smarter than you, doesn't work out in real life. Meritocracies are rare, and only seem to emerge out of necessity. That applies for tech companies as well.
I have been jobless for quite sometime. Did an interview recently for a non-tech position in a non-tech industry. I emerged as one of two top candidates alongside an old friend from a previous employer. I know the gentleman very well, and knew there was no way he could beat me in a fair game. Well, he did get the job. Two months later, I get called by HR asking whether I am still interested in the job. Being still jobless, I accepted the offer. Now, the shocking thing is, I did very well in the written test beating my old friend by a significant margin. Apparently, that didn't still factor in their final decision. And, how do I know about me acing the written test? Everyone who was in the panel has separately told me about it. Now, the only explanation I have for their leaving me out in the first place is that someone might have felt very threatened by my confidence and ambition. While only one panelist rated me highly in the oral interview, the rest rated me lower than my previous colleague but with a small margin.
74 comments
[ 1.7 ms ] story [ 150 ms ] threadMakes sense. If you focus on coding there isn't much it applies to (in terms of employment) other than coding for a living or working near coding-related things (CTO, manager, etc.) That being said, accounting also only really applies to a handful of jobs and nobody has ever said being an accountant is risky.
Unrelated, but jbreckmckye your email is in the URL.
[1] - https://support.google.com/analytics/answer/6366371?hl=en
>What are the most valuable combinations of job skills? >David Deming found that the jobs with the greatest growth in employment were those that required both social and mathematical skills.
I think these are the key takeaways. STEM is very important, but it appears the market is saying we have a lack of leadership skills, which are not really emphasized in a typical education.
There are some terrible leaders that somehow get into leadership positions
You listen to the managers, or are otherwise invested in the inner workings of the company. Using those skills of intuition, you gather the business objectives, and then write code to solve those needs in the manner most appropriate to the environment in which you work. Of course, often you're writing more than just code, and will contribute to documentation, and test with your users to gather feedback and improve your solution.
Good programmers spend less of their time writing actual code, and much more of their time understanding the problems their code is meant to solve.
More seriously, lots of junior developers need to do stuff like that so they don't make mistakes when they move to actually designing things.
You really didn't like the suggestion that the two words aren't synonyms. Sorry about that. I used to have a hard time understanding the difference between the terms "tactic" and "strategy" because there were so many examples where they seemed interchangeable, and perhaps you're feeling the same sort of hair-splitting is happening here.
Here's another way of looking at it. Coding is writing new code or improving existing code (maybe even improving it by removing it). Engineering might, for example, be a decision that it's more cost-effective to buy more hardware and spin up a second instance than to refactor code to enable the safe addition of a cache.
If it continues to frustrate you that different words are used to describe different responsibilities, you're free to call them both the same thing. My personal experience in the industry is that one is a superset of the other.
Understanding business needs and gathering requirements is software analysis. Deciding what components to write to fulfill those requirements is system architecture. Determining the modules, algorithms, and data structures to use within those components is software design. Finally, writing down those algorithms and data structures in a way that satisfies the compiler is coding.
Most of us "software engineers," "software developers," or simply "programmers" wear all of these hats at various points in a project's lifecycle. But to wear the title "coder" is to explicitly mark your position as one with minimal critical thinking, problem solving, or decision-making.
Coding is nowhere near sufficient to create programs that solve complex problems, in the same way that typing is not sufficient to create a novel. If people explicitly designated as coders are making decisions and thinking critically, we should be as concerned as if typesetters were reworking character development.
"Design is not coding, coding is not design" [0].
[0] https://en.wikipedia.org/wiki/Software_design
Because that hasn't existed in a long time, at least since the 70s. Much like typesetter don't exist anymore where designers use programs that allow the, to typeset themselves.
* many of these "coders" like future rear admiral Grace Hopper got fed up with this and did something about it, leading to the first compilers and programming languages.
Which is why it's so strange that people would suddenly rally around this term, rather than "programmer" or "developer" or "software engineer" which encompass the full range of what they're doing, and instead choose to cheapen it by calling out the least intellectually challenging step.
You could argue that source code in a contemporary high-level language is a software design, and compilers/interpreters have grown sophisticated enough to eliminate the need for human grunt work.
Reaching a basic level of success in employment is way more holistic than these bar charts would indicate.
Statements like this are just silly:
> "A skill like “judgement” could make you highly employable, but be hard to improve, and so offer poor returns per hour spent learning."
How about this for a pretty generic plan:
- Know your trade: Understand whatever system you are using in depth.
- Understand how you create value within the specific business you are in.
- Have an O.K understanding of how your work interacts with others, and be O.K at explaining your understanding to others.
- Try to consistently interact with others in good faith and try to score runs for your project/business/whatever. Subjugate your own ego as much as possible and remain friendly when things get hectic.
You don't. You listen to someone trustworthy vouching for the person having good judgement.
So then the employability might just read "how much people like you".
Anything that involves a word like "good" instead of something numeric is hard to objectively measure. But if your aim is not science but hiring, you learn to trust your gut and other unscientific instruments. (Human vision is very much flawed as a scientific instrument, but it helps do complex things nonetheless. Same with human judgment.)
The fact that you raised this issue demonstrates good judgement. You pass.
You don't need to "quantify" it. You just need to be able to exercise it. It's one of the things that people you know when you see it (especially in hindsight) whatever the domain (so the fact that it's context dependent doesn't matter either).
But I think part of my gripe stands: the study is treating all these skills as independent when they actually seem pretty interrelated. There are also important confounding factors like industry which aren't given a mention.
For example 'judgement and decision making' in any professional field has to be built on a foundation of technical knowledge. And that judgement and decision making is probably not really transferable to other professional fields.
Is it though? Because we have the case of CEOs and upper management doing fine in widely differing companies and industries.
It's more about knowing who to trust and what the signs tell you, than about having any low- or even mid-level technical knowledge.
Taleb has this story: "“In one of the rare non charlatanic books in finance, descriptively called What I Learned Losing A Million Dollars, the protagonist makes a big discovery. He remarks that a fellow called Joe Siegel, the most active trader in a commodity called “green lumber” actually thought that it was lumber painted green (rather than freshly cut lumber, called green because it had not been dried). And he made a living, even a fortune trading the stuff! Meanwhile the narrator was into theories of what caused the price of commodities to move and went bust. The fact is that predicting the order flow in lumber and the price dynamics narrative had little to do with these details — not the same thing. Floor traders are selected in the most non-narrative manner, just by evolution in the sense that nice arguments don’t make much difference.”
[0] https://80000hours.org/articles/skills-most-employable/
Translation: We cooked up data by adding our biases, but since we teamed up with a "data science fellow", thus our findings must scientific!
This is worse than the average feel good pop pscyhology that appears in NYtimes.
Reminds me of this good bit from an EJMR post:
"Any approach that claims to recover the distribution of individual utility parameters from aggregate data based on arbitrary distributional and functional form assumptions is dubious at best,"
Consider: "Reading comprehension": at a moderate level that's basically everyone in the industrialized world. At a high level, what are the jobs where this is going to be the skill that makes a difference, as opposed to prior training and learning ability re: the things you've read?
Consider: "Management of personnel": in a world in which middle management are the first to be laid off, it's hard not to think that the allegedly high incomes are unstable and/or only for the best performers.
Consider: "Service orientation." Uh, like in the service industry? Sure, that's "employable," for a can't-make-rent sense of the term.
Generally, the list seemingly fails to take into account the extent to which a skill is already saturated. It's striking, for example, that the top few are skills characteristically developed in advanced degree training in the humanities, law, etc., who haven't, shall way say, had the best few years in the job market lately, due to rampant overproduction...
And yet, even HN comments (by native english speakers) illustrate every day that this is not the case. Except if we have a very low bar for that "moderate level".
In any case, when they that you need "those job skills" they don't mean "you need them in the average level that everybody in the industrialized world more or less has them". The mean you if if you're good at them, you have an advantage.
>it's hard not to think that the allegedly high incomes are unstable and/or only for the best performers.
Isn't that the whole point of the list? It's not like they say "any kind of skill in Management of personnel". They say you need to be good (best performer) in it.
>Consider: "Service orientation." Uh, like in the service industry?
No, like everywhere it is applicable: "Service orientation, aka personality traits and a predisposition to be helpful, thoughtful, considerate and cooperative".
(Besides, there are extremely lucrative jobs in the service industry. Service industry doesn't mean being a waiter. It can also mean e.g. running or owing hotels).
Re: any kind of skill vs being the best performer: they're clearly not referring to best performer skill. Part of their analysis is based on "Time to enter [which] depends on how much training it takes to enter the jobs in which the skill is important." So the level of skill has to be something like entry-level skill for the lowest level of job using the skill. Otherwise the time to enter measure would be meaningless.
If some skills are a boon to success, why would they be constrained to be one or the other type?
Some would be common in most (but not great in the majority, like reading comprehension skills), others would be rarer (like coding or managing people).
>Re: any kind of skill vs being the best performer: they're clearly not referring to best performer skill. Part of their analysis is based on "Time to enter [which] depends on how much training it takes to enter the jobs in which the skill is important." So the level of skill has to be something like entry-level skill for the lowest level of job using the skill.
"Entry-level skills for the lowest level of job using the skill" can still be compared relatively to others entering the same job -- so a ranking as being the best performer among your competition still makes sense.
Clearly they didn't mean you have to be best in the world, or among the top in your country in those skills. Just better than most you're competing against.
Equipment maintenance seems low risk, unless robots start repairing themselves. In which case..
If you look at modern automation trends in software, a key property is that they rely on throwing things away that don't work, and replacing them with known-good new "instances". The same approach is already used widely for physical goods as well - the "disposable society".
It's not difficult to image equipment "maintenance" being automatically performed by replacing major parts, instead of worrying about trying to diagnose and fix precisely what went wrong.
1. Be good at your job. 2. Don't be an asshole.
Every established business I have worked with is like this.
http://48laws-of-power.blogspot.com/2013/10/law-1-never-outs...
For people looking to climb the ladder, I recommend you check out the book.
Quality B professionals hire quality C people so that they can feel superior.
Companies have limited money and budget, especially the small and medium ones.
When choosing between candidates, the ones who is cheaper is much more likely to be given the advantage.