Great post! Something I have found very valuable for myself is accumulating experience. Having gone through a process, task or problem even once brings a lot of knowledge and insights. If I had to put it in numbers, I'd say mastery as a whole is 50% knowledge about the layers on one side of the pyramid and 50% experience, at least for me.
That seems to misunderstand the path from apprentice to journeyman (singular) to master. Look to actual (not software) engineers for that. They still do it and they somehow managed it even with present day educational standards.
There is also a deep misunderstanding of what the Internet is. It's not a "third dimension" or a set of marketing hype. It is an engineering marvel. Which again drives home that the author has no grounding in engineering.
This "pyramid of mastery" is roughly as sensible as organizing your bookshelf by color. It might please the eye of a layman, but makes no sense to the knowledgeable. There is no sense of sweep and scope of concepts and instead everything is labelled by size of something a novice can easily identify. Never mind that this shape would be an inverted pyramid given the current taxonomy and concept of size, it just doesn't make sense as a path toward mastery.
Then there is cyclic learning, not drawn because apparently it would spoil the oversimplified diagrams.
I don't understand this piece. It's not trying to sell me anything. If it were, it would be better designed to a purpose. For charity's sake, I'll choose to believe it's an apprentice's draft, a first effort at prose.
Why do people (many software engineers) insist on putting down software engineering like this? I see things like "bad" languages being popular and instances like leftpad cited, as if other disciplines never have clunky standards or silly incidents.
As a software engineer with an electrical engineering degree , I think there are other factors that make software engineering "less" engineering-y.
One of the biggest things that comes to mind for me is that in software engineering a junior engineer can legally build, deploy, and launch a critical project.
In other engineerings, projects require sign-off from a licensed (P.Eng in Canada) engineer. And the engineer that signs off on that project is the one held liable for its success or failure.
Personally, I've loved software engineering for the above as it's let me grow my career much more easily, but I do think of it as a stark difference in engineering and "software engineering".
> One of the biggest things that comes to mind for me is that in software engineering a junior engineer can legally build, deploy, and launch a critical project.
Except in my experience this rarely happens. Maybe your experiences are different?
You're also potentially forgetting something: if their software breaks down it's very, very unlikely to cause a death. There are far, far, far, far fewer cases in which software engineering failures have resulted in death versus, say, structural engineering.
Building a bridge that takes people over a river? Better get that right...
Building LinkedIn? Let's hope we get it right but if we don't, some people get mildly annoyed and the share holders lose their money. It's not quite the same impact, but still downtime isn't ideal.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
As a software engineer with a CS degree who complains about "bad languages", none of that is what matters. Software engineering, as practiced, isn't real engineering.
When people say "actual engineers", they're talking about features like:
* codified best practices for at least 90% of the job (software development does a bit of this, but still precious little, and it's so immature that a lot of codified best practices (e.g. "use OO for everything") are clearly wrong)
* certification, with standards, where it's possible to do a bad enough job that you lose your certification (also true of e.g. doctors or lawyers). that cannot happen in S.E. because there's no certification in the first place.
* jobs with sufficient consequences (e.g. bridges, buildings, electrical work...) are illegal to build without sign-off by a sufficiently senior sufficiently-certified engineer. that isn't the case in S.E., there's no law against a high school student building a site that records PII and then leaks it
* if an engineer signs off on such a job, and is sufficiently negligent in doing so, not only do they lose certification but they can be legally responsible. as far as I know this is in theory just as possible in S.E., but as far as I know has never happened in practice, while it does from time to time happen in other fields
* part of the aforementioned certification is training in questions of law, ethics, and professional liability, whereas most CS students take at most a course on "social consequences" in the hand-wavy abstract, and most "software engineers" didn't do a CS degree anyway
It used to be the case that the word for the super-category here was "professional" (as in "member of a professional association"), but these days people use "professional" just to mean "wears nice clothes and doesn't cuss". Shrug. (btw it's fine that the meaning changed, because a still-older meaning of "profession" is purely religious, so using it for these kinds of training/trades usages is already a "distortion".) But anyway, as I noted above, doctors and lawyers and accountants all share most of these properties, they are far from exclusive to engineers.
I think there are good reasons why software engineering isn't currently real engineering. E.g. civil engineering (one of the oldest types of engineering) muddled along okay without any of these features for thousands of years, and many of these features are effectively impossible in a field as fast-moving (i.e. young) as software. So I'm not necessarily saying that S.E. could reasonably aim for those features in the near future.
But still. Real engineering is a thing, and software engineering isn't real engineering. Yet.
It feels like you and many others look at things tertiary to the core of engineering (certifications, sign-off, etc) and see them as the defining aspects somehow. You could take those away and it'd still be engineering.
Dictionaries aren't perfect but Merriam's definitions closely capture what I think of as engineering really well:
2a : the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people
b : the design and manufacture of complex products
Programs obviously aren't made of physical matter but it's otherwise fitting.
I'm not sure quite how you got "tertiary", but, I mean, to some degree I agree with you. The qualities I pointed out are certainly not sufficient qualities for something to be engineering, and if I had to say which was more important, the design-and-craft or the responsibility, I'd say it was the design-and-craft.
But many things fit that Merriam's definition, and are not engineering. Since you were so honest as to note that dictionaries aren't perfect, I don't want to be a jerk about how useless that definition is, but since you went on to say that software seems to fit, let's just look at some examples of just how excessively inclusive that definition is.
(I'll assume that 2a means "matter and/or energy", because if it means "matter and also energy" then clearly software doesn't qualify anyway.)
Knitting fits those definitions perfectly. Science, yes, mathematics, yes, properties of matter, yes, useful to people, yes, design and manufacture of complex products, yes. Are you claiming that knitting is engineering?
Filmmaking manipulates matter and energy, creates a thing that is useful to people, and involves complex design and complex manufacture.
Music composition depends on math and science, manipulates sources of energy in nature, is useful to people, and involves the design of products (although composition doesn't involve the manufacture of those products; we call that manufacture "performance").
Accounting doesn't worry about "properties of matter and energy" (much as software doesn't, as you point out), but it involves the application of mathematics to create things useful to people, and there's often the design and manufacture of complex (informational) products. (Note that I'm not saying that clerical work fits the definition, I'm saying that the design of accounting processes fits the definition. Obviously many "accountants" are not designing processes but are simply doing bookkeeping, in the same way that a rivetter is not an engineer.)
Compared to any of these, software creation involves no science, typically little mathematics (although there are certainly very deep exceptions to that, haha), and doesn't involve any manufacture. If you're gonna put software creation in the club, you're basically saying that "engineering is creation stuff (including non-physical stuff"). No one agrees with that concept.
---
That has all been arguably a bit of an over-reaction to the details of your argument, so I want to just return here to my core point. Yes, certification and sign-off and ethics and liability and law and culture is arguably a less-essential characteristic of engineering than something to do with making stuff. But in this day and age, the certification and ethics and sign-off and so on is a necessary part of what makes it engineering. And it's one of the main reasons that software engineering as practices isn't real engineering. Yet.
> That seems to misunderstand the path from apprentice to journeyman (singular) to master
That or this? And I don't believe it does. Also no, "actual" engineers don't still (universally) operate in a master/apprentice model. I've heard of that happening in quite some time.
> Look to actual (not software) engineers for that.
This is putting down software engineers who are, by definition of engineering solutions, real engineers. They're just simply not in regulated markets.
> There is also a deep misunderstanding of what the Internet is. It's not a "third dimension" or a set of marketing hype. It is an engineering marvel.
Which part of the article said the Internet was a marketing hype? I think you may have taken the term "third dimension" a bit too literally here. The author didn't mean what you thought they meant.
> This "pyramid of mastery" is roughly as sensible as organizing your bookshelf by color.
Networking fundamentals come before learning to use AWS VPC peering or VPNs, which are tools and frameworks. You learn one before you learn the other. I think the structure is valid.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
Personal attacks and name-calling will get you banned on HN. We also rate limit accounts that post unsubstantive and/or flamewar comments. Please make your substantive points thoughtfully and leave out the rest.
>>There is a widespread belief that putting in 10,000 hours will make you an expert, but that myth has been proved wrong many times).
No, that is a misinterpretation of what deliberate practice involves. Most shallow interpretations like this one just talk about the time involved, and not about the other important factors like continuous feedback and focused practice, and then call it a myth.
I'd say the 10000 hour thing is an oversimplification. There is no clear-cut definition for either "expert" or "deliberate" practice, so those statements can never be proven or disproven.
To me it is inevitable that some people embark on a journey of mastery only to discover that there is some kind of barrier that they can't overcome just by thinking or working their way out of it. Plenty of clear-cut examples, lot's of more murky ones. Some barriers are predictable, some aren't.
And mastery doesn't even equal success. Many master painters had no success in their life time. Many successful artists have questionably mastery.
The medieval explanation was far more revealing than the pyramid that came after.
I highly recommend "everydays" as a way to mastery. I've done in arts and music and I'm still mind blown at how fast and proficient I got.
The rules are simple: do one thing every day, that you can be held accountable (aka. in public). Such as a daily jam on twitch or soundcloud, a piece on IG. Keep it up, after 2-3 days you get much faster, after 10 days you do it flyingly, after 30 days I find the curve flattens a bit as you're pretty much as proficient as could be. Time to then start another goal as "everyday". If you miss one day, don't sweat it. Pretend that day didn't happen.
I really like that idea. I use it a lot in my own work. For example, working through the sample sheets for an MIT opencourseware or working on learning a Data Science problem. Focus on how you construct your habits to learn more.
yeah and because you "ship" something everyday, your pipeline gets put in place. You'll have no blockers, you can then spend more time on better results, the pipeline is ready to go for the shipping part, whatever that may be.
Some of my everyday pieces got so good they started rivalling with my quality work I spent days on.
I’m fascinated by the master apprentice relationship in craftsmanship and other things like meditation practice (zen). It is a really powerful and - excuse this wishy washy term - natural principle.
But I think it is not as prevalent as it should be when it comes to programming and software development, which is a beautiful mix of problem solving, craft/skill, and the arts of communication and organization. It is driven by experience/practice and pragmatism but also creativity and synthesis. This paradox yearns for mentorship.
Gladly we have some excellent thinkers and communicators in our culture and history. And the internet. But I feel as an industry we don’t do as much as we should to further our craftsmanship.
I agree. I have been unsuccessfully looking for a SWE/programming mentor for years. I am now back in school, working on a PhD at a CS department and I am still facing the same problem. Curiously, I have had no difficulty finding mentors in other areas, e.g., modeling, psychology. I often wonder if I am doing something wrong or is mentoring simply not a part of the SWE culture.
It seems to me the pyramid needs to be flipped upside down. The amount of knowledge needed at mastery is much higher than at the base level when you are learning the elements. It is oversimplified to say the least. Seems like an average post that appeals to a layman who is searching the Internet for an short guided answer to mastery. I didn't buy it.reads like any other self help book or guide. Sorry. Lastly the 10000 hour thing is far deeper than that. Please read the context behind it. Overall decent for a first post on a hobby blog.
> It seems to me the pyramid needs to be flipped upside down. The amount of knowledge needed at mastery is much higher than at the base level when you are learning the elements.
You're confusing knowledge with experience. At the top end of a career you need a lot of experience to build solutions, but that experience is built up (slowly) by understanding first the fundamentals, followed by how-to build tools and solutions, finally abstracting them behind frameworks or SaaS products.
You have to understand TCP/IP before you can fit out an office with a network. You have to understand Python before you can use Django. And you have to understand Django before you can build a SaaS product. And you need experience before you can build anything good.
> Overall decent for a first post on a hobby blog.
I might come across as a bit condescending calling it a "hobby blog". It's sort of putting down the OP's efforts, I feel.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
I think the author confuses experts at performing particular tasks and experts for some field of knowledge.
And then goes on to reiterate the age old wisdom that you need to practice, and especially the fundamentals, to gain expert skills.
To become expert at either teaching a skill or a subject matter, or even advance the field, I think the most important activity is to find out and understand what and how they are doing and thinking.
Standing on the shoulders of Giants is a good first step even if just to survey where to leap next.
There's a certain truth to be considered that there are some things you will never be able to master, not even after 20000 hours. Usually people identify these things early on in life, but sometimes it takes a while.
For example, I realized early on that I would never be able to become a fighter pilot.
I found myself actually being able to do things I thought early on I could never become good at, and pretty well.
If anything, now I treat that unpleasant feeling of perceived impossibility of something as a strong indication that I should pursue it. It never let me down.
I think pretty much the only thing that disqualifies you from becoming a fighter jet pilot is an untreatable bodily impediment. Well, also pacifism, but that’s chosen :)
30 comments
[ 4.6 ms ] story [ 80.3 ms ] threadThere is also a deep misunderstanding of what the Internet is. It's not a "third dimension" or a set of marketing hype. It is an engineering marvel. Which again drives home that the author has no grounding in engineering.
This "pyramid of mastery" is roughly as sensible as organizing your bookshelf by color. It might please the eye of a layman, but makes no sense to the knowledgeable. There is no sense of sweep and scope of concepts and instead everything is labelled by size of something a novice can easily identify. Never mind that this shape would be an inverted pyramid given the current taxonomy and concept of size, it just doesn't make sense as a path toward mastery.
Then there is cyclic learning, not drawn because apparently it would spoil the oversimplified diagrams.
I don't understand this piece. It's not trying to sell me anything. If it were, it would be better designed to a purpose. For charity's sake, I'll choose to believe it's an apprentice's draft, a first effort at prose.
Why do people (many software engineers) insist on putting down software engineering like this? I see things like "bad" languages being popular and instances like leftpad cited, as if other disciplines never have clunky standards or silly incidents.
One of the biggest things that comes to mind for me is that in software engineering a junior engineer can legally build, deploy, and launch a critical project.
In other engineerings, projects require sign-off from a licensed (P.Eng in Canada) engineer. And the engineer that signs off on that project is the one held liable for its success or failure.
Personally, I've loved software engineering for the above as it's let me grow my career much more easily, but I do think of it as a stark difference in engineering and "software engineering".
Except in my experience this rarely happens. Maybe your experiences are different?
You're also potentially forgetting something: if their software breaks down it's very, very unlikely to cause a death. There are far, far, far, far fewer cases in which software engineering failures have resulted in death versus, say, structural engineering.
Building a bridge that takes people over a river? Better get that right...
Building LinkedIn? Let's hope we get it right but if we don't, some people get mildly annoyed and the share holders lose their money. It's not quite the same impact, but still downtime isn't ideal.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
EDIT: Apologies to all. This isn't the right attitude for HN and I'll refrain from this kind of behavior in the future.
When people say "actual engineers", they're talking about features like:
* codified best practices for at least 90% of the job (software development does a bit of this, but still precious little, and it's so immature that a lot of codified best practices (e.g. "use OO for everything") are clearly wrong) * certification, with standards, where it's possible to do a bad enough job that you lose your certification (also true of e.g. doctors or lawyers). that cannot happen in S.E. because there's no certification in the first place. * jobs with sufficient consequences (e.g. bridges, buildings, electrical work...) are illegal to build without sign-off by a sufficiently senior sufficiently-certified engineer. that isn't the case in S.E., there's no law against a high school student building a site that records PII and then leaks it * if an engineer signs off on such a job, and is sufficiently negligent in doing so, not only do they lose certification but they can be legally responsible. as far as I know this is in theory just as possible in S.E., but as far as I know has never happened in practice, while it does from time to time happen in other fields * part of the aforementioned certification is training in questions of law, ethics, and professional liability, whereas most CS students take at most a course on "social consequences" in the hand-wavy abstract, and most "software engineers" didn't do a CS degree anyway
It used to be the case that the word for the super-category here was "professional" (as in "member of a professional association"), but these days people use "professional" just to mean "wears nice clothes and doesn't cuss". Shrug. (btw it's fine that the meaning changed, because a still-older meaning of "profession" is purely religious, so using it for these kinds of training/trades usages is already a "distortion".) But anyway, as I noted above, doctors and lawyers and accountants all share most of these properties, they are far from exclusive to engineers.
I think there are good reasons why software engineering isn't currently real engineering. E.g. civil engineering (one of the oldest types of engineering) muddled along okay without any of these features for thousands of years, and many of these features are effectively impossible in a field as fast-moving (i.e. young) as software. So I'm not necessarily saying that S.E. could reasonably aim for those features in the near future.
But still. Real engineering is a thing, and software engineering isn't real engineering. Yet.
Dictionaries aren't perfect but Merriam's definitions closely capture what I think of as engineering really well:
2a : the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people
b : the design and manufacture of complex products
Programs obviously aren't made of physical matter but it's otherwise fitting.
But many things fit that Merriam's definition, and are not engineering. Since you were so honest as to note that dictionaries aren't perfect, I don't want to be a jerk about how useless that definition is, but since you went on to say that software seems to fit, let's just look at some examples of just how excessively inclusive that definition is.
(I'll assume that 2a means "matter and/or energy", because if it means "matter and also energy" then clearly software doesn't qualify anyway.)
Knitting fits those definitions perfectly. Science, yes, mathematics, yes, properties of matter, yes, useful to people, yes, design and manufacture of complex products, yes. Are you claiming that knitting is engineering?
Filmmaking manipulates matter and energy, creates a thing that is useful to people, and involves complex design and complex manufacture.
Music composition depends on math and science, manipulates sources of energy in nature, is useful to people, and involves the design of products (although composition doesn't involve the manufacture of those products; we call that manufacture "performance").
Accounting doesn't worry about "properties of matter and energy" (much as software doesn't, as you point out), but it involves the application of mathematics to create things useful to people, and there's often the design and manufacture of complex (informational) products. (Note that I'm not saying that clerical work fits the definition, I'm saying that the design of accounting processes fits the definition. Obviously many "accountants" are not designing processes but are simply doing bookkeeping, in the same way that a rivetter is not an engineer.)
Compared to any of these, software creation involves no science, typically little mathematics (although there are certainly very deep exceptions to that, haha), and doesn't involve any manufacture. If you're gonna put software creation in the club, you're basically saying that "engineering is creation stuff (including non-physical stuff"). No one agrees with that concept.
---
That has all been arguably a bit of an over-reaction to the details of your argument, so I want to just return here to my core point. Yes, certification and sign-off and ethics and liability and law and culture is arguably a less-essential characteristic of engineering than something to do with making stuff. But in this day and age, the certification and ethics and sign-off and so on is a necessary part of what makes it engineering. And it's one of the main reasons that software engineering as practices isn't real engineering. Yet.
That or this? And I don't believe it does. Also no, "actual" engineers don't still (universally) operate in a master/apprentice model. I've heard of that happening in quite some time.
> Look to actual (not software) engineers for that.
This is putting down software engineers who are, by definition of engineering solutions, real engineers. They're just simply not in regulated markets.
> There is also a deep misunderstanding of what the Internet is. It's not a "third dimension" or a set of marketing hype. It is an engineering marvel.
Which part of the article said the Internet was a marketing hype? I think you may have taken the term "third dimension" a bit too literally here. The author didn't mean what you thought they meant.
> This "pyramid of mastery" is roughly as sensible as organizing your bookshelf by color.
Networking fundamentals come before learning to use AWS VPC peering or VPNs, which are tools and frameworks. You learn one before you learn the other. I think the structure is valid.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
https://news.ycombinator.com/newsguidelines.html
No, that is a misinterpretation of what deliberate practice involves. Most shallow interpretations like this one just talk about the time involved, and not about the other important factors like continuous feedback and focused practice, and then call it a myth.
To me it is inevitable that some people embark on a journey of mastery only to discover that there is some kind of barrier that they can't overcome just by thinking or working their way out of it. Plenty of clear-cut examples, lot's of more murky ones. Some barriers are predictable, some aren't.
And mastery doesn't even equal success. Many master painters had no success in their life time. Many successful artists have questionably mastery.
I highly recommend "everydays" as a way to mastery. I've done in arts and music and I'm still mind blown at how fast and proficient I got.
The rules are simple: do one thing every day, that you can be held accountable (aka. in public). Such as a daily jam on twitch or soundcloud, a piece on IG. Keep it up, after 2-3 days you get much faster, after 10 days you do it flyingly, after 30 days I find the curve flattens a bit as you're pretty much as proficient as could be. Time to then start another goal as "everyday". If you miss one day, don't sweat it. Pretend that day didn't happen.
Some of my everyday pieces got so good they started rivalling with my quality work I spent days on.
I’m fascinated by the master apprentice relationship in craftsmanship and other things like meditation practice (zen). It is a really powerful and - excuse this wishy washy term - natural principle.
But I think it is not as prevalent as it should be when it comes to programming and software development, which is a beautiful mix of problem solving, craft/skill, and the arts of communication and organization. It is driven by experience/practice and pragmatism but also creativity and synthesis. This paradox yearns for mentorship.
Gladly we have some excellent thinkers and communicators in our culture and history. And the internet. But I feel as an industry we don’t do as much as we should to further our craftsmanship.
https://www.6seconds.org/2018/02/09/the-great-practice-myth-... - Perhaps this is can help shine some light on the author's original comments regarding the 10,000 hour rule?
> It seems to me the pyramid needs to be flipped upside down. The amount of knowledge needed at mastery is much higher than at the base level when you are learning the elements.
You're confusing knowledge with experience. At the top end of a career you need a lot of experience to build solutions, but that experience is built up (slowly) by understanding first the fundamentals, followed by how-to build tools and solutions, finally abstracting them behind frameworks or SaaS products.
You have to understand TCP/IP before you can fit out an office with a network. You have to understand Python before you can use Django. And you have to understand Django before you can build a SaaS product. And you need experience before you can build anything good.
> Overall decent for a first post on a hobby blog.
I might come across as a bit condescending calling it a "hobby blog". It's sort of putting down the OP's efforts, I feel.
EDIT: Apologies for being so crude in my original wording. I'm updating the comment to reflect a more professional, civil tone.
And then goes on to reiterate the age old wisdom that you need to practice, and especially the fundamentals, to gain expert skills.
To become expert at either teaching a skill or a subject matter, or even advance the field, I think the most important activity is to find out and understand what and how they are doing and thinking.
Standing on the shoulders of Giants is a good first step even if just to survey where to leap next.
For example, I realized early on that I would never be able to become a fighter pilot.
If anything, now I treat that unpleasant feeling of perceived impossibility of something as a strong indication that I should pursue it. It never let me down.
I think pretty much the only thing that disqualifies you from becoming a fighter jet pilot is an untreatable bodily impediment. Well, also pacifism, but that’s chosen :)