Short fat engineers are undervalued(nested.substack.com)
nested.substack.com
Short fat engineers are undervalued
https://nested.substack.com/p/short-fat-engineers-are-undervalued
268 comments
Diversity.
I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." <looks of surprise> A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing.
This whole expert thing isn't tenable on a long term project. The expert will get bored and wander off, at which point all the mistakes they avoided will just be explored in their absence. Unless they built up people, documentation and processes to take over the work.
My read of Kernighan's Law, back-ported onto my own philosophy, is that most of the time you don't want the most capable person working on a solution. You want the 2nd or 3rd most capable person on it, have them reach consensus with the other two. Maybe 10% of your code should be as clever as you can manage. Most of the rest should be so boring that only the junior people find it interesting. The bottom rungs of an orchard ladder everyone is trying to climb.
I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." <looks of surprise> A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing.
This whole expert thing isn't tenable on a long term project. The expert will get bored and wander off, at which point all the mistakes they avoided will just be explored in their absence. Unless they built up people, documentation and processes to take over the work.
My read of Kernighan's Law, back-ported onto my own philosophy, is that most of the time you don't want the most capable person working on a solution. You want the 2nd or 3rd most capable person on it, have them reach consensus with the other two. Maybe 10% of your code should be as clever as you can manage. Most of the rest should be so boring that only the junior people find it interesting. The bottom rungs of an orchard ladder everyone is trying to climb.
The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they teach everyone how to use it and why
And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature.
Force multiplier is the game.
And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature.
Force multiplier is the game.
No thank you.
Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes.
The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific trajectory. And if ever the non-experts decide to do something different, -that's their prerogative-. Because it's they who will be dealing with the fallout if they're wrong. And unfair to make them deal with the fallout if they were right, and the expert was wrong. It's incumbent on the expert to convince them, not dictate.
Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes.
The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific trajectory. And if ever the non-experts decide to do something different, -that's their prerogative-. Because it's they who will be dealing with the fallout if they're wrong. And unfair to make them deal with the fallout if they were right, and the expert was wrong. It's incumbent on the expert to convince them, not dictate.
I'm in line with your comment more than the parent. This happened to me too. Turns out this expert was very knowledgeable, but spread very thin so he could never help out as much as was needed. Furthermore, there were just issues that one couldn't have predicted because it would require months of working in the code base to see the problems clearly manifest.
Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.
Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.
This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable.
It's fine if people want to do something different: just first become an expert.
It's fine if people want to do something different: just first become an expert.
This thread shows the problems with both approaches. Being handed a design that isn't appreciated but expected to follow tends to go off in a direction that's unproductive, especially if there isn't someone who understands the value and maintains the key parts so as not to lose it.
The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn.
Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.
The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn.
Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.
'decide to break patterns and remove guardrails because they don't understand their purpose'
Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point.
An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.
Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point.
An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.
Absolutely, but it's a three-way street. The experts must be willing to teach, the non-experts must be willing to learn, and the organization must be willing to allow them the time to do so.
If any one of those things is missing, it doesn't work. And in my experience, the most likely ingredient to be present is it willingness of the experts to teach. If you're good at something, it's fun to explain it to others.
If any one of those things is missing, it doesn't work. And in my experience, the most likely ingredient to be present is it willingness of the experts to teach. If you're good at something, it's fun to explain it to others.
I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along.
Without it, you start out with a multiplier but end with a divisor.
Without it, you start out with a multiplier but end with a divisor.
I think that's why it's very important to get buy-in and solicit feedback from coworkers even if you're the domain expert. Also, regression test coverage from the beginning is very important if you ever expect anyone else or even your future self to have a shot at safely modifying mission critical pieces of code.
You have to get people invested in the solution. Some people call that buy-in, others use that term a little more tepidly.
It could be described as about the bus factor, couldn't it?
If an organization has a product, and that product is not retired, it should be sustainable by a team.
Lone points of breakage such as a single visionary or the mythic 10x-er are not optimal for the product if the unit taking care of the product is a team or several teams.
Lone points of breakage such as a single visionary or the mythic 10x-er are not optimal for the product if the unit taking care of the product is a team or several teams.
I have been the "expert" in many situations, and no way would I let this happen.
1.) Mentoring is such a difficult aspect as an expert. I likely would have built up my expertise from a combination of my studies, my past work experience and my previous, extremely skilled mentors. I can't expect people to get up to speed simply through my mentoring alone - especially if I'm not a capable enough communicator.
2.) Experts like to retain their expertise, stay unique. Regardless of what idealistic scenario you have in mind, everywhere I've seen, experts are always very cautious to giving away ground. I've been guilty of it, especially when I knew that my unique expertise was responsible for my sizeable bonus check in an IB.
3.) Experts will not do all the grunt work you mentioned. They come with the expectation that they've been hired for their expertise and not to be another cog in the wheel, but the engine itself (for a particular project).
Ideally now, what you would want would be a team of generalists, and a small crack team of experts (or a lone wolf expert). The generalists set up the project, plan how to build the guard rails, etc, then explain it to the experts, then when both are up to speed, generalists build it out and give the heavy lifting work to the experts to take over from.
Converting a generalist to an expert is a time intensive process that has to be structured and well-thought out. It should not be for just one project, but should continue for multiple projects.
1.) Mentoring is such a difficult aspect as an expert. I likely would have built up my expertise from a combination of my studies, my past work experience and my previous, extremely skilled mentors. I can't expect people to get up to speed simply through my mentoring alone - especially if I'm not a capable enough communicator.
2.) Experts like to retain their expertise, stay unique. Regardless of what idealistic scenario you have in mind, everywhere I've seen, experts are always very cautious to giving away ground. I've been guilty of it, especially when I knew that my unique expertise was responsible for my sizeable bonus check in an IB.
3.) Experts will not do all the grunt work you mentioned. They come with the expectation that they've been hired for their expertise and not to be another cog in the wheel, but the engine itself (for a particular project).
Ideally now, what you would want would be a team of generalists, and a small crack team of experts (or a lone wolf expert). The generalists set up the project, plan how to build the guard rails, etc, then explain it to the experts, then when both are up to speed, generalists build it out and give the heavy lifting work to the experts to take over from.
Converting a generalist to an expert is a time intensive process that has to be structured and well-thought out. It should not be for just one project, but should continue for multiple projects.
> Experts like to retain their expertise, stay unique.
In sports they call that a Ball Hog.
Is software a collaborative effort or an ego trip for three people?
As someone else mentioned, their expert was spread too thin. I’ve had this happen to me, too, and the only solution I know is to give away (delegate) almost everything you can. If some part really makes you happy, hold onto that even if you could give it away. Not for ego, but for burnout. You need some reasons to show up in the morning, just like everybody else.
In sports they call that a Ball Hog.
Is software a collaborative effort or an ego trip for three people?
As someone else mentioned, their expert was spread too thin. I’ve had this happen to me, too, and the only solution I know is to give away (delegate) almost everything you can. If some part really makes you happy, hold onto that even if you could give it away. Not for ego, but for burnout. You need some reasons to show up in the morning, just like everybody else.
A lot of people seem against this approach, but I'm all for it.
In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.
In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.
I'm half with you, and I see both sides.
When it's done well, I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and help with the hard problems, but most of the day-to-day work is on them. It's working out great because it seems I got the structure relatively right (they've changed things a little bit as they've added new things I didn't think of, and I've reviewed and supported those changes)
The flip side is ${JOB-2} for me. It was a similar situation; an "expert" laid the foundations and then got pulled off to do other projects. There were two main differences between my current situation and that one:
- The infrastructure he put together was not great and full of footguns (e.g. accidentally implicitly double-encoding HTTP requests, bizarre cookie handling, etc)
- The code was hard to change because of how it was integrated, and the team didn't feel particularly empowered to fix it
- He was barely around (being assigned to something in a different building).
- He pushed back hard when people suggested that there might be problems with it and fixes required. Instead of facilitating and reviewing, he'd pop by occasionally, look at things that changed in his absence, and shit on them.
As I'm writing this, I'm reflecting on whether or not I'm contributing enough to the long-term development of this codebase, and I'm feeling relatively ok with the answer. Ultimately, this product is still my baby and whether or not it's successful is on me. Maybe that's the difference? I'm quite invested in the foundations I laid, and more than happy to help my team work through issues they find in it?
When it's done well, I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and help with the hard problems, but most of the day-to-day work is on them. It's working out great because it seems I got the structure relatively right (they've changed things a little bit as they've added new things I didn't think of, and I've reviewed and supported those changes)
The flip side is ${JOB-2} for me. It was a similar situation; an "expert" laid the foundations and then got pulled off to do other projects. There were two main differences between my current situation and that one:
- The infrastructure he put together was not great and full of footguns (e.g. accidentally implicitly double-encoding HTTP requests, bizarre cookie handling, etc)
- The code was hard to change because of how it was integrated, and the team didn't feel particularly empowered to fix it
- He was barely around (being assigned to something in a different building).
- He pushed back hard when people suggested that there might be problems with it and fixes required. Instead of facilitating and reviewing, he'd pop by occasionally, look at things that changed in his absence, and shit on them.
As I'm writing this, I'm reflecting on whether or not I'm contributing enough to the long-term development of this codebase, and I'm feeling relatively ok with the answer. Ultimately, this product is still my baby and whether or not it's successful is on me. Maybe that's the difference? I'm quite invested in the foundations I laid, and more than happy to help my team work through issues they find in it?
There's also the fundamental question of whether or not the expert is actually an expert. It sounds like in the unpleasant case you mention, maybe there wasn't so much expertise there.
I think you're right that having skin in the game is critical. It's important to have real accountability, so if there's painful design flaws, the expert feels it.
But it's easy to think it should have been done differently and better when you don't have the perspective of the designer. I still vividly recall being a junior engineer and thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong. Thank goodness he was patient.
I think you're right that having skin in the game is critical. It's important to have real accountability, so if there's painful design flaws, the expert feels it.
But it's easy to think it should have been done differently and better when you don't have the perspective of the designer. I still vividly recall being a junior engineer and thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong. Thank goodness he was patient.
> thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong
I'm laughing pretty hard at this. The codebase in this current project is definitely a bit... quirkly. It's semi-embedded (Linux on an 8-core ARM unit) and doing high-performance image processing (C++ on Linux). The new guy last month has a fair bit more programming experience than "fresh grad" would lead one to expect, and the first week he had a lot of questions like that.
Him: "Why is it like this? Couldn't we just..."
Me: "Would that keep all 8 cores busy processing things as fast as possible?"
Him: "Oh. Yeah. I guess not!"
Him: "Wait... couldn't we just...hmmm...no... that would serialize everything..."
I suppose one other angle to it is that I don't have a lot of ego in it; if someone figures out a way to squeeze more juice out of the system we've got, they're going to get high-fives.
I'm laughing pretty hard at this. The codebase in this current project is definitely a bit... quirkly. It's semi-embedded (Linux on an 8-core ARM unit) and doing high-performance image processing (C++ on Linux). The new guy last month has a fair bit more programming experience than "fresh grad" would lead one to expect, and the first week he had a lot of questions like that.
Him: "Why is it like this? Couldn't we just..."
Me: "Would that keep all 8 cores busy processing things as fast as possible?"
Him: "Oh. Yeah. I guess not!"
Him: "Wait... couldn't we just...hmmm...no... that would serialize everything..."
I suppose one other angle to it is that I don't have a lot of ego in it; if someone figures out a way to squeeze more juice out of the system we've got, they're going to get high-fives.
Wrong comparison. Django and React are products, if you were to say experts make it easier for us to write Django and React themselves that would better.
That doesn't make sense to me. Where do you draw the line between a framework and a product?
Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product?
Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?
Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product?
Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?
agree - in my view, if you're not designing for the 'hit by a bus scenario', you're not an expert, irrespective of technical knowledge
As a generalist, I agree with bulk of what you're saying but at least my personal experience seems to echo the fact that generalists in general are undervalued since when someone asks a person "what can you do for me", a specialist always has a better and sharper answer than a generalist - and that makes all the difference.
Personally I'll take a generalist any day since specialists suffer from the "if you only have a hammer everything looks like a nail" syndrome.
Having said that, my 1 career advice to anyone would be, become a specialist in 1-single thing, and then become a generalist in everything else. I'm not that, but I feel that that I would have been best served if I had been that.
Personally I'll take a generalist any day since specialists suffer from the "if you only have a hammer everything looks like a nail" syndrome.
Having said that, my 1 career advice to anyone would be, become a specialist in 1-single thing, and then become a generalist in everything else. I'm not that, but I feel that that I would have been best served if I had been that.
Sounds like the 'T' shaped skill set.
Sorry, not sure what you mean by ‘T’ shaped skill set. Could you elaborate..
[deleted]
It is used to describe a skillset which has a little experience in a wide number of areas (the top of the T) and deep experience in a single area (the stick of the T).
Thanks, yes, than that is what I was referring to, I just didn't know that there was actually a term for it.
The article discusses T shaped engineers. It's pretty good, I suggest reading it!
My experience is that opposite. I'm a generalist and every company I've worked for is looking for generalists. If you're doing boring business work, which most of us are, you don't need to know every crevice of any technology. The majority of software development is not moving the needle on crypto or search algorithms, it's crud business apps and reporting.
> it's crud business apps and reporting.
And yet... as 'boring' as those things are, I constantly see basic errors crop up all the time because people aren't even moderately versed in the technologies.
For example, you don't need to "know every crevice of a technology", but if you're doing LOB reports for business systems, I would reasonably expect you to understand what indexes are, or what joins are and how to use them, in your SQL engine of choice,
And yet... as 'boring' as those things are, I constantly see basic errors crop up all the time because people aren't even moderately versed in the technologies.
For example, you don't need to "know every crevice of a technology", but if you're doing LOB reports for business systems, I would reasonably expect you to understand what indexes are, or what joins are and how to use them, in your SQL engine of choice,
Don't take this the wrong way, but I feel like you are undervaluing short fat engineers. :)
The article isn't saying that specialists aren't valuable. In fact is says the opposite: "If you know exactly what you need, and you need it right now, choose depth." It is just saying that perhaps the short fat engineer would be the one who realizes they need an OpenGL specialist on the team in the first place because the graphics are hitting a bottleneck and slowing down everything else. The author is merely pointing out that in the nascent portion of projects their contributions are, at times, under valued.
The article isn't saying that specialists aren't valuable. In fact is says the opposite: "If you know exactly what you need, and you need it right now, choose depth." It is just saying that perhaps the short fat engineer would be the one who realizes they need an OpenGL specialist on the team in the first place because the graphics are hitting a bottleneck and slowing down everything else. The author is merely pointing out that in the nascent portion of projects their contributions are, at times, under valued.
> you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore
to expand on this, I've found most of my happiness as a generalist in early stage startups. to me, a larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. obviously there are exceptions to this rule - some companies just prefer generalists - but usually once teams get big enough, people settle into specific roles, even as a generalist.
to expand on this, I've found most of my happiness as a generalist in early stage startups. to me, a larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. obviously there are exceptions to this rule - some companies just prefer generalists - but usually once teams get big enough, people settle into specific roles, even as a generalist.
> larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together.
Or that their culture is such that they have entrenched, stovepiped personnel that don't venture out of their specific knowledge domains and they need somebody to bridge that gap.
An analogy that I've used far too often when describing software deployment in traditional orgs is one of the dev team and IT playing tennis with the grenade that is the software. With each volley back and forth they give each other nigh-useless information - the operations team will tell the dev team that it crashed without sending logs and that it's because of random setting X that they pulled out of a hat, then the dev team will tell the ops team that said configuration value is hardcoded but that can't be the problem because it runs perfectly on their dev machine, and so on and so forth. Having somebody to mediate this interaction so that it's actually productive is inherently invaluable to, y'know, getting actual work done.
Unfortunately it's not particularly valuable from a business perspective because if your org is operating this way then it means that they place greater value on the performance of "software engineering" than the actual value added by the software produced. So basically what you said.
Or that their culture is such that they have entrenched, stovepiped personnel that don't venture out of their specific knowledge domains and they need somebody to bridge that gap.
An analogy that I've used far too often when describing software deployment in traditional orgs is one of the dev team and IT playing tennis with the grenade that is the software. With each volley back and forth they give each other nigh-useless information - the operations team will tell the dev team that it crashed without sending logs and that it's because of random setting X that they pulled out of a hat, then the dev team will tell the ops team that said configuration value is hardcoded but that can't be the problem because it runs perfectly on their dev machine, and so on and so forth. Having somebody to mediate this interaction so that it's actually productive is inherently invaluable to, y'know, getting actual work done.
Unfortunately it's not particularly valuable from a business perspective because if your org is operating this way then it means that they place greater value on the performance of "software engineering" than the actual value added by the software produced. So basically what you said.
> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore.
Generalists could also be the people in the project who get things done: they may have sufficient domain knowledge to implement the recommendations of a specialist. In poorly-managed or understaffed teams, a generalist might feel a bit frustrated because they're a go-to for any Job That Needs Doing Right Now, even if it falls outside of the field of their deepest experience.
Generalists could also be the people in the project who get things done: they may have sufficient domain knowledge to implement the recommendations of a specialist. In poorly-managed or understaffed teams, a generalist might feel a bit frustrated because they're a go-to for any Job That Needs Doing Right Now, even if it falls outside of the field of their deepest experience.
You're going to pay more for a specialist but in shorter bursts whereas you're going to need generalists in longer stretches. Generalists are where your tribal knowledge and lessons learned are going to live. Generalists are also more likely to move into management because of the perspective they bring and adaptability inherent in being a generalist.
I think the management point is a good one. A valuable generalist role is working at the interface between management and the specialists in the team. As an engineer I was much more of a generalist which lead me into product management.
> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore.
My general take is that generalists would excel in small scrappy disorganized organic teams, while "specificists" would do well in teams with high level of organization and management structure. Unfortunately, large organizations tend to push out generalists, as structure increases, and their value in the eyes of management decreases.
I think a large organization should have both kinds of teams. This kind of alludes to Clayton Christensen's Innovator's Dilemma -- "well managed" big orgs should be internally disrupted by small-scale "startup" style teams, and those scrappy organic type of teams need generalists.
My general take is that generalists would excel in small scrappy disorganized organic teams, while "specificists" would do well in teams with high level of organization and management structure. Unfortunately, large organizations tend to push out generalists, as structure increases, and their value in the eyes of management decreases.
I think a large organization should have both kinds of teams. This kind of alludes to Clayton Christensen's Innovator's Dilemma -- "well managed" big orgs should be internally disrupted by small-scale "startup" style teams, and those scrappy organic type of teams need generalists.
> you're likely in the wrong project
The point is there are less project slots for generalists to be in right now.
The point is there are less project slots for generalists to be in right now.
>I think there's a point in every innovation where the generalist contribution declines sharply.
That why as another post commented they move into management or product at larger organizations. They get to move the needle and apply their generalist knowledge even to mature projects.
That why as another post commented they move into management or product at larger organizations. They get to move the needle and apply their generalist knowledge even to mature projects.
The article itself isn't about this but one could theorize that the headline taken literally is also likely true.
Ngl for a minute before clicking I was slightly curious if this was some random study of the literal interpretation.
I believe there is ample research showing height and attractiveness (one could reasonably consider weight to be one determining factor in attractiveness) do play a factor in career success, compensation, and selection for leadership.
I noticed at Microsoft that the tallest people always got promoted. It never made any sense to me - we weren’t playing basketball.
It may have been other factors that were involved in their promotions. Did they perhaps walk around with their arms out to the sides, in a T-esque shape?
I think that only works in Tetris.
To give one (admittedly not conclusive) datapoint: almost all US Presidents have been taller than the average American male, many of them exceptionally slow (Lincoln was 6'4"!), and the effect has become more pronounced in the modern era (height was less of an advantage in the days when there was no TV or photography so voters had less of an idea what you looked like.)
Also, the taller presidential candidate is statistically more likely to win the election: "In the thirty-one presidential elections between 1900 and 2020, twenty of the winning candidates have been taller than their opponents, while nine have been shorter, and two were the same height. On average the winner was 1.1 inches (2.8 cm) taller than the loser."
https://en.wikipedia.org/wiki/Heights_of_presidents_and_pres...
Also, the taller presidential candidate is statistically more likely to win the election: "In the thirty-one presidential elections between 1900 and 2020, twenty of the winning candidates have been taller than their opponents, while nine have been shorter, and two were the same height. On average the winner was 1.1 inches (2.8 cm) taller than the loser."
https://en.wikipedia.org/wiki/Heights_of_presidents_and_pres...
Invader Zim was prescient, it turns out.
Halo Effect, baby.
I think it goes more the other way around. Successful people prefer to look attractive, so they take the necessary steps to achieve that. Elon M would be an example, I guess.
[0]: https://news.ycombinator.com/item?id=7378972
[0]: https://news.ycombinator.com/item?id=7378972
Yes, we all know that time when Musk decided to grow taller.
Yes, we all know that time when Musk decided to grow t̶a̶l̶l̶e̶r̶ hair.
Fatness and lack of stature was the original topic.
But the comment you replied to talked about attractiveness in general.
Here’s the comment that that one was a reply to:
> I believe there is ample research showing height and attractiveness (one could reasonably consider weight to be one determining factor in attractiveness) do play a factor in career success, compensation, and selection for leadership.
Look, only about obesity and height (and mainly height). To which they replied:
> I think it goes more the other way around. …
Which makes no sense because no one ever mentioned hair, so that can’t be used as a direct counter-argument to a comment about research on height.
Are we gonna continue this? This is enough for me.
> I believe there is ample research showing height and attractiveness (one could reasonably consider weight to be one determining factor in attractiveness) do play a factor in career success, compensation, and selection for leadership.
Look, only about obesity and height (and mainly height). To which they replied:
> I think it goes more the other way around. …
Which makes no sense because no one ever mentioned hair, so that can’t be used as a direct counter-argument to a comment about research on height.
Are we gonna continue this? This is enough for me.
I would write a rebuttal, but you have written it for me. "attractiveness (one could reasonably consider weight to be one determining factor in attractiveness)" does not mean "attractiveness (which means weight)".
Wait, it's possible to look significantly more attractive through willpower alone? I dress okay and am not a total slob but I've never considered myself anything more than average-looking, and I've certainly never been told that I'm hot or that I should consider a career in modelling.
What tricks can I apply to make myself as gorgeous as Elon Musk?
What tricks can I apply to make myself as gorgeous as Elon Musk?
I haven't read it yet, but looked at the headline and debated if it was related to the FAT file system and there was a language called short.
I'm still interested in why engineers who know FAT should be valued more. It seems like an interesting thing to look up
I'm still interested in why engineers who know FAT should be valued more. It seems like an interesting thing to look up
Here’s a hot take on that front: “ The well-known association between height and earnings is often thought to reflect factors such as self esteem, social dominance, and discrimination. We offer a simpler explanation: height is positively associated with cognitive ability, which is rewarded in the labor market.” https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2709415/
The issue with that theory is that height is significantly more correlated with labor market outcomes for men than for women. Naive models of what you're suggesting (where e.g. negative gestational or early environmental influences are correlated with disrupted height growth and cognitive abilities) would result in men and women both showing the correlation.
A secondary point is that a correlation between height and cognitive ability existing in a world where children suffer poverty/malnutrition/exposure to lead does not imply that a correlation between height and cognitive ability exists in a world without that suffering, so studies using data from the 50s and 70s might have limited relevance for the present day.
A secondary point is that a correlation between height and cognitive ability existing in a world where children suffer poverty/malnutrition/exposure to lead does not imply that a correlation between height and cognitive ability exists in a world without that suffering, so studies using data from the 50s and 70s might have limited relevance for the present day.
> The issue with that theory is that height is significantly more correlated with labor market outcomes for men than for women.
How about cognitive abilities? You'd need to state that there is no (or less) difference in those between the two genders in order for this to be a valid counter argument.
> correlation between height and cognitive ability existing in a world where children suffer poverty/malnutrition/exposure to lead does not imply
The paper uses UK and US data.
How about cognitive abilities? You'd need to state that there is no (or less) difference in those between the two genders in order for this to be a valid counter argument.
> correlation between height and cognitive ability existing in a world where children suffer poverty/malnutrition/exposure to lead does not imply
The paper uses UK and US data.
That's almost certainly at least part of the explanation, if for no other reason than that height and cognitive development are both adversely impacted by some of the same environmental conditions from conception through childhood.
Now let's make the same argument but with race or gender. :/
I think it's definitely true that attractiveness indicators correlate with characteristics like intelligence. If you think about it, this shouldn't actually be that surprising; it would be silly if the factors that went into sexual selection had no correlation with survival-boosting traits.
Hm, perhaps I'm reasoning about this correctly, but wouldn't you think the opposite? Being attractive provides evolutionary slack that requires less optimization on other characteristics (like intelligence), and vice versa.
Being judged attractive is a cultural thing that varies with time and place.
Being judged intelligent is also a cultural thing that varies with time and place.
Unless your culture is static for 20+ generations, don't expect much influence of it on evolution.
Being judged intelligent is also a cultural thing that varies with time and place.
Unless your culture is static for 20+ generations, don't expect much influence of it on evolution.
There are attractiveness signifiers that are not culturally mediated (e.g. clear healthy skin is valued everywhere, extreme obesity or thinness is very rarely valued, being very short is very rarely valued, etc.)
Intelligence also seems to have plenty of culture-independent aspects.
Intelligence also seems to have plenty of culture-independent aspects.
> Being judged attractive is a cultural thing that varies with time and place.
This is partially true, but there are many significant markers of attractiveness that are not particularly context-dependent.
> Being judged intelligent is also a cultural thing that varies with time and place.
This I disagree with much more strongly. "Being judged intelligent" isn't explicitly isn't the only thing that feeds into the evolutionary drive, and the second-order consequences are much more significant: being quick-witted/funny, increasing likelihood of success/resources, etc. The concept of general intelligence is not nearly as narrowly-defined as you're implying. To take an example, subsistence farming isn't exactly _easy_. General intelligence is an important factor in success at subsistence farming just as it is in success at post-industrial white-collar work.
This is partially true, but there are many significant markers of attractiveness that are not particularly context-dependent.
> Being judged intelligent is also a cultural thing that varies with time and place.
This I disagree with much more strongly. "Being judged intelligent" isn't explicitly isn't the only thing that feeds into the evolutionary drive, and the second-order consequences are much more significant: being quick-witted/funny, increasing likelihood of success/resources, etc. The concept of general intelligence is not nearly as narrowly-defined as you're implying. To take an example, subsistence farming isn't exactly _easy_. General intelligence is an important factor in success at subsistence farming just as it is in success at post-industrial white-collar work.
No, I don't think this reasoning holds. What is intuitively considered attractive is itself an evolved trait, so as a meta-evolutionary strategy it almost certainly selects for otherwise desirable traits.
In this thread, "attractive" is being used as shorthand for "physically attractive": it was first introduced in response to a comment talking about height.
Also, while intelligence is per se attractive to some degree, it's also mediated through downstream effects like a higher likelihood of financial/resource success.
Also, while intelligence is per se attractive to some degree, it's also mediated through downstream effects like a higher likelihood of financial/resource success.
What's the correlation coefficient though? Attractiveness may only be weakly correlated with intelligence, in which case it isn't very meaningful.
came for hope - walked away disappointed.
And that’s true even more if they are bald and with a beard.
The balding greybeards are among the most respected engineers of my peers
But not necessarily when they apply for their next jobs, unfortunately
What?? Beards are discriminated against professionally?
I knew a senior software engineer who was in his 60s, who was short, fat (pot bellied), completely bald (or shaven), and had a large white beard.
He also used to ruffle the feathers of HR. Once, when a woman from the talent acquisition team tried to give him generic instructions about conducting interviews, he told her “Lady, I don’t need all this, I’ve been doing this since before you were born”. (She was born in the mid-80s.) She reported him to HR, and obviously they didn’t do anything, since he was one of the most valuable engineers at the company.
He had a great breadth of knowledge and experience, and was really good at what he did.
So what you’re stating doesn’t necessarily always hold true.
He also used to ruffle the feathers of HR. Once, when a woman from the talent acquisition team tried to give him generic instructions about conducting interviews, he told her “Lady, I don’t need all this, I’ve been doing this since before you were born”. (She was born in the mid-80s.) She reported him to HR, and obviously they didn’t do anything, since he was one of the most valuable engineers at the company.
He had a great breadth of knowledge and experience, and was really good at what he did.
So what you’re stating doesn’t necessarily always hold true.
Sometimes when people refuse to learn something new because they think they know better they are right, and sometimes they are wrong. Sadly it is difficult to know in which of these group you are, so it might be a good hedge not to refuse to listen to the young people. Even the most knowledgeable engineer can become a net negative quite easily.
Hubris right? Gets you twice, every time.
[deleted]
Some clicking on google scholar shows academic literature supports the claim at least with regard to height. Maybe someone can find similar articles with weight (I couldn't find anything)
https://psycnet.apa.org/buy/2004-95165-004
https://link.springer.com/article/10.1007/BF00288309
https://psycnet.apa.org/buy/2004-95165-004
https://link.springer.com/article/10.1007/BF00288309
I'd agree if its most other jobs but I thought devs were one job where appearance doesn't matter as much?
[deleted]
thatsthejoke.png
well, yeah, all engineers are under valued
one could devil's advocate speculate the other way as well; e.g. If IQ declines with age, and exercise is a way to slow the decline[1], fatness could reflect lack of exercise and lifestyle which doesn't prioritise exercise, so would you expect to see lower value for fatter engineers in a pure meritocracy?
If lower IQ correlates with obesity ("a 10‐point decrease in IQ was associated with a 1.10‐fold increase in the odds for obesity."[2]) either way - a lower IQ person is more likely to get fat, or the metabolic changes of getting fat negatively affect cognition as well - over a large group of skilled people would you expect thinner people to earn more?
If height and IQ are correlated ("Taller people tend to be smarter. Although the relationship is modest, height and IQ are consistently correlated at ∼.10–.20"[3]), would, etc.
[1] https://www.mdedge.com/neurology/article/193699/alzheimers-c...
[2] https://onlinelibrary.wiley.com/doi/10.1002/lim2.11
[3] https://journals.plos.org/plosgenetics/article?id=10.1371/jo...
If lower IQ correlates with obesity ("a 10‐point decrease in IQ was associated with a 1.10‐fold increase in the odds for obesity."[2]) either way - a lower IQ person is more likely to get fat, or the metabolic changes of getting fat negatively affect cognition as well - over a large group of skilled people would you expect thinner people to earn more?
If height and IQ are correlated ("Taller people tend to be smarter. Although the relationship is modest, height and IQ are consistently correlated at ∼.10–.20"[3]), would, etc.
[1] https://www.mdedge.com/neurology/article/193699/alzheimers-c...
[2] https://onlinelibrary.wiley.com/doi/10.1002/lim2.11
[3] https://journals.plos.org/plosgenetics/article?id=10.1371/jo...
> If IQ declines with age,
IQ doesn't decline with age. Pretty simply because IQ is deliberately determined in an age agnostic way: your IQ score tells how well your problem solving skills are compared to your age group.
Fluid intelligence does decline with age, but most people are said to be able to keep up fairly decently by utilizing (and building) crystalized intelligence. Now, of course, your usefulness as an engineer may very well decline with age. Though there are different roles that you can take on in most organizations. It's anecdotal, but my mother used to be a software engineer until her retirement in her sixties, as well as her colleagues she used to work with when I was a child. They started their careers in the 70s and 80s and most of them never left the field.
IQ doesn't decline with age. Pretty simply because IQ is deliberately determined in an age agnostic way: your IQ score tells how well your problem solving skills are compared to your age group.
Fluid intelligence does decline with age, but most people are said to be able to keep up fairly decently by utilizing (and building) crystalized intelligence. Now, of course, your usefulness as an engineer may very well decline with age. Though there are different roles that you can take on in most organizations. It's anecdotal, but my mother used to be a software engineer until her retirement in her sixties, as well as her colleagues she used to work with when I was a child. They started their careers in the 70s and 80s and most of them never left the field.
Maybe revisit that comment in your mid 40s or 50s.
Up until around age 35 or so, I was generally very lean and did not get noticably fat regardless of my lifestyle.
I know I haven't gotten any stupider. Hormonal changes are the most likely difference for me.
Up until around age 35 or so, I was generally very lean and did not get noticably fat regardless of my lifestyle.
I know I haven't gotten any stupider. Hormonal changes are the most likely difference for me.
What difference does it make whether I am in the described groups or not? You can argue that IQ doesn't exist, or shouldn't affect engineer value, or that the correlations don't exist, but telling the author "you won't like it when it happens to you, so agree it doesn't exist" is weird.
> "Up until around age 35 or so, I was generally very lean and did not get noticably fat regardless of my lifestyle."
It's tempting to read this as saying "I didn't choose it to happen, so I'm excused from any negative effects", although that would be taking a negative view on it. But if not that, what else is this sentence here for? Maybe you're saying that there's more to fat than lifestyle - then skim read "Ten Putative Contributors to the Obesity Epidemic"[1] (PDF or online PDF) where they discuss things like viral infections, environmental triggers, socieo-economic contributers, and other things which aren't diet or exercise related. Does any of that change whether obesity does or doesn't correlate with IQ? Or maybe you're saying you got fat despite exercising - which only says exercise didn't save you, it doesn't need to change whether IQ and obesity are correlated or not. Plus exercise was suggested as a counter to age related decline, not as a counter to fat, only as a thing people might think when seeing fat.
> "I know I haven't gotten any stupider."
Who ever thinks they have? Would you honestly know? You ought to have lost some abilities just going from age 35 to 55 alone. See[2]: "Age and individual productivity: a literature survey" - "The ability levels of employed white men and women up to the age of 65, using data from the General Aptitude Test Battery collected in the U.S. from 1970-1984, is shown in Figure 2. These findings suggest a relatively sharp decline in most abilities, after maximum values are reached in the 20s and early 30s (Avolio and Waldman 1994). The decline of mental abilities from early adulthood is a universal phenomenon. The age-induced changes in cognitive abilities are similar across countries and within population subgroups, such as between men and women (Park et al. 1999, Maitland et al. 2000). Further individuals with high and low ability levels are subject to the same age-induced changes in cognitive functioning (Deary et al. 2000). Even among non-human species, ranging from fruit flies to primates, age-reductions in memory and learning capabilities have been observed (Minois and Bourg 1997, Bunk 2000)."
[1] https://www.researchgate.net/publication/40447388_Ten_Putati...
[2] https://www.demogr.mpg.de/papers/working/wp-2003-028.pdf
> "Up until around age 35 or so, I was generally very lean and did not get noticably fat regardless of my lifestyle."
It's tempting to read this as saying "I didn't choose it to happen, so I'm excused from any negative effects", although that would be taking a negative view on it. But if not that, what else is this sentence here for? Maybe you're saying that there's more to fat than lifestyle - then skim read "Ten Putative Contributors to the Obesity Epidemic"[1] (PDF or online PDF) where they discuss things like viral infections, environmental triggers, socieo-economic contributers, and other things which aren't diet or exercise related. Does any of that change whether obesity does or doesn't correlate with IQ? Or maybe you're saying you got fat despite exercising - which only says exercise didn't save you, it doesn't need to change whether IQ and obesity are correlated or not. Plus exercise was suggested as a counter to age related decline, not as a counter to fat, only as a thing people might think when seeing fat.
> "I know I haven't gotten any stupider."
Who ever thinks they have? Would you honestly know? You ought to have lost some abilities just going from age 35 to 55 alone. See[2]: "Age and individual productivity: a literature survey" - "The ability levels of employed white men and women up to the age of 65, using data from the General Aptitude Test Battery collected in the U.S. from 1970-1984, is shown in Figure 2. These findings suggest a relatively sharp decline in most abilities, after maximum values are reached in the 20s and early 30s (Avolio and Waldman 1994). The decline of mental abilities from early adulthood is a universal phenomenon. The age-induced changes in cognitive abilities are similar across countries and within population subgroups, such as between men and women (Park et al. 1999, Maitland et al. 2000). Further individuals with high and low ability levels are subject to the same age-induced changes in cognitive functioning (Deary et al. 2000). Even among non-human species, ranging from fruit flies to primates, age-reductions in memory and learning capabilities have been observed (Minois and Bourg 1997, Bunk 2000)."
[1] https://www.researchgate.net/publication/40447388_Ten_Putati...
[2] https://www.demogr.mpg.de/papers/working/wp-2003-028.pdf
In my career, I have met exactly one short fat engineer with >5yrs of exp that I was impressed by. That person is now a Product Manager at a FAANG company (albeit PM-ing highly technical stuff).
I bring this up because I think there is a very good analogy to the point that the author is making and the distinction between PM and Engineers. Broadly put, PM's are good at figuring out the theta, and Engineers are good at the r.
I think that with the perspectives that short fat engineers have, they can play enormous roles as "PM" or "Engineering Manager", and definitely as ICs during early stages of startups. But they clearly don't enjoy depth, and this can be counter-productive for that 1% of the time where you really, really want depth.
I don't buy the knowledge vs wisdom thing though, there's plenty of wisdom to be gained from going deep into a subject. I'd actually claim that wisdom can only come from depth - though what depth means is different for different roles.
I bring this up because I think there is a very good analogy to the point that the author is making and the distinction between PM and Engineers. Broadly put, PM's are good at figuring out the theta, and Engineers are good at the r.
I think that with the perspectives that short fat engineers have, they can play enormous roles as "PM" or "Engineering Manager", and definitely as ICs during early stages of startups. But they clearly don't enjoy depth, and this can be counter-productive for that 1% of the time where you really, really want depth.
I don't buy the knowledge vs wisdom thing though, there's plenty of wisdom to be gained from going deep into a subject. I'd actually claim that wisdom can only come from depth - though what depth means is different for different roles.
If you're a "short and fat" engineer, and you know it, it's very hard to stay that way, and also stay in engineering. Either you become a T-shaped engineer, or you move out of engineering to apply your broad-but-shallow knowledge in ways that elevate others (e.g. PM work).
"Short and fat" is a transitionary state. Staying there is just logistically hard, not to mention handicapping in situations where being deeper in one specific area would help.
"Short and fat" is a transitionary state. Staying there is just logistically hard, not to mention handicapping in situations where being deeper in one specific area would help.
>met exactly one short fat engineer with >5yrs of exp that I was impressed by
I'll go so far as to say that they don't really exist. I'm not sure how you can spend 5 years and not learn at least one thing in depth. You'd have to rotate technologies every 6-12 months and there's not that many technologies.
I'll go so far as to say that they don't really exist. I'm not sure how you can spend 5 years and not learn at least one thing in depth. You'd have to rotate technologies every 6-12 months and there's not that many technologies.
> I'm not sure how you can spend 5 years and not learn at least one thing in depth. You'd have to rotate technologies every 6-12 months and there's not that many technologies.
That's kinda how SV is these days though. It's very common for engineers to jump companies every 1-2 years for a long period of time and the companies very frequently undergo a shift in technologies while engineers are there. So, unless you join FAANG or some super stable company - I could see it being natural from just how the market works that you end up having a very short fat engineering career.
For myself, the only consistent thing from my five jobs over the last 7-8 years is that they've all had JavaScript (actually - one had CoffeeScript but then we migrated to JavaScript when I was leaving) - but that's mostly just because of the nature of web development. In the middle of my sixth job search right now and it's looking to be a backend role that won't be in JS now. So, there goes that stability...
Personally: fullstack LAMP -> fullstack Python + Django -> frontend role with backbone/knockout/angular and majority of vanilla JS and CSS -> fullstack Python + Django + CoffeeScript -> Fullstack Angular + Node -> Backend Node with shift to TypeScript near the end
That's kinda how SV is these days though. It's very common for engineers to jump companies every 1-2 years for a long period of time and the companies very frequently undergo a shift in technologies while engineers are there. So, unless you join FAANG or some super stable company - I could see it being natural from just how the market works that you end up having a very short fat engineering career.
For myself, the only consistent thing from my five jobs over the last 7-8 years is that they've all had JavaScript (actually - one had CoffeeScript but then we migrated to JavaScript when I was leaving) - but that's mostly just because of the nature of web development. In the middle of my sixth job search right now and it's looking to be a backend role that won't be in JS now. So, there goes that stability...
Personally: fullstack LAMP -> fullstack Python + Django -> frontend role with backbone/knockout/angular and majority of vanilla JS and CSS -> fullstack Python + Django + CoffeeScript -> Fullstack Angular + Node -> Backend Node with shift to TypeScript near the end
You wouldn't say you have deep knowledge of JS & front end frameworks?
Nope. My frontend knowledge has disappeared in the last year as I've done almost all backend. My knowledge of JS is enough to get the job done but deep knowledge? How could it be - I'm constantly building products, not toying with the minute of performance optimization or creating some impressively large framework. The stuff I do is extremely lean and relies very little on language nuances. The stuff I do could be done easily in many languages - it just happened to be in JS a lot of the time.
What do you classify as deep? I feel comfortable with JS and have a vague understanding of the internals of front end frameworks, but I wouldn't consider myself to have deep knowledge of either.
It's relative to your other skills. If you were a novice at everything and intermediate at JS then that's the trunk of your T.
On the spectrum from compilers to machine learning to frontend, there are plenty of technologies.
I could imagine it happening, if you've worked as a contractor on 12-18 month gigs per company for the last 5 years, testing things out and getting a feel for what areas you like to work in the most.
>PM's are good at figuring out the theta, and Engineers are good at the r.
I'm only familar with the options definition of theta and the reproductive strategy of r. Could you expand? Something like, PM's are good at long term (e.g. our product needs this feature, then this feature) and Engineers are good at fine detail (e.g. the feature should work like this)?
I'm only familar with the options definition of theta and the reproductive strategy of r. Could you expand? Something like, PM's are good at long term (e.g. our product needs this feature, then this feature) and Engineers are good at fine detail (e.g. the feature should work like this)?
Theta is the angle, r is the radius.
Thus PMs are good at figuring out in what direction to concentrate their effort, and then the engineers make progress in that direction. That's how I interpreted it at least.
Thus PMs are good at figuring out in what direction to concentrate their effort, and then the engineers make progress in that direction. That's how I interpreted it at least.
Aha, thank you! I understand that as similar to what I tried to articular.
[deleted]
I spent 7 years in product before making the transition to being a developer 2 years ago. I've successfully made the jump but definitely had hoped I'd be in a better position than I am now. Obviously this could be me, but I have been pretty surprised how companies/startups seems disinterested in my PM past. I think it certainly gave me a broad perspective on how to ship software customers love, and how successful teams work. It likely is still my inexperience but nonetheless no one seems to care about broad knowledge.
I don't think it's your inexperience. I have found most people don't care if you know something else well that's outside the remit of your current role. Some are actively threatened by it.
I also switched careers 10 years ago. I have found that having this broad experience has helped me to make better decisions, understand different points of view and to work with others better.
But I usually have no ability to directly apply the experience from my first career, and very few organisations would ever want or allow me to. It's a pleasure when I can, but it's rare.
I also switched careers 10 years ago. I have found that having this broad experience has helped me to make better decisions, understand different points of view and to work with others better.
But I usually have no ability to directly apply the experience from my first career, and very few organisations would ever want or allow me to. It's a pleasure when I can, but it's rare.
I have been working for around 5 years now and haven't stuck to one programming language or framework more than 1-2 years. Not enough to an expert in any of them. Started from c#, than some web, than cpp and some Java, than some DevOps and now full time Java. Been doing Javascript along with out of interest only.
When I tell my friends how I feel about my knowledge and expertise they say I am only suffering from imposter syndrome. May be with more years I do become really good at one or two things.
When I tell my friends how I feel about my knowledge and expertise they say I am only suffering from imposter syndrome. May be with more years I do become really good at one or two things.
I am more of a square than an I, T, or Fat I. I have vast knowledge about a lot of stuff. I am very knowledgeable about every engineering aspect of my field (video games) and can be integrated and lead any team in the stack.
Cool
None of these things exist. A taxonomy of three kinds is entirely inadequate to describe the potential of anyone working today. These sorts of quick fix mental models are pretty poisonous. There are literally recommendations for all three saying how useful they are. This is some of the dumbest snake oil to infect software development.
All these sorts of things were cooked up in the depths of some HR department somewhere, likely by people who fundamentally don't understand technical skillsets. They provide some level of false utility by allowing people to compartmentalize otherwise highly complex systems (knowledge sets) into simple ideas.
Skillsets are highly complex assemblies that can't be summed up or generalized. Doing things like that give us the hilariously misguided strategies that make HR folks hand out Myers Briggs tests for culture fit checks. I know for myself that a lot of my skills are actually just fancy applications of thought processes and theory, expressed in code. Trying to box that into this goofy trichotomy will just confuse someone.
Skillsets are highly complex assemblies that can't be summed up or generalized. Doing things like that give us the hilariously misguided strategies that make HR folks hand out Myers Briggs tests for culture fit checks. I know for myself that a lot of my skills are actually just fancy applications of thought processes and theory, expressed in code. Trying to box that into this goofy trichotomy will just confuse someone.
The point isn't a taxonomy of 3 types but the layout in two axes - breadth and depth of expertise. Those are quite real and useful to think about when considering hiring or your own career development.
Right but no one actually measures what real distributions look like. They just invent some shapes with stories attached they like. Then the misguided try to lump people into them.
When I was younger I used to say that I was a jack of all trades, master of none. Many years later I feel like a jack of all trades, master of many. I no longer fit any of the profiles presented here.
I too have a broken comb profile. Every now an then I get to have some fun and add or extend a few teeth. But for the most part the skills let me work through most tangles pretty well.
Aah, I was looking for a word to describe this shape!
It's also what I consider myself. It's basically the result of being a generalist who is also willing to dive deep in order to solve a problem rather than stackoverflow my way to a workaround.
"Key-shaped" might be another word here, for someone who does have an area of focus, but not as extreme as a T shape. For example, someone who does full stack web dev with a frontend specialty, but not so focused on one particular frontend framework.
It's also what I consider myself. It's basically the result of being a generalist who is also willing to dive deep in order to solve a problem rather than stackoverflow my way to a workaround.
"Key-shaped" might be another word here, for someone who does have an area of focus, but not as extreme as a T shape. For example, someone who does full stack web dev with a frontend specialty, but not so focused on one particular frontend framework.
Its interesting that a history of doing hard things is less important than it once was at interview time. You still have to prove that you can do hard things.
I feel like 20 min coding exercises of today are nearly completely inadequate tools for proving if a candidate can do hard things.
The problem is, while I love my story of figuring out xmlhttprequest (before it was called ajax) in IE5 so I could rebuild our refresher frame to not refresh anymore because Windows had unexpectedly introduced a clicking sound for every page navigation and our application was now clicking every second driving our customers crazy, that situation will never come up again.
Every day, the specifics of tech experience matter less, and they reduce to "merely" signals of creativity, tenacity, etc.
Every day, the specifics of tech experience matter less, and they reduce to "merely" signals of creativity, tenacity, etc.
Perhaps this is because many problems are fundamentally the same. Understand the requirements, research the tools, combine the tools in a clean architecture, ...
And the more tools you have used the quicker you can figure out new ones, at least for what you need.
And the more tools you have used the quicker you can figure out new ones, at least for what you need.
That's called being old. Generally considered out of date, unable to learn new stuff :-)
Yet, always held a job, so far never part of a layoff, still pulling my weight. If you are not constantly learning then you are falling behind. The biggest differences from my younger days are more distractions in my personal life (family), and I make better decisions than I once did.
It depends, if your "master of many" list is all old technologies, or all new technologies.
How about the newest version of an old technology
I mean, all that really matters is if your list of technologies matches up with what the company currently uses and what they would aspirationally like to use in the future.
I’ve heard it called “paint drip” since you have a broad scope, with a lot of various length depth lines.
I feel very funnel/inverse-triangle shaped.
"Junior in every department" really struck hard for me.
I know just enough of basically everything to get by or as a starting point, but I lack that really deep knowledge that comes from using a small group of skills and tools for years. I feel that switching languages and frameworks and tools and OSes a bunch of times early in my career has really held me back.
I don't mind supporting my team, what I don't like is how companies will structure an entire team as support around one or two people. I am not a rock star but I am still capable of contributing more than "support". I want to build real features.
Especially when I know I'm capable of doing the things those devs do, just maybe not at the speed they do.
I know just enough of basically everything to get by or as a starting point, but I lack that really deep knowledge that comes from using a small group of skills and tools for years. I feel that switching languages and frameworks and tools and OSes a bunch of times early in my career has really held me back.
I don't mind supporting my team, what I don't like is how companies will structure an entire team as support around one or two people. I am not a rock star but I am still capable of contributing more than "support". I want to build real features.
Especially when I know I'm capable of doing the things those devs do, just maybe not at the speed they do.
I’m in a similar position, albeit mostly because even though my professional career has been predominantly one stack, there’s just no real chance to ever really get to learn the ecosystem. Most of the work hasn’t called for me learning much of an ecosystem, especially since in very bureaucratic environment, a lot of it is simply delegated to someone else.
I often half joke about how I don’t know any programming languages which is unfortunately kinda of true. I’ve toyed with a lot of languages, including ones that your average developer may not have even heard of, but at the end of the day it’s just toying.
I often half joke about how I don’t know any programming languages which is unfortunately kinda of true. I’ve toyed with a lot of languages, including ones that your average developer may not have even heard of, but at the end of the day it’s just toying.
I'm in the opposite position; I've spent almost my entire five-year career focusing on one quite narrow tech stack and I'm good at it but I'm also sick of it and desperate to learn something new. I just changed jobs and I took a substantial pay cut for the chance to get professional experience in a new tech stack, which isn't ideal, but I really want to work with a new language and I don't know what else to do (there was no possibility of diversifying at my previous position.)
My point is that both the "short and fat" and "spikey" approaches have their pros and cons.
My point is that both the "short and fat" and "spikey" approaches have their pros and cons.
I have also been working on different tech throughout my career. Do you suffer from imposter syndrome because of this? I often feel like I don't know as much as my peers do. I can't do things that quickly. I am in a very good workplace now where my manager appreciates my work. But most of the times I feel I am not contributing like others. I don't even understand that much.
Yes, I sometime have a strong doubt of my abilities. You're not alone in that.
How big a team are you working in? In most places I've worked the teams (or company) were small enough that even new hires would get a change to work on something big if they have the capacity.
I have basically always been on teams of 5 devs.
Maintaining legacy stuff.
Maintaining legacy stuff.
"Junior" is not the same as "fat & short". It puts stigma onto you (no experience, green) and your capabilities (needs guidance, possibly bad judgment) which is certainly unfounded after working several years in the industry, no matter how niche your stack was. Switching technologies does not make you a "Junior" when you have loads of war stories to tell.
Is it really true?
A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
> Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
This is what DevOps is _supposed_ to be but often not what "DevOps Engineers" are hired to be. In my experience most companies hire DevOps Engineers that are one of two things:
1) Sysadmins that also know Python and whichever public cloud dominates the vertical the company operates in
2) Developers that don't actually develop but spend all of their time managing CI/CD pipelines, SCM, JIRA, etc.
In either case their roles are obviously secondary to the developers that build actual solutions; they are the mechanics for the software engineers, which inherently means that their contribution to the value stream is not holistic and it's just another way of enforcing the traditional dichotomy between people that build solutions (developers) and people that keep them from falling over (operations).
I've held the title of "DevOps Engineer" at least once professionally and when I would talk to recruiters or new employers about a software engineering position they'd often ask me what "got me into DevOps" or why I'm trying to "get back into coding". If you know and like working with dev tools and infrastructure then my advice to you is to be a Software Engineer that does DevOps, not a "DevOps Engineer".
This is what DevOps is _supposed_ to be but often not what "DevOps Engineers" are hired to be. In my experience most companies hire DevOps Engineers that are one of two things:
1) Sysadmins that also know Python and whichever public cloud dominates the vertical the company operates in
2) Developers that don't actually develop but spend all of their time managing CI/CD pipelines, SCM, JIRA, etc.
In either case their roles are obviously secondary to the developers that build actual solutions; they are the mechanics for the software engineers, which inherently means that their contribution to the value stream is not holistic and it's just another way of enforcing the traditional dichotomy between people that build solutions (developers) and people that keep them from falling over (operations).
I've held the title of "DevOps Engineer" at least once professionally and when I would talk to recruiters or new employers about a software engineering position they'd often ask me what "got me into DevOps" or why I'm trying to "get back into coding". If you know and like working with dev tools and infrastructure then my advice to you is to be a Software Engineer that does DevOps, not a "DevOps Engineer".
Some would see this as a cynical take, but I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps; seems no one but the most highest of highly functioning teams seem to grok it. Wonder if that makes me a cynic. Would a cynic admit to being a cynic? Probably.
Anyway.
Nice little coincidence seeing your comment suggesting exactly the same thing. Of course, google just calls those people “SREs”...which in the best of worlds is a “Site Reliability Engineer”, in past orgs though it’s really meant “Sometimes Responsible for Everything”
Anyway.
Nice little coincidence seeing your comment suggesting exactly the same thing. Of course, google just calls those people “SREs”...which in the best of worlds is a “Site Reliability Engineer”, in past orgs though it’s really meant “Sometimes Responsible for Everything”
I don't think it's cynical at all... it's just an unfortunate reality. New things come along and people try to fit them into existing frameworks. Words' meanings evolve over time. People that don't actually do technical work often end up being responsible for placing and managing the people that do; sometimes their notions of roles and responsibilities don't align with ours.
> I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps
I, too, am glad to see that I'm not the only one that's had this experience. I wish you the best of luck in "breaking the cycle". Hang tough!
> I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps
I, too, am glad to see that I'm not the only one that's had this experience. I wish you the best of luck in "breaking the cycle". Hang tough!
I appreciate that. Best of luck to you as well.
"Full stack" (for whatever definition) is valued because it cuts down on coordination costs, but you may run into limits of what you can expect one person to know. Interestingly, as I've had to hire some "skinny" specialists, my Kanban board has gotten wider to coordinate between them.
Jquery is horrible for many reasons.
But it made it easy to be a full stack developer.
Things are far more challenging these days.
Things are far more challenging these days.
Agree - most job postings I see call for experience with an ever-increasing number of disparate technologies. And full-stack web development necessitates it until you've grown the team to a large size.
yes it's true. as someone who's a generalist, every interview I've been to asks me very specific things about one programming language / tech stack. Even though I'm underpaid, I enjoy continuing doing my "short fat" engineering at my current job getting to touch many technologies and focusing on solving the problems at hand rather than specializing in one.
Do "height on demand". Constant abstract and compress the knowledge so you can ramp up in any area as needed.
Really, this is why programming languages are my "home base" of expertise. It's the study of formal ideas and their communication.
Really, this is why programming languages are my "home base" of expertise. It's the study of formal ideas and their communication.
Interesting to see someone else with the same base and thoughts on it, and I'd highly recommend it! At a lower level, I've found a PL/Compilers background lets me switch/pick up languages quickly often and also helps even finding quirks as you can often guesstimate where the bodies are buried from design choices of the language. Also very helpful for architect type roles where you're picking what technologies to build on, consulting experts when needed.
I think the idea of "you have to spend years and years to know the internals of X" is a bit flawed - you can get quite a good feel in ~6 months that's not equivalent but not terribly far off. If you do "height on demand" for long enough, you end up with a good number of these. As someone called it, a "comb" engineer, if you will.
I think the idea of "you have to spend years and years to know the internals of X" is a bit flawed - you can get quite a good feel in ~6 months that's not equivalent but not terribly far off. If you do "height on demand" for long enough, you end up with a good number of these. As someone called it, a "comb" engineer, if you will.
I feel like the 80/20 rule applies here. For most things you can probably learn 80% of the knowledge in 20% of the time it would take to learn 100%.
This is also the strategy I tend to take. Strong, broad fundamentals so I can quickly pick up specifics on the job.
IMHO, I just don't buy this. Every piece of technology has its own set of quirks, pitfalls, and shortcuts. You can jump around from Rails to Spring to iOS to whatever and be a decent individual contributor. But to be a real Senior/Lead engineer that can be responsible for a project you've gotta have the in depth knowledge.
- If you become senior manager of an existing project, learn from the rest of the team!
- If you end senior manager of a new project, you probably shouldn't also be new at the company period, but at the very least, you start with something there is expertise somewhere on the team on.
- New tech, new team, new org all at once: that's a terrible idea. The project shouldn't happen, or you shouldn't be the sole senior manager on it.
All that said, if we have some team continuity across the industry, that should allow enough on boarding time for everyone to a be a non-pidgeonholed generalist. Just because there are derivative bounds doesn't mean we can't abandon change and pigeon-hole people in myopic specialist roles.
- If you end senior manager of a new project, you probably shouldn't also be new at the company period, but at the very least, you start with something there is expertise somewhere on the team on.
- New tech, new team, new org all at once: that's a terrible idea. The project shouldn't happen, or you shouldn't be the sole senior manager on it.
All that said, if we have some team continuity across the industry, that should allow enough on boarding time for everyone to a be a non-pidgeonholed generalist. Just because there are derivative bounds doesn't mean we can't abandon change and pigeon-hole people in myopic specialist roles.
Sure, but the time it takes to hit diminishing returns wrt different technologies seems greatly underrated to me. I've seen many engineers stick with a single technology so long that they were just memorizing standard libraries instead of actually learning anything.
This still restricts you from getting many of the jobs that require narrow specialization. Specializing on the fly only works to a certain extent and only if you get the opportunity to do so in the first place.
In my experience, "narrow" professionals tend to heavily overestimate what they bring to the table, which makes them not very hard to outcompete.
Switching technology is easy, switching domain is hard. You can't specialize in a technology, that is just nonsense, you specialize in a domain.
Or several domains if they are simple enough. Like, the typical needs of a web product are simple enough that you master how to do the database, back end and front end. You wont be able to do the back end or database at Google scale, but you can master doing them at typical scale and I'd actually argue that Google scale is a different domain entirely with a different set of skills, you need a different specialist to handle that problem and he wont be able to efficiently solve your small scale needs either.
Or several domains if they are simple enough. Like, the typical needs of a web product are simple enough that you master how to do the database, back end and front end. You wont be able to do the back end or database at Google scale, but you can master doing them at typical scale and I'd actually argue that Google scale is a different domain entirely with a different set of skills, you need a different specialist to handle that problem and he wont be able to efficiently solve your small scale needs either.
I think one person can understand the backend at google scale. You shouldn't LARP solving problems you don't actually have (it's stupid to pay those costs, especially when the google state of the art isn't really that good) but you can still understand it.
- Modern hardware realities (nearby network faster than disk they say, memory of all sort slow relative to CPU). My mental model is the good ol' hydrolic analogy, but with molasses. Wires are slow, components are hardly slower. Flash is slower still. Maybe also think of the machines being close relative to length of wires in CPU and mollases properties.
- DB arch and similar. Well, if everything is molasses synchronizations is clearly hard. Rather than think about nifty hacks in isolation, think about what is the "business logic"'s actual expectations of synchronization. Remember financial settlement is the original example solution for this sort of thing, long predating computers.
- Modern hardware realities (nearby network faster than disk they say, memory of all sort slow relative to CPU). My mental model is the good ol' hydrolic analogy, but with molasses. Wires are slow, components are hardly slower. Flash is slower still. Maybe also think of the machines being close relative to length of wires in CPU and mollases properties.
- DB arch and similar. Well, if everything is molasses synchronizations is clearly hard. Rather than think about nifty hacks in isolation, think about what is the "business logic"'s actual expectations of synchronization. Remember financial settlement is the original example solution for this sort of thing, long predating computers.
> Constant abstract and compress
can you expand on this? i feel like i do this but not quite sure what you mean
can you expand on this? i feel like i do this but not quite sure what you mean
Well, taken to the limit, something like https://ncatlab.org/nlab . (I do endorse, but am no category theory wise by any stretch of the imagination.)
By default being extremely skeptical of all things computing related, and general being dour about the mainstream trends also helps. Skepticism is what allows separating the accidental and essential complexity, as some term it. Only learn the essential parts.
By default being extremely skeptical of all things computing related, and general being dour about the mainstream trends also helps. Skepticism is what allows separating the accidental and essential complexity, as some term it. Only learn the essential parts.
I read some of the introductory pages such as their perspective, but unfortunately, I think this is mostly beyond my level of comprehension.
I don't really get category theory in layman terms.
However, it does seem like this is really powerful for whomever understands and adopts it.
I don't really get category theory in layman terms.
However, it does seem like this is really powerful for whomever understands and adopts it.
The point that "on a long enough time line, wisdom is always more valuable than knowledge" is pretty irrelevant to tech companies. They hire engineers to get stuff done quickly - not slowly gather "wisdom". The average tenure at a tech company continues to be a few years.
Also, I've noticed that entry-to-mid level jobs are great for "short and fat" engineers, but once you start aiming for senior (or higher) level IC positions, job interviews require you to be an expert in whatever field the position you’re interviewing for is in. If you stay "short and fat", you're setting your career trajectory up for failure.
I tend to see a lot of highly promoted "short and fat" principal engineers and other internal thought leaders who lack depth. In fact the career path seems to top out if you prefer being an expert in something rather than jack of all trades and able to talk about any subject.
I suspect they don't lack depth so much as have depth in other technologies which aren't used. If they don't want to stay on the treadmill of building expertise in the next new thing, then they move up to jobs based on the wisdom they have accumulated instead.
I have also seen a lot of people hired in at high pay due to their laser-like career focus and years of experience in just the right area, who turned out to embody the peter principle. They lacked the brains and creativity to do anything new and still get stuck when a new twist comes up. Meanwhile I know generalists who are great at figuring things out, and got bored when they had more or less mastered the technology so them move on to a new challenge.
I have also seen a lot of people hired in at high pay due to their laser-like career focus and years of experience in just the right area, who turned out to embody the peter principle. They lacked the brains and creativity to do anything new and still get stuck when a new twist comes up. Meanwhile I know generalists who are great at figuring things out, and got bored when they had more or less mastered the technology so them move on to a new challenge.
> If you stay "short and fat", you're setting your career trajectory up for failure.
Is staying short and fat really an option? Aren't you always specialising in the problem domain / tech stack that you're currently working with?
Is staying short and fat really an option? Aren't you always specialising in the problem domain / tech stack that you're currently working with?
Not if you keep switching teams or companies every few years into something new.
Gotta laugh at the HN definition of "failure". Plenty of "short and fat" jobs provide a good career. Not everyone wants or needs anything else.
Gotta laugh at your definition of "good career". Plenty of "short and fat" jobs provide relatively failed career. Not everyone wants or needs anything else.
This falls victim to the fallacy that everybody has a fixed number of points to allocate across skills. To torture the analogy, the reality is some people are huge squares and some are tiny slivers. Or a fat fork or some other weird shape. Basically, some people are just better than you at everything.
The other thing is that you often just need problem solvers where it doesn’t even matter how wide their experience is. You just need someone who knows the basics and is adaptable.
The other thing is that you often just need problem solvers where it doesn’t even matter how wide their experience is. You just need someone who knows the basics and is adaptable.
> Both dimensions can be useful; but breadth gives us perspective, and thus wisdom
No, it really doesn't. If you haven't ever gone through the work required to become great at something then you lack that perspective completely. If you have gone through that journey at least once you start seeing that journey in other domains as well which gives you a lot of understanding about the field, about engineers, about what projects actually require etc. I really don't see how you can be considered wise without having seen that, not as a software engineer at least. Maybe you could be a great product manager though.
No, it really doesn't. If you haven't ever gone through the work required to become great at something then you lack that perspective completely. If you have gone through that journey at least once you start seeing that journey in other domains as well which gives you a lot of understanding about the field, about engineers, about what projects actually require etc. I really don't see how you can be considered wise without having seen that, not as a software engineer at least. Maybe you could be a great product manager though.
A friendly suggestion for the OP:
An uppercase theta should be used for "Big Θ time complexity" regarding algorithms but for angles like in the article, it should be the lowercase theta that looks like this: θ.
An uppercase theta should be used for "Big Θ time complexity" regarding algorithms but for angles like in the article, it should be the lowercase theta that looks like this: θ.
Wisdom comes from depth and breadth not breadth alone. That initial bolder claim was a major turn off for me. The “wisdom” you get from breadth is the same kind of “wisdom” you get from seeing a lot of faces go by on the street. It’s surface level, and mostly wrong.
Egads. The term is "generalist", and has been for decades.
No one would or should say "short & fat".
And yes, generalists are undervalued.
No one would or should say "short & fat".
And yes, generalists are undervalued.
Good "short fat engineers" are not undervalued at all, the reason they are not hired often is because they are the boss!
A wide profile is typically what you want as a boss/executive/entrepreneur. With technical knowledge but also artistic, legal, people and of course business skills. This is what you need to run a company. And as you reach your limits, you start to hire experts.
A wide profile is typically what you want as a boss/executive/entrepreneur. With technical knowledge but also artistic, legal, people and of course business skills. This is what you need to run a company. And as you reach your limits, you start to hire experts.
Exactly! At the bottom of the organization, your boss can be better than you on all dimensions. Towards the top, you are better than your boss at your job. It gets wider and wider, culminating in a CEO who is worse at tech than the CTO, worse at finance than the CFO, etc. At those levels, your actual skill is in driving experts to results.
Worst part is so many interview processes value skinny engineers who are tall enough to drop balls into 20 minute cs algorithm baskets.
Everyone should aim to be T-shaped. The problem with 'tall skinny' engineers is that they can be extremely dangerous because:
- Their deep domain knowledge makes them sound a lot smarter than they are... Especially to non tech-savvy managers who don't know better. So they can be extremely persuasive in arguments. They only participate in arguments that they can win but their ability to constantly win those niche arguments gives them extra general credibility which is not deserved.
- They are excellent at implementing solutions within their narrow area of expertise but they tend to miss a lot of alternative solutions which may have been better. They could spend years working on a solution whose problem could have been solved much faster and more elegantly via a different solution which happens to lie outside of that individual's immediate domain of expertise. People who wield absolute top-of-the-range, world-class hammers but have no other tool in their toolbox have a very strong incentive to see and portray every problem as a nail.
- Their deep domain knowledge makes them sound a lot smarter than they are... Especially to non tech-savvy managers who don't know better. So they can be extremely persuasive in arguments. They only participate in arguments that they can win but their ability to constantly win those niche arguments gives them extra general credibility which is not deserved.
- They are excellent at implementing solutions within their narrow area of expertise but they tend to miss a lot of alternative solutions which may have been better. They could spend years working on a solution whose problem could have been solved much faster and more elegantly via a different solution which happens to lie outside of that individual's immediate domain of expertise. People who wield absolute top-of-the-range, world-class hammers but have no other tool in their toolbox have a very strong incentive to see and portray every problem as a nail.
And what about us short, skinny engineers? I guess we're just happy to be here.
Looking at the author's background, it's easier to say generalists are undervalued when you're a freelancer/agency - you kind of have the freedom to work on projects for 3-6 months, punt them, and move on to the next.
When you're a bigger product organization, more specialized approaches can work better since you're better suited to find the right trade-off of "speed" vs "future-proofness".
This can backfire too though - many specialists can get lost in the weeds and over-engineer solutions that can cripple a business with maintenance costs simply because they want to increase their depth.
I think this entire contextualization is kind of ridiculous though. If you were to categorize short fat vs tall skinny vs T, you might see something like:
fullstack eng vs ML researcher vs backend engineer w/ ETL experience
The fact is that fullstacks _are_ utility players. I don't know that they're really at liberty to "take the helm" if they're not well-versed in the technology that differentiates the company (or team).
When you're a bigger product organization, more specialized approaches can work better since you're better suited to find the right trade-off of "speed" vs "future-proofness".
This can backfire too though - many specialists can get lost in the weeds and over-engineer solutions that can cripple a business with maintenance costs simply because they want to increase their depth.
I think this entire contextualization is kind of ridiculous though. If you were to categorize short fat vs tall skinny vs T, you might see something like:
fullstack eng vs ML researcher vs backend engineer w/ ETL experience
The fact is that fullstacks _are_ utility players. I don't know that they're really at liberty to "take the helm" if they're not well-versed in the technology that differentiates the company (or team).
The most successful engineers, to me, seem to be the ones who rise about the lower levels of technology and abstract out minor details.
They understand what the technology in question can do and cannot do. They know what other technologies can be paired and cannot be paired with the current one and they understand the performance, development, deployment and maintenance aspects of all the combinations.
They can then design applications or platforms, learning as they go.
Take, for example NodeJS. Ryan knows what V8 is capable of, knows what it's not capable of outside the browser sandbox, and built himself an alternate sandbox. The implementation details, while complex, are minor in the grand scheme of things.
They understand what the technology in question can do and cannot do. They know what other technologies can be paired and cannot be paired with the current one and they understand the performance, development, deployment and maintenance aspects of all the combinations.
They can then design applications or platforms, learning as they go.
Take, for example NodeJS. Ryan knows what V8 is capable of, knows what it's not capable of outside the browser sandbox, and built himself an alternate sandbox. The implementation details, while complex, are minor in the grand scheme of things.
I’ve always felt understanding the broader context of technologies is one of the hardest things.
Practical question: I have a short, fat resume (e.g. MechE degree, work experience in AI, UX, manufacturing, academic research, and writing). What industries/companies/roles will value this skill set the most? Where can short, fat people find opportunities?
Wouldn't that be startups? Maybe a hardware startup since you are a MechE.
What I've observed is that people have an easier time when they can assign you a label that fits with their world view. Depth (for some value or depth) provides the tag that (lazy) managers, hr, etc need to understand where you will fit. If you can do a range of stuff, even well, people aren't sure what to do with that, and so often end up focusing on someone else.
I saw that a lot in consulting, where people with what would objectively be a very superficial skillset in some area or another "branded" themselves as being a deep expert, and became the go-to for anything that was perceived as relating to their area.
So I would maybe rephrase as "skinny engineers brand more easily"
I saw that a lot in consulting, where people with what would objectively be a very superficial skillset in some area or another "branded" themselves as being a deep expert, and became the go-to for anything that was perceived as relating to their area.
So I would maybe rephrase as "skinny engineers brand more easily"
I think there's some dynamics at play here that obscure the situation.
First of all, there's a tendency for depth engineers to be more visible. But this is extreme; there's a handful of top names in StackOverflow for a tag like csharp or django, but that doesn't mean number 1000 in a given tag is an amateur at it, he's likely pretty good. Similarly, not everyone writes respected blogs, but the people who do tend to be ones who spent a heck of a lot of time in one niche. That doesn't mean you need a known blogger for your project.
Second, there's a tendency for hiring firms to want a dev fully trained in some vertical. This may sound sensible but often isn't. If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I think in a lot of cases, yes. Whether you'll be allowed to take that risk depends on the situation, and often you won't be. This works the other way too: a lot of devs will decide not to bother applying.
Third, diminishing returns. Like a lot of knowledge stuff, there's a sort of pareto principle here. You can learn most of anything in way under half the time to learn the whole thing, if that's even possible. If your project is not super specialized in one vertical, but still requires a lot of verticals, you benefit from having a guy who knows a lot about a lot of stuff.
First of all, there's a tendency for depth engineers to be more visible. But this is extreme; there's a handful of top names in StackOverflow for a tag like csharp or django, but that doesn't mean number 1000 in a given tag is an amateur at it, he's likely pretty good. Similarly, not everyone writes respected blogs, but the people who do tend to be ones who spent a heck of a lot of time in one niche. That doesn't mean you need a known blogger for your project.
Second, there's a tendency for hiring firms to want a dev fully trained in some vertical. This may sound sensible but often isn't. If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I think in a lot of cases, yes. Whether you'll be allowed to take that risk depends on the situation, and often you won't be. This works the other way too: a lot of devs will decide not to bother applying.
Third, diminishing returns. Like a lot of knowledge stuff, there's a sort of pareto principle here. You can learn most of anything in way under half the time to learn the whole thing, if that's even possible. If your project is not super specialized in one vertical, but still requires a lot of verticals, you benefit from having a guy who knows a lot about a lot of stuff.
> If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly?
I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it.
It can’t be very long. Maybe 2 weeks? If you had a number, you could calculate the costs as part of a standard onboarding process. You’d just need to make sure that you hire someone who can demonstrate a willingness to learn the new thing.
This seems like it could be much cheaper than hiring an expert with the most years of experience in the particular combination of technologies in your stack, without compromising on quality.
And the perspective from someone with a breadth of knowledge is more likely to yield innovations that provide your company/project with a competitive advantage, compared to the expert that has been working on the same thing for many years.
I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it.
It can’t be very long. Maybe 2 weeks? If you had a number, you could calculate the costs as part of a standard onboarding process. You’d just need to make sure that you hire someone who can demonstrate a willingness to learn the new thing.
This seems like it could be much cheaper than hiring an expert with the most years of experience in the particular combination of technologies in your stack, without compromising on quality.
And the perspective from someone with a breadth of knowledge is more likely to yield innovations that provide your company/project with a competitive advantage, compared to the expert that has been working on the same thing for many years.
> I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it.
As someone who's done this probably too many times (Perl cgi -> cakePHP -> Play framework -> Spring -> Node.js/Express -> Flask -> Sinatra) I'd say your two week estimate sounds about right, at least given my personal experience.
After switching you quickly notice patterns and apply your past experience from other languages and frameworks. After a few weeks to a couple months you produce idiomatic code indistinguishable from your peers.
And those examples are just web framework transitions. As someone with not enough sense to stay put, I've wandered as far as:
* embedded C and assembly for microcontrollers
* writing kernel modules and device drivers
* designing, programming and assembling custom hardware (pcbs, enclosures)
* writing mobile applications (iOS/hybrid)
* being a frontend engineer (jQuery -> moo -> knockout -> backbone -> redux+react)
I've jumped fields from robotics research, social networking, healthcare, fintech, and consumer electronics.
It's been a wild ride and looking back I honestly wouldn't change much in hindsight.
As a generalist I work best on the early side of projects where I end up "wearing lots of hats." 'Tend to stick to a place for 5 or so years until everyone becomes specialists, then move on. As you say though the key is the willingness to learn.
As far as your point on generalists being cheaper than experts--I've found that pay honestly has more to do with soft skills than "expertise." (Good communication, self advocacy skills, etc.)
As someone who's done this probably too many times (Perl cgi -> cakePHP -> Play framework -> Spring -> Node.js/Express -> Flask -> Sinatra) I'd say your two week estimate sounds about right, at least given my personal experience.
After switching you quickly notice patterns and apply your past experience from other languages and frameworks. After a few weeks to a couple months you produce idiomatic code indistinguishable from your peers.
And those examples are just web framework transitions. As someone with not enough sense to stay put, I've wandered as far as:
* embedded C and assembly for microcontrollers
* writing kernel modules and device drivers
* designing, programming and assembling custom hardware (pcbs, enclosures)
* writing mobile applications (iOS/hybrid)
* being a frontend engineer (jQuery -> moo -> knockout -> backbone -> redux+react)
I've jumped fields from robotics research, social networking, healthcare, fintech, and consumer electronics.
It's been a wild ride and looking back I honestly wouldn't change much in hindsight.
As a generalist I work best on the early side of projects where I end up "wearing lots of hats." 'Tend to stick to a place for 5 or so years until everyone becomes specialists, then move on. As you say though the key is the willingness to learn.
As far as your point on generalists being cheaper than experts--I've found that pay honestly has more to do with soft skills than "expertise." (Good communication, self advocacy skills, etc.)
Think of an engineering team like a DnD group. You need a tank (wide), DPS (narrow), buff / debuff (QA), wizard (designer), and more.
Going all wide or all narrow is a recipe for a team wipe.
Going all wide or all narrow is a recipe for a team wipe.
Unless, to expand the metaphor to MMORPGs, you’re trying to solo (read: ramen startup) non-current content (read: disrupt an industry that has lagged in technical innovation, meaning you don’t need deep technical innovations but you do need broad agility).
The “short fat engineer” is the early-career nothing-to-lose startup founder, and that’s a vital role that is arguably correctly valued by our industry in recent decades.
The “short fat engineer” is the early-career nothing-to-lose startup founder, and that’s a vital role that is arguably correctly valued by our industry in recent decades.
What about the squares amongst us?
A possible problem with ‘wisdom’ in this sense is that it doesn’t always stack well, whereas deep knowledge usually does.
A wise generalist manager deftly guiding the skills of a bunch of deep specialists probably makes for a great team, and a team that can be expanded without much friction. A team with too many ‘wise’ people (or people who perceive themselves that way) might just waste all day arguing.
A wise generalist manager deftly guiding the skills of a bunch of deep specialists probably makes for a great team, and a team that can be expanded without much friction. A team with too many ‘wise’ people (or people who perceive themselves that way) might just waste all day arguing.
How about "tall and fat" (square)? I'd consider myself fairly expert in C and C++, SQL, Windows programming, UNIX/Linux in general, Delphi and a few other technologies, in that quite a few people have paid me for writing important applications using them, teaching them and writing about them.
It seems pretty clear that the model is relative to "total surface area". What you call a "tall and fat" square may be "short and skinny" relative to someone else's bar, but now we're just talking about total level of skill, which isn't really relevant.
Then, according to this dumb pop psych thing, you are autistic and not a good fit for the job market.
[deleted]
No sources and a lot of assertions here. I'm not sure how true this is tbh. Some of the best TAs I've worked with have a very broad knowledge of a lot of technologies, without being much of an expert in any specific technology.
I'm also personally somewhere between a tall-skinny and t-shaped engineer. Admittedly jobs seem to be a little harder to come by, but there are some jobs (especially with small startups) that really appreciate engineers who have a wide range of skills.
I'd love to see some data, confirming this. I suspect OP is right, but I don't think "short and fat" engineers are under valued as a rule, it's more that 90% of the time companies are looking to hire someone with a very specific skillset to fill a very specific role.
I'm also personally somewhere between a tall-skinny and t-shaped engineer. Admittedly jobs seem to be a little harder to come by, but there are some jobs (especially with small startups) that really appreciate engineers who have a wide range of skills.
I'd love to see some data, confirming this. I suspect OP is right, but I don't think "short and fat" engineers are under valued as a rule, it's more that 90% of the time companies are looking to hire someone with a very specific skillset to fill a very specific role.
I think this article underestimates a risk of the "short fat" information spectrum.
People who think they know something are more likely to be wrong than people who don't think they know anything on a topic. There's a "competence gap" between knowing you know nothing and actually having deep knowledge; it's the "just enough to be dangerous" zone.
Depending on how tall precisely "short fat" is, that can describe an engineer that, more often than not, makes the wrong choice because they know enough to have opinions but those opinions are raw.
People who think they know something are more likely to be wrong than people who don't think they know anything on a topic. There's a "competence gap" between knowing you know nothing and actually having deep knowledge; it's the "just enough to be dangerous" zone.
Depending on how tall precisely "short fat" is, that can describe an engineer that, more often than not, makes the wrong choice because they know enough to have opinions but those opinions are raw.
I made an account to give my perspective. I call my self a generalist because I don’t know the correct term. You can put me on any team and I can learn, adapt, and improve any system you put me on. I’m not the best at coming up with new ideas, but I can take any idea, implementation, etc and combine them all to fit whatever need. I tend to build systems, make them stable, teach people the how and why, and then move on to another project. I thrive at companies that allow me to choose my projects and allow me to learn and build new things.
For further in-depth reading, I recommend the book "Range: Why Generalists Triumph in a Specialized World". It explores the generalist vs specialist dichotomy within various fields (e.g. sports, music, engineering) and compares the successes and contributions between the two. As you might guess from the title, the book reaches a very similar conclusion - for spaces involving unstructured problem solving such as engineering, breadth lends itself better to creativity and achieving breakthroughs.
In my opinion, for most projects what's necessary is to approach from a broadly informed perspective and then dive deep into multiple potential solution strategies to see what direction will work well. Then dive even deeper into the details related to the architecture you have chosen.
The problem with focusing too much on one area is that you can only deal with one particular type of problem and maybe only with one particular type of solution.
The problem with focusing too much on one area is that you can only deal with one particular type of problem and maybe only with one particular type of solution.
I would add that deep skills, especially when expressed in years of experience, are often indicative of having worked in a bubble, and may not even generalize to other applications of the same tech.
Cases where someone has actually gotten progressively "deeper" as they continue to work in the same area are (anecdotally) outliers. It's much more common to have just spend a lot of time doing more of the same.
Cases where someone has actually gotten progressively "deeper" as they continue to work in the same area are (anecdotally) outliers. It's much more common to have just spend a lot of time doing more of the same.
I guess I’m relatively fat, but not really. I’ve done a lot of surface level research/ on stuff that no one uses or really cares about.
Ive always been amazed by the “tall” devs and have one or twice (or more than I’d like to admit) tried to deep dive something always eventually giving up because I have no idea where to obtain the deeper knowledge. Perhaps more realistically, I just have a different type of fat.
Ive always been amazed by the “tall” devs and have one or twice (or more than I’d like to admit) tried to deep dive something always eventually giving up because I have no idea where to obtain the deeper knowledge. Perhaps more realistically, I just have a different type of fat.
This could be one of the reasons why tech interviews are awkward. Most of them are "optimised" for tall and fat engineers but what you actually get is "luck of the draw" T shaped engineers on random specialties that you may not even need, with the assumption that the T shaped engineer can be transformed on demand to a short and fat or tall and skinny.
Specialist vs generalist is a false bifurcation in the article's context. There's really just one dimension: influence. You have only breadth but you can convince teams to move in the direction you like, and you will be valued. You have depth yet the depth is of no use to solve your team's challenges, then your depth will not be valued.
Expressing ideas as pseudo-graphs is overvalued.
A lot of sounds words without anything concrete. What is wisdom? How do you quantify it? Why "short far" engineer can have it and why T-shaped or "skinny" engineer can't have it? What makes someone "short and fat" valuable compared to other types?
This is shortsighted. The reason deep knowledge is more valuable is that learning anything stops being fun, and therefore presents less of a biological pull, after the first few milestones. There's a logarithmic decay in reward to effort put in. So naturally you're going to want engineers that have put in the hard work to build their knowledge, rather than the posers who read about engineering but never actually got into the nitty gritty. Why? Because it becomes rare, and scarcity drives up value. Simple!
EXAMPLE: Why would I care if my plumber also moonlights as a surgeon if all I care about is getting my faucet fixed without him passing the buck due to perceived complexity?
Those things are great in a dinner party setting, but in the professional workplace you want professionals not dabblers. Whenever I meet a self styled "generalist" nowadays I scoff. It's not hard to read HN daily and pick up on the lingo and memes and fake your way to 99% of a "generalist" in both knowledge and impression, but that doesn't make one a good engineer.
EXAMPLE: Why would I care if my plumber also moonlights as a surgeon if all I care about is getting my faucet fixed without him passing the buck due to perceived complexity?
Those things are great in a dinner party setting, but in the professional workplace you want professionals not dabblers. Whenever I meet a self styled "generalist" nowadays I scoff. It's not hard to read HN daily and pick up on the lingo and memes and fake your way to 99% of a "generalist" in both knowledge and impression, but that doesn't make one a good engineer.
I think your premise is flawed. Generalists are not "dabblers". They are professionals just as much as specialists are. Either you have a very odd (and incorrect) view of how software development is done, or you're presenting a straw man that doesn't have anything to do with the article's premise.
I find most specialists useless when it comes to architecting and building a full system, and often when they are a part of a team, focused on their specialty, they build in a way that is difficult to fit into the whole.
Obviously there are good things, too: my knowledge of things like data science and graphics is limited; if a part of a project called for deep knowledge in those areas, I'd be happy to have a specialist on the team. But unless they are more of the "T-shaped" type the article talks about, they need a lot of hand-holding when it comes to anything outside their domain.
Generalists bridge that gap, and handle necessary concerns that most specialists don't even consider, let alone know how to handle.
(Full disclosure: I consider myself a generalist, though at times I have ended up diving deep into particular areas when projects have required it.)
I find most specialists useless when it comes to architecting and building a full system, and often when they are a part of a team, focused on their specialty, they build in a way that is difficult to fit into the whole.
Obviously there are good things, too: my knowledge of things like data science and graphics is limited; if a part of a project called for deep knowledge in those areas, I'd be happy to have a specialist on the team. But unless they are more of the "T-shaped" type the article talks about, they need a lot of hand-holding when it comes to anything outside their domain.
Generalists bridge that gap, and handle necessary concerns that most specialists don't even consider, let alone know how to handle.
(Full disclosure: I consider myself a generalist, though at times I have ended up diving deep into particular areas when projects have required it.)
You’re not arguing against a generalist (varying depth over a handful or many areas), you’re describing, sure, let’s call it a poser or dabbler (little to no depth in any area).
I suppose the paradigm for aging engineers like me would be "crumbling dock" rather than "T shaped": Quite a bit of breadth, with depth in various places, except that when you rely too much on it, you may find out that some of it has rotted away in the mean time.
The valve employee handbook talks about the T shaped engineer (page 32) https://media.steampowered.com/apps/valve/Valve_Handbook_Low...
That's before their model is rigged properly.
The article of this post also does. I’m unsure what point you’re trying to make?
Nothing! Just a cool factoid!
Interesting choice of words. I might consider invest in named engineers, is there EFT for them?
One hidden risk with adopting industry leading technology at smaller businesses is that you unintentionally select for tools that favor specialists, and that is harder to hire for and less useful for an early or small business.
Remember the adage:
A specialist will tend to underestimate how much a generalist can accomplish, when they choose to specialize, and a generalist will tend to underestimate how deep any given specialty really goes.
A specialist will tend to underestimate how much a generalist can accomplish, when they choose to specialize, and a generalist will tend to underestimate how deep any given specialty really goes.
Looking at their illustrations reminds me of Tetris. I guess it is just like in Tetris - we need the right mix of vertical, horizontal, and T shaped pieces or we are screwed!
Yeah exactly! That "undervaluing" is what initiated that whole fuck-up at the Jurassic Park :)
I thought this was going to be about salary discrepancies between people with different physical characteristics.
Someone should study that.
Someone should study that.
[deleted]
I always thought pi "shaped" knowledge is best, as it helps you build networks interlocking like proteins.
Is there any data to back up the claim the author makes? Otherwise, this looks like little more than a long tweet.
Bad article. Noone is just an expert in one thing and can't do anything else. What actually happens is by becoming an expert at something you also learn things that will help you elsewhere, which means you can pick up other things more quickly. So the choice is either between someone who is an expert in a one thing and knows a bunch of other things, or someone who just knows of bunch of things.
As a tall fat engineer I wish that described my technical ability not my physical appearance.
my theory: depth == salary, width == mobility.
depth is risky - when time is right, you make a ton of money; opposite also true.
width is a hedge - you don't get paid as much, but you can land a job quickly, because you can plug into any team
width is a hedge - you don't get paid as much, but you can land a job quickly, because you can plug into any team
> width is hedge - you don't get paid as much, but you can land a job quickly, because you can plug into any team
I generally like your model, but mobility is upstream of salary too. If you're very intentional about your career, mobility is the ace up your sleeve, letting you slot into the places you need to to maximize your current and future salary.
I've always been a pretty width-first engineer; it just fits my personality. But time and again, I've been able to open doors for myself because my established excellence in one area provided an "insurance policy" for teams to take a chance on me working in another (in-demand, specialized) area. After the first iteration or two, it's been a virtuous cycle, where I make lots of money with my established skill in the currently-hot thing and trade off a small portion of that to grow the skill in the next-to-be-hot thing.
Though perhaps this doesn't generalize well. I've been studying/working in AI for well over a decade and it's been a remarkable boom for my chosen field. Perhaps during the next AI winter, I'll have to face the depth/width trade-off a little more directly. But even in that case, it seems like width maximizes my expected salary.
I generally like your model, but mobility is upstream of salary too. If you're very intentional about your career, mobility is the ace up your sleeve, letting you slot into the places you need to to maximize your current and future salary.
I've always been a pretty width-first engineer; it just fits my personality. But time and again, I've been able to open doors for myself because my established excellence in one area provided an "insurance policy" for teams to take a chance on me working in another (in-demand, specialized) area. After the first iteration or two, it's been a virtuous cycle, where I make lots of money with my established skill in the currently-hot thing and trade off a small portion of that to grow the skill in the next-to-be-hot thing.
Though perhaps this doesn't generalize well. I've been studying/working in AI for well over a decade and it's been a remarkable boom for my chosen field. Perhaps during the next AI winter, I'll have to face the depth/width trade-off a little more directly. But even in that case, it seems like width maximizes my expected salary.
You're absolutely correct. Great insight that mobility also increases salary!
Can I rubber duck you with another question? As someone who is also trying to maximize mobility and width, how do you feel about the idea of "it's not who you know vs what you know, it's who knows what you know"? In other words, when you move teams/jobs, how to you gain credibility? Do you do anything to promote/show your 'track record'?
Can I rubber duck you with another question? As someone who is also trying to maximize mobility and width, how do you feel about the idea of "it's not who you know vs what you know, it's who knows what you know"? In other words, when you move teams/jobs, how to you gain credibility? Do you do anything to promote/show your 'track record'?
[deleted]
[deleted]
Jack of all trades, master of none but sometimes better than one.
I am not sure that perspective will be widely shared, I am not even sure if I agree myself, but I do appreciate this post as I consider myself a short fat engineer.
A short fat engineer is likely a dilettante.
but isn't the best team to have one of each of the shapes? Why do we have to choose which shape is the best?
Short and fat ones are in management.
at this point i'm Π-shaped.
Great title. Great article.
My wife likes me so
The reality often goes against the premise of the article.
What are accomplishments of tall.skinny vs short.fat engineers?
Linux was driven by Linus T, javascript by Brendan E, Apple by 2 Steve’s, etc.
Innovation and creativity are more highly valued, which are byproducts of short.skinny type.
What are accomplishments of tall.skinny vs short.fat engineers?
Linux was driven by Linus T, javascript by Brendan E, Apple by 2 Steve’s, etc.
Innovation and creativity are more highly valued, which are byproducts of short.skinny type.
The two Steves are a great example. Well, Steve W was an electronic engineer with a deep interest and understanding of electronics. But Steve J was the one who took calligraphy classes and realised that computers could benefit from multiple fonts.
Steve J is tall and skinny. Steve W is slightly shorter than average and fat. Linus is pretty much dead average, maybe a little tall and a little heavy. Brendan's the same height as Steve W, and was weight proportionate at the time, though he's put on weight since then.
As usual with these types of articles, the advice in the maxim is asserted free of context.
> On a long enough time line, wisdom is always more valuable than knowledge.
In practice, context is everything. That’s why for every expert, there is an equal and opposite expert.
> On a long enough time line, wisdom is always more valuable than knowledge.
In practice, context is everything. That’s why for every expert, there is an equal and opposite expert.
People who have broad interests with no depth of knowledge have not identified (for themselves) where their value lies.
I would imagine that this type of engineer needs to be carefully managed to stay on tasks that add business-value.
As such, it's not unfair that they are seen as juniors. They are juniors.
I would imagine that this type of engineer needs to be carefully managed to stay on tasks that add business-value.
As such, it's not unfair that they are seen as juniors. They are juniors.
People whose value lies in coordination often need to dabble in multiple fields. Think of a technical artist in a game company.
I would count coordination here as a deep technical skill, which requires a depth of study and/or experience. You are selling your coordination skills.
It's the stick of the T.
It's the stick of the T.
I don't think there are too many people around who actually have no deep skill. That usually doesn't hold up too well in the job market.
Not sure I agree. A "short fat" could theoretically be replaced by a group of "short skinny", whereas a "tall skinny" could only be replaced by another "tall skinny".
As value is largely determined by scarcity (supply and demand), this would cause "short fat" to be of lower value.
As value is largely determined by scarcity (supply and demand), this would cause "short fat" to be of lower value.
So you're saying one engineer who's good at lots of things can be replaced by a dozen engineers who are only good at one thing?
It doesn't work that way because coordination costs are a big part of the cost.
It doesn't work that way because coordination costs are a big part of the cost.
It depends on how depth of knowledge is measured. One is considered an expert in a niche because they know it inside and out. But in theory, multiple people with a disjoint subset of knowledge of the niche could also be a reasonable replacement?
Why would a generalist be wiser than somebody who is able to go into depth and understand the ugly details of a project? That is what the T-shaped thinking is about.
Elon Musk is a great example who is able to answer deep technical questions on many subjects, and I think he needs people who understand their own project deeply, not ,,short fat'' engineers.
Elon Musk is a great example who is able to answer deep technical questions on many subjects, and I think he needs people who understand their own project deeply, not ,,short fat'' engineers.
Elon Musk is a hack, and his "deep technical" answers are either pre-prepared or appear deep and technical to people outside of the fields.
Specialisation is the exception, not the rule.
> Everyone should read "Range By David Epstein" https://www.amazon.com/Range-Generalists-Triumph-Specialized...
> In most fields, especially those that are complex and unpredictable. Generalists, not specialists, are primed to excel.
> Everyone should read "Range By David Epstein" https://www.amazon.com/Range-Generalists-Triumph-Specialized...
> In most fields, especially those that are complex and unpredictable. Generalists, not specialists, are primed to excel.
Generalists are highly valuable for many types of orgs and projects especially nascent projects. But sometimes you need the precise output of a specialist to achieve something.
If my business has a product that is highly dependent of let's say OpenGL, then an OpenGL specialist will generate more specific output that someone who knows a little of OpenGL and a lot of other things.
However, there's always the counterargument that generalists can compensate with their holistic view and understanding of problems throughout the whole stack. I understand this and agree with it, but I think there's a point in every innovation where the generalist contribution declines sharply. And I'm saying this as a generalist.
If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore.