Perhaps professionally, being an "expert beginner" is bad, but in other pursuits being content with competency can make them more enjoyable.
To build on the bowling example, it is ok to be an average bowler if you are having fun with it. Anyone that's bowled casually with someone that is over competitive knows how obnoxious it is. Accepting that improvement is not always necessary to enjoyment is important.
Not sure I get the analogy. If you're an expert beginner bowler, everyone can see how good, or bad, you are.
All the expert beginner developers I've met act as if they are not beginners. You only find out piecemeal, and that can end up in frustration and wasted time.
I think what you're more talking about is just sitting at what he considers "advanced beginner" or "competent" phases, rather than calling yourself an expert at something. And that's fine if it's what you're going for - you definitely don't need to try to squeeze every last ounce of knowledge and skill into every department in your life - just don't assume you know everything!
Yeah, I'm with you. For example I'll never be a great skiier, and I'm content with that, but at the same time in fact I derive a fair amount of enjoyment out of the simple process of trying to get better.
I feel like I may have wound up on this path... I'm working in a government role where I've been put as the lead developer on some major pieces of software despite only being 5 or so years into my career because the people I'm surrounded with seem to have some significant competency issues.
Not sure what I can do but quit and I just don't want to give up on the stuff I'm working on yet and I'm relied upon quite a bit... but I'm almost completely stagnating. Worst part is, I can probably just keep doing it for another 20 years and retire, it's almost too easy to just go that route.
> I feel like I may have wound up on this path... I'm working in a government role where I've been put as the lead developer on some major pieces of software despite only being 5 or so years into my career because the people I'm surrounded with seem to have some significant competency issues.
Please don't quit yet. Please work on some pet project or something in your free time if you'd like. As you saw, we need people who care in government IT projects. We won't magically find people who care. We are the people who care.
I’ve been in a similar organization and have been put in charge of projects that I’ve been under qualified for, too, but I pressed on with good intentions and an “I care!” attitude. The problem is that at these organizations there’s often no one more competent to turn to for help. If you fail (like I did) you get the sense that there’s a class of people who can do things rigorously and well and then there’s the class that includes you. It’s an experience that can easily leave you worse off.
It would be noble to stick around, but maybe a person owes it to him or herself to find an organization already doing things the right way that is willing to hire and train eager inexperienced team members.
So basically the article is saying if you wound up on this path, it means you're an incompetent programmer. Why would people rely on you if you're incompetent.
I'm in a unionized position, the least competent people on my team are people who were basically dumped on us from other groups who had to get rid of people and of course, sent off the worst... suffice to say I'm not too concerned about keeping a job somewhere around there.
>Not sure what I can do but quit and I just don't want to give up on the stuff I'm working on yet and I'm relied upon quite a bit... but I'm almost completely stagnating.
Don’t quit your job. The article is elitist nonsense. The reality is that most of us are just plumbers, we’ll always be just plumbers, and that’s ok. You’ll probably never do anything world changing or cutting edge in your career. But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard. Keep that in perspective and focus on pursuing meaning in your life that doesn’t involve a manic drive to sacrifice more time for more money.
It’s not about doing anything world changing. There are a few
dangers in burying your head in the sand and not keeping your skills in sync with the market.
- lack of optionality: If for some reason you don’t like your job, you’re stuck because it’s harder to find a job if you don’t check at least some of the boxes.
- alternatively, your job lays you off after you’ve been at a company for 15 years doing ASP.NET Web Forms and you start looking for a job and you find that you aren’t hireable. Then you start screaming “ageism” (I’m 45).
But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard.
$56k is the median household income, according to your source. The median salary in this country is $31k [0]
I also assumed most people here are bay area, where $100k is intern pay. That means your average software developer out of college is earning more than twice the median income of two working adults.
Golf is the same way. I know people who improve a little but it’s rare to find a golfer who shoots high 90s and makes their way into the 70s. I went from a 15 handicap to a 5 in two years, and even now I am just starting to grasp at my core weaknesses and faults. Software development has been similar in past few years, in that the growth has come from facing my feers of talking to people, communication, leading, etc.
I think that as you get more towards the 70s golf becomes more of a mental game and a battle of endurance to hit shots as crisp on 18 as you did on 1. That being said, I jumped from 100s to around 80 from simple mental things like instead of focusing on hitting the ball with the club, I instead tried to hit the club with the ball. I found that helped me hit the sweet spot much more.
In software development, there is currently no more certain route to this state than to read 'Clean Code', take it as dogma, and stop there. Most of its major prescriptions and proscriptions have important caveats that are either glossed over or forgotten.
What that tells us is to design development environments for the expert beginner. Expert beginners are cost-effective. Competence and expertise in web development is not cost effective. By the time someone reaches the expert level, the technology in which they are an expert is obsolete. Like Java programmers.[1]
Competent (web) developers can roll with changing technology, leveraging fundamental skill and understanding; beyond superficial differences, the basics haven’t changed all that much in the past two decades. “Expert beginners” seem to complain about rapidly-changing technology (as well as basics like proper usage of version control); they also make giant messes, which can’t possibly be cost effective.
"the basics haven’t changed all that much in the past two decades"
I did some front and back-end development in the mid 00s and almost nothing still applies. Even the HTML standard is different, CSS has gotten much more complicated and JS has changed immensely.
Most importantly, people don't build web sites any more, they use various frameworks to build so-called SPAs.
The front-end is in eternal turmoil and front-end skills expire fast, good thing I got off this carousel.
I don't want to trivialize learning modern frontend development with a clean slate, because it is a long process to get familiar with the tools. But I think those are the details and not the basics. Whether you use html templates rendered server side, or JSX in an SPA, the experience is quite familiar.
This is a very narrow way to look at software expertise. The technology stack may change but the fundamental problems are unfortunately quite stubborn. And once you understand fundamental approaches like OOP or functional programming the only thing many “new” technologies bring to the table is a bunch of new syntax for expressing the same ideas.
It’s rather like mechanical engineering. Every decade brings new equipment, software tools, and manufacturing techniques but the problems (and solutions) of stress, strain, and heat transfer remain stubbornly similar.
That’s an interesting premise, but how do we know? What if expert beginners aren’t cost-effective but the true cost of relying on them is hidden because there isn’t enough evidence available about the success of alternatives built by developers who have reached higher levels of skill and experience?
By the time someone reaches the expert level, the technology in which they are an expert is obsolete.
I respectfully disagree. Focussing on specific tools seems to be exactly the kind of danger we’re talking about with the expert beginner syndrome. Someone who sees the bigger picture will understand common principles and techniques that are applicable with many tools, allowing them to reach proficiency with new but similar tools very quickly. This leaves them free to focus on any genuine differences and, more importantly, on the problem to be solved rather than the tools used to solve it.
This effect is seen only with scale. If you have thousands of developers like my former employer, IMHO it's best to develop a tool that will help these "expert beginners" to not make mistakes, e.g. make them form designers, rule engine and composable rule blocks etc.
If you have thousands of “expert beginner” level developers, perhaps a training programme would be a better option? At that scale, you would surely have the resources to systematically increase the skill level of your whole staff instead of merely trying to compensate for their current limitations indefinitely.
That is a good point but that requires either having training in place or having time to do that. The workplace I worked at had a pretty high turnout of developers and short term projects using various languages and technologies (our "expert beginner tools" largely abstracted that as well, thankfully), training them was not really an option (and we lacked the required infrastructure). It was an outsourcing/staffing firm btw, not a product company.
The problem with the expert beginner is that they refuse to learn the new tool, because in their mind the old way worked perfectly fine. The developer who recognizes the value of these systems and takes the time to learn their intricacies is the least likely to fall into the trap.
Though even with those systems, there's the danger of people becoming experts of those specific systems, and resisting any push for an upgrade, no matter how important.
> the technology in which they are an expert is obsolete
A lot of the principles, idioms, patterns, and instincts experts pick up transcend technology. Sure, they won't be able to optimize a framework they've never interacted with, and some bugs will probably require a trip to stack overflow, but they know how different pieces fit together, where to go for help, what it looks like when something isn't working, best practices for avoiding a huge catastrophe, and - probably most importantly - the wetware people skills required to get things done and done right.
Being a master software engineer, in other words, has almost nothing to do with the particulars of the software.
When I was working with a react code base, there are a lot of brittle and bloated components, which didn't follow React idioms at all. Make a lot of data flow out of sync.
It turns out there are a lot of senior programmers use their experiences from Java or other background to build things. They've read some redux docs, but they refuse to use follow those idioms just because it looks weird.
I don't about master software engineers. But I see front-end development or WebSocket programming differs from plain old stateless HTTP back-end programming because there's a major partaway from request response programming model. For those scenario even typical hexagon pure domain model starts to falling apart, because the model is simply not reactive.
I've seen this (or variations of) this article before, but what is lacking is how to resolve this problem. How to bring programmers out of the "expert beginner" stage once they realize it. Is it just a heavy dose of mentoring? Where do they find companies most fit to put programmers on the right path?
I am by no means an expert programmer, but this is my strategy to stay relevant and employable. Obviously I'm not perfect and break my own rules, but this is what in my mind an optimal honkycat would get up to:
Read books, lots of them. Books about programming, math, computer science, game design, user interfaces, graphic design, productivity, investing, meditation, history, criminal justice, fantasy, science-fiction, and everything else.
Watch conferences. Go to your local tech meet-ups. Meet people. Ask questions.
Take classes that interest you in your city.
If I get too bored at a job I find a new job. You can't stop learning. What you are going to be good at is what you do for your day job.
Have a schedule. Work out frequently, keep my health in order. Wake up EARLY in the morning and work on side projects BEFORE WORK. If I wait until after work, I'm going to be too tired to actually get anything useful done. Turn off the computer/tv for a few hours before bed every night, and read books instead of surfing ( social media of choice ).
This reminds me of the saying that you can have ten years of experience or you can have one year of experience ten times. Unfortunately there several forces in our industry that tend to push in the latter direction.
One such force is that compensation tends to increase more quickly, at least in the early stages of a career, with rapid job-hopping. This leads to the kind of title inflation mentioned in the article, and in the extreme case you get the 27-year-old founder/CTO who has an impressive-looking list of former employers on their résumé yet who has never built a substantial software system from scratch nor maintained an existing system for more than a year or two.
Another force pushing towards short-termism is that lot of new software simply isn’t expected or intended to last. The commercial incentives to invest in building robust, future-proof software are often outweighed by the commercial incentives to deliver early and deal with any problems if and when you get to v2. But then v2 has to be shipped early, and… Issues with reliability, scalability, performance and security just get kicked down the road until the next big rewrite, and writing maintainable code that can support ongoing development for a long time is unnecessary if you’re going to throw it all out and start over within a year or two anyway. Eventually, if the business hasn’t failed along the way, it reaches a level of maturity where it’s worth investing in these things more seriously, and then you do need developers who know what they’re doing. But by then a lot of the cool kids have moved on to throwing stuff at their next employer’s wall to see what sticks.
Of course there are parts of the industry that don’t follow this pattern and do have serious quality and longevity requirements for what they are building. However, they don’t tend to be in today’s fashionable parts of the industry like web app and mobile app development. As a result they may not be so attractive to the expert beginner, which is unfortunate because the expert beginner is not then exposed to better ways of doing things that are used routinely out of necessity in more demanding environments.
That quote was used in the article! I guess you missed it:
> If you’ve ever heard the aphorism about “ten years of experience or the same year of experience ten times,” the Expert Beginner is the epitome of the latter.
I agree with the factors you listed. As always I think company culture plays a big role too. If you're surrounded by expert beginners it's like an echo chamber where everyone thinks they are rockstars. Being surrounded by people who genuinely want to learn and improve instils the opposite mentality and drives progress.
So it is… I must have managed to skip over that paragraph. In my defence, I’d woken up in the middle of the night and just read all four articles in the series while wondering whether I was going to get any more sleep. :o)
I think this is where a good college curriculum is invaluable compared to say a bootcamp. The reason being is that you get exposed to a lot more aspects of computer science that show you just how much you don't know.
No they definitely don’t you can only get that through experience. But instead of learning one thing and thinking you’re the master of everything, in a fast moving CS curriculum you don’t have time to move further than advanced beginner and it will give you humility and wisdom to know what you don’t know
I find just the opposite. For the jobs that I hire for when I am in a hiring position, new CS grads are basically useless. At least the boot camp grads can hit the ground running and do simple features.
People get stuck in expert beginner land in no small part due to how shitty the hiring/training process is in most places. Outside of big tech companies and SV, no one hires generalists (past entry-level dev) and your resume gets screened out if you don't tick all the right boxes for language/framework (right down to exact framework..) or have a BigCo brand.
No one is willing to take on people who might need the slightest bit of ramp up time on new tech. So if you don't get all the right chances early, the only jobs you can even get hired into are those doing almost the exact same shit you have always done. God forbid someone hires a Java developer without experience in Spring into a gasp role that requires Spring (I see this constantly)!
I suspect managers like the authors basically fulfill their own prophecy. They insist on putting people into boxes and pretending they cannot learn, provide little opportunity to do so, and then blame the devs when they do not grow.
Your Java example hits too close to home. I know Java pretty well, and despite several good interviews, I got rejected because I didn't know Spring. One company even told me to learn Spring, build an independent project on it, and come back to interview. They followed up with me for 3 months after that till I told them not to anymore. At that time I was proficient in Java, Angular, Typescript, C# & Jython.
Ironically - I got hired into a product company which mostly works on their own internal java frameworks and didn't have a spring requirement. I figured I'll have to give time to learning Spring on the side since most Java jobs require it, but my first project here was on Spring Boot/Hibernate/Angular because of a client requirement, and I was put on it purely because of my Angular knowledge.
I'd understand if a company required complicated stuff done in Spring/Hibernate, but most organizations use of Spring Boot is limited to building rest APIs, for which no previous knowledge is necessary. I haven't yet run into an issue I couldn't solve by less than an hour of googling despite having no experience in it beforehand - even making interceptors and adding Spring Security.
Because of its simplicity I do wonder if I've barely touched the edge of it, and the usual usecase is much more complicated than this, but I'm planning on learning spring on Udemy anyway, so I guess I'll find out.
I fully believe that the Jack Welch style stack ranking school of management, performance and skills acquisition was a very expensive cultural mistake in modern corporate culture, perhaps one of the worst. The idea of stack ranking or internal competition is so naive and practically ineffective that it's no surprise it was an utter disaster in nearly every instance its been implemented -- it's also no surprise that it has been broadly recanted from most large tech firms that once implemented it, as well as disavowed by its original inventor!
That's what makes this article (and series) frustrating. It ignores that corporate software engineering is a team sport. Individual contributors need and deserve coaching and constructive working environment to unlock their true potential. But who is responsible for that? Is "everyone equal" or is it the case that the executives highest in the hierarchy are also responsible for the outcomes? I would say it's the latter. Are you a leader that's tired of expert beginners on your team? Take a look in the mirror. You hired them (or chose to retain them). You failed to provide them with the mentoring they needed to grow. You failed to build a constructive environment for them to be an engineer. And sometimes, most damningly, you failed to select the right kind of company or industry for your professional working style, goals, or preferred compensation. The truth is, if you didn't fail in any of these ways, you would never see any of these things you complain about!
Being a leader is hard, but doing it properly makes such a disproportionate binary impact on the ability of the organization to function properly that it's almost always my first (and often my last) question I need to ask to assess an organization. I'd like to see an end to these kinds of think-pieces and I'd highly recommend that folks who want real solutions to these problems (whether you're an IC or not) look elsewhere. By no means do I have the all the answers here, but a great place to start is one of my favorite books about engineering management: Camille Fournier's The Manager's Path.
52 comments
[ 3.6 ms ] story [ 94.4 ms ] threadTo build on the bowling example, it is ok to be an average bowler if you are having fun with it. Anyone that's bowled casually with someone that is over competitive knows how obnoxious it is. Accepting that improvement is not always necessary to enjoyment is important.
All the expert beginner developers I've met act as if they are not beginners. You only find out piecemeal, and that can end up in frustration and wasted time.
Not sure what I can do but quit and I just don't want to give up on the stuff I'm working on yet and I'm relied upon quite a bit... but I'm almost completely stagnating. Worst part is, I can probably just keep doing it for another 20 years and retire, it's almost too easy to just go that route.
Please don't quit yet. Please work on some pet project or something in your free time if you'd like. As you saw, we need people who care in government IT projects. We won't magically find people who care. We are the people who care.
It would be noble to stick around, but maybe a person owes it to him or herself to find an organization already doing things the right way that is willing to hire and train eager inexperienced team members.
I worked with many who had a 10-20 years career, but only 2-4 years "experience"
As long as you can keep your current job, that is.
Don’t quit your job. The article is elitist nonsense. The reality is that most of us are just plumbers, we’ll always be just plumbers, and that’s ok. You’ll probably never do anything world changing or cutting edge in your career. But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard. Keep that in perspective and focus on pursuing meaning in your life that doesn’t involve a manic drive to sacrifice more time for more money.
- lack of optionality: If for some reason you don’t like your job, you’re stuck because it’s harder to find a job if you don’t check at least some of the boxes.
- alternatively, your job lays you off after you’ve been at a company for 15 years doing ASP.NET Web Forms and you start looking for a job and you find that you aren’t hireable. Then you start screaming “ageism” (I’m 45).
But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard.
The median salary in the US is $56515 (https://wallethacks.com/average-median-income-in-america/). The median salary for a software developer is $100,690 (https://money.usnews.com/careers/best-jobs/software-develope...)
Also the best way to even get that is statistically to job hop at least early in your career.
I also assumed most people here are bay area, where $100k is intern pay. That means your average software developer out of college is earning more than twice the median income of two working adults.
[0] https://www.ssa.gov/OACT/COLA/central.html
https://www.alexa.com/siteinfo/ycombinator.com
[1] https://www.infoworld.com/article/3195285/java-and-c-continu...
I did some front and back-end development in the mid 00s and almost nothing still applies. Even the HTML standard is different, CSS has gotten much more complicated and JS has changed immensely.
Most importantly, people don't build web sites any more, they use various frameworks to build so-called SPAs.
The front-end is in eternal turmoil and front-end skills expire fast, good thing I got off this carousel.
It’s rather like mechanical engineering. Every decade brings new equipment, software tools, and manufacturing techniques but the problems (and solutions) of stress, strain, and heat transfer remain stubbornly similar.
That’s an interesting premise, but how do we know? What if expert beginners aren’t cost-effective but the true cost of relying on them is hidden because there isn’t enough evidence available about the success of alternatives built by developers who have reached higher levels of skill and experience?
By the time someone reaches the expert level, the technology in which they are an expert is obsolete.
I respectfully disagree. Focussing on specific tools seems to be exactly the kind of danger we’re talking about with the expert beginner syndrome. Someone who sees the bigger picture will understand common principles and techniques that are applicable with many tools, allowing them to reach proficiency with new but similar tools very quickly. This leaves them free to focus on any genuine differences and, more importantly, on the problem to be solved rather than the tools used to solve it.
Though even with those systems, there's the danger of people becoming experts of those specific systems, and resisting any push for an upgrade, no matter how important.
A lot of the principles, idioms, patterns, and instincts experts pick up transcend technology. Sure, they won't be able to optimize a framework they've never interacted with, and some bugs will probably require a trip to stack overflow, but they know how different pieces fit together, where to go for help, what it looks like when something isn't working, best practices for avoiding a huge catastrophe, and - probably most importantly - the wetware people skills required to get things done and done right.
Being a master software engineer, in other words, has almost nothing to do with the particulars of the software.
When I was working with a react code base, there are a lot of brittle and bloated components, which didn't follow React idioms at all. Make a lot of data flow out of sync.
It turns out there are a lot of senior programmers use their experiences from Java or other background to build things. They've read some redux docs, but they refuse to use follow those idioms just because it looks weird.
I don't about master software engineers. But I see front-end development or WebSocket programming differs from plain old stateless HTTP back-end programming because there's a major partaway from request response programming model. For those scenario even typical hexagon pure domain model starts to falling apart, because the model is simply not reactive.
https://www.tiobe.com/tiobe-index/
Read books, lots of them. Books about programming, math, computer science, game design, user interfaces, graphic design, productivity, investing, meditation, history, criminal justice, fantasy, science-fiction, and everything else.
Watch conferences. Go to your local tech meet-ups. Meet people. Ask questions.
Take classes that interest you in your city.
If I get too bored at a job I find a new job. You can't stop learning. What you are going to be good at is what you do for your day job.
Have a schedule. Work out frequently, keep my health in order. Wake up EARLY in the morning and work on side projects BEFORE WORK. If I wait until after work, I'm going to be too tired to actually get anything useful done. Turn off the computer/tv for a few hours before bed every night, and read books instead of surfing ( social media of choice ).
If you want things to improve for you, you have to improve.
One such force is that compensation tends to increase more quickly, at least in the early stages of a career, with rapid job-hopping. This leads to the kind of title inflation mentioned in the article, and in the extreme case you get the 27-year-old founder/CTO who has an impressive-looking list of former employers on their résumé yet who has never built a substantial software system from scratch nor maintained an existing system for more than a year or two.
Another force pushing towards short-termism is that lot of new software simply isn’t expected or intended to last. The commercial incentives to invest in building robust, future-proof software are often outweighed by the commercial incentives to deliver early and deal with any problems if and when you get to v2. But then v2 has to be shipped early, and… Issues with reliability, scalability, performance and security just get kicked down the road until the next big rewrite, and writing maintainable code that can support ongoing development for a long time is unnecessary if you’re going to throw it all out and start over within a year or two anyway. Eventually, if the business hasn’t failed along the way, it reaches a level of maturity where it’s worth investing in these things more seriously, and then you do need developers who know what they’re doing. But by then a lot of the cool kids have moved on to throwing stuff at their next employer’s wall to see what sticks.
Of course there are parts of the industry that don’t follow this pattern and do have serious quality and longevity requirements for what they are building. However, they don’t tend to be in today’s fashionable parts of the industry like web app and mobile app development. As a result they may not be so attractive to the expert beginner, which is unfortunate because the expert beginner is not then exposed to better ways of doing things that are used routinely out of necessity in more demanding environments.
> If you’ve ever heard the aphorism about “ten years of experience or the same year of experience ten times,” the Expert Beginner is the epitome of the latter.
I agree with the factors you listed. As always I think company culture plays a big role too. If you're surrounded by expert beginners it's like an echo chamber where everyone thinks they are rockstars. Being surrounded by people who genuinely want to learn and improve instils the opposite mentality and drives progress.
No one is willing to take on people who might need the slightest bit of ramp up time on new tech. So if you don't get all the right chances early, the only jobs you can even get hired into are those doing almost the exact same shit you have always done. God forbid someone hires a Java developer without experience in Spring into a gasp role that requires Spring (I see this constantly)!
I suspect managers like the authors basically fulfill their own prophecy. They insist on putting people into boxes and pretending they cannot learn, provide little opportunity to do so, and then blame the devs when they do not grow.
Ironically - I got hired into a product company which mostly works on their own internal java frameworks and didn't have a spring requirement. I figured I'll have to give time to learning Spring on the side since most Java jobs require it, but my first project here was on Spring Boot/Hibernate/Angular because of a client requirement, and I was put on it purely because of my Angular knowledge.
I'd understand if a company required complicated stuff done in Spring/Hibernate, but most organizations use of Spring Boot is limited to building rest APIs, for which no previous knowledge is necessary. I haven't yet run into an issue I couldn't solve by less than an hour of googling despite having no experience in it beforehand - even making interceptors and adding Spring Security.
Because of its simplicity I do wonder if I've barely touched the edge of it, and the usual usecase is much more complicated than this, but I'm planning on learning spring on Udemy anyway, so I guess I'll find out.
That's what makes this article (and series) frustrating. It ignores that corporate software engineering is a team sport. Individual contributors need and deserve coaching and constructive working environment to unlock their true potential. But who is responsible for that? Is "everyone equal" or is it the case that the executives highest in the hierarchy are also responsible for the outcomes? I would say it's the latter. Are you a leader that's tired of expert beginners on your team? Take a look in the mirror. You hired them (or chose to retain them). You failed to provide them with the mentoring they needed to grow. You failed to build a constructive environment for them to be an engineer. And sometimes, most damningly, you failed to select the right kind of company or industry for your professional working style, goals, or preferred compensation. The truth is, if you didn't fail in any of these ways, you would never see any of these things you complain about!
Being a leader is hard, but doing it properly makes such a disproportionate binary impact on the ability of the organization to function properly that it's almost always my first (and often my last) question I need to ask to assess an organization. I'd like to see an end to these kinds of think-pieces and I'd highly recommend that folks who want real solutions to these problems (whether you're an IC or not) look elsewhere. By no means do I have the all the answers here, but a great place to start is one of my favorite books about engineering management: Camille Fournier's The Manager's Path.