If you work in an average company who hires average people and you are well above average you quickly risk becoming exactly that. You can be the top 5% (I know it's subjective and controversial yet I'm sure we all have a clue what that means) of developers and this will make it likely for you to be that "local maximum" as everyone will see you internally as a guru.
But at companies who are employing the top 5% of the top 5% you will probably won't even make the first round of phone screens.
Get out of your comfort zone, and simply learn something new. Go wide, go deep or go both just realize that the moment you feel you are an expert on something it just means you are probably just ready to start learning it for real.
tl;dr
Knowing more than your peers doesn't make you an expert. You are at a local maximum and you need to look at the big picture to avoid being stuck there forever
It is very important to recognize that "comfort zone" also means you must have room to fail, which is actually tough for companies to hire for because most companies are actually super risk averse when it comes to hiring. Why else would they want to hire people that know as much about their stack as a filter before asking questions about their potential?
I went (foolishly, in hindsight) into areas on the thesis that a lot of organizations simply need some motivation from one or two highly capable people to raise the standards for everyone and that this form of leadership would be a good career path because people are oftentimes rewarded quite well for saving failing / ailing companies. Instead, I was beaten severely for trying to do create too much change for people that just wanted to a 9-to-5 job or (more importantly) given no projects with any risk or even much value even if it succeeded.
I've come to realize that organizations without risk or without any sense of leaving their comfort zones are the same thing as people - these are beginner-expert organizations. These are companies who implement a working Hadoop cluster in production and give themselves a big pat on the back... in 2015. These are companies that implement some CMDB... in 2014. These are companies that are rolling out SOAP services seriously on a roadmap... for 2018. The aversion to risk leads inevitably to worse results than if you had accepted some failures, but this only makes sense anyway when your organization is capable of speed. And this becomes the ultimate chicken and the egg problem with large companies. My answer is that you must break your egg to create a new chicken - if you do not sacrifice something, you will lose everything for sure.
This is very true and so important to your professional growth. There's a famous saying, "if you're the best one in the room, you're in the wrong room".
At my last job I was the only developer at a small web agency, along with a designer and a project manager. Basically every problem and solution I had to figure out myself, and while I did that, due to time constraints I often had to go with just what worked, rather than figuring out the best of all possible options.
At my current job, there are developers who know a lot more than me, and in the time I've spent working with them I've found I learn so much more so much more quickly than I did when I was working on my own.
> If you work in an average company who hires average people and you are well above average you quickly risk becoming exactly that.
I liked Steven Covey's 7 Habits take on this much more "Sharpen the Saw." This approach and wording puts all the blame on those around you. That is very good to think your above those around you and that you are above average.
A) Nothing wrong with average half the people are below average
B) Rating someone top 5% is totally a perception unless your in something that can be measured easily (Think fast 100m Dash or the author's bowling)
C) Having hired dozens of people for different jobs I can tell you that my top 5% at higher usually ended up being drama and the one person I just hired because I needed a body ASAP ended up being hands down my best employee. (Look at how Google has changed their hiring practices because hiring is close to impossible to get right, think NCAA Brackets)
D) Self-deception - Everyone believes their kid is above average and self-delusion inflates our own self-assessment. Blaming those around you give you a great out of self-responsibility.
This is where I find myself, although my team is very small (2 people only). HN has gone a long way in eliminating my expert beginner syndrome. Looking at what people are doing, when all I'm doing is writing "textboxes over data", is both humbling and inspiring.
I also find that sites like CodinGame, HackerRank, and Project Euler can also be helpful in combating that.
Ultimately, I'm looking to make the leap into a more challenging job, but for now, these will have to do.
Agree with you qualitatively about the need to get out of one's comfort zone, avoid "local maxima", and never consider oneself an expert. However:
But at companies who are employing the top 5% of the top 5% you will probably won't even make the first round of phone screens.
There's so much noise, context, and (as you acknowledge) subjectivity in how performers are evaluated that a statement like "We hire only the top .25%" can't possibly have any meaning. Top 5% might be about as far as you can push it. But even at that level, at best it's just a metaphor. And by itself, it doesn't provide us with any tools to reliably determine membership in that category.
Other than, of course, the tried-and-true method of throwing out a series of hoops for people to jump through over the phone, on your live coding portal, and at the whiteboard (ignoring all the built-in selection biases in this process: from whether candidates had had that very problem fed to them in another interview somewhere; to whether they spent 3 weeks to 3 months doing nothing but prepping for your hoops, day and night; to the simple matter of whether they're having a good day that day).
And then stack-rank: "See, only 5% of email applicants made it through our phone screen and take home test (which we had to re-design midway through because we realized we weren't stating the requirements properly, but whatever). Then we brought in 10 or so of those for interviews, until basically we got tired of interviewing and decided we had to hire someone. Ergo, we only hire the top .5%."
I dont know about that. Dont risk to much depending on your individual situation. Sometimes its better to be the king of the beggars, than to be the beggar of the kings.
(improvement is always welcome, but be careful flipping corporations)
I doubt there is such a thing as the "average people". There will always be some overlapping skill area and something one can learn from another, even if both got the same number of years of experience and very similar backgrounds.
This (partly) explains a major paradox I see: all the best software engineers I know are over 50, and yet the young'uns who dominate the tech zeitgeist assume these same people are incompetent dinosaurs. The young'uns have reached the expert beginner stage, and because they assume they're experts, they refuse to seek out the actual experts to discover what it is they don't know. And if the young'uns ARE the experts, and older developers aren't part of their in-group, then by definition the older developers must not be experts.
This is why I (for one) am strongly biased towards hiring older developers.
All the best software engineers I know are over 50, and yet the young'uns who dominate the tech zeitgeist assume these same people are incompetent dinosaurs.
With age comes experience and also comes a strengthening of biases. Older people, so the stereotype goes, are inflexible and set in their ways, if very experienced in those ways.
It's not really paradoxical, it just depends on what tradeoffs you're willing to make as the person responsible for hiring, which depends on your line of business. There are few things more tiresome than someone making mistakes you already made two decades ago and tried to warn about, and the same applies to someone ignoring the new and improved ways to get things done just because they've always done it that way and know it the best.
> all the best software engineers I know are over 50
Survivorship bias? Perhaps all the bad 50-year-old programmers transitioned out or became "incompetent dinosaurs" in low-challenge areas where you can't easily see them.
Technology moves so fast that I'm not sure it even pays to become the actual expert anymore, most of the time. When I was younger I'd work 40 hours a week and spend at least 40 more becoming expert. It paid off and got me to the Senior level. However, all the technology I was an expert at 20, 15, and even less than 10 years ago is useless.
When hiring I usually looked for guys that were smart and could quickly learn new things or jacks of all trades. Now if trying to write new kernel drivers maybe I'd get a Kernel/C expert who values himself at 120k/year (probably contract so I could use him for a month or two). But, lets face it most of the time companies want to hire the 3 smart enough guys at 80k/year than 2 geniuses at one specific language or technology. At least that has been my experience, then again, I usually work at normal smaller/midsize and non tech large companies. I'm sure if you work at Google your experience would be very different.
The point is I don't care about being the expert anymore as it requires a lot of my unpaid personal time. Then after investing my time for free I find the tech trending down and have to go back to the drawing board again.
I used to think this 20 years go. I was also wrong.
The state of the art of software development does NOT move fast, it moves glacially slowly. The fundamental technologies of 20 years ago are very similar to what is in use today. The tools are similar, the languages are similar, the frameworks and libraries are similar. Mostly, they have simply now more polished and have a few more features.
A handful of things that were leading edge 20 years ago have gained popularity. These include things like object frameworks, event-oriented programming and the like. Some things that some call new are actually things that existed in the 80's that have just come back into fashion. Take asynchronous programming using callbacks (popular with javascript/node). We used these techniques in the late 80's quite extensively. There are a few things on the leading edge today that did not exist decades ago (or at least I wasn't aware of them). But these are far and few between. The basics though, those have not changed.
What changes rapidly is tech fashion (for want of a better phrase).
When I hire, I simply do not care if you know framework X or Y. Or even if you know language P, Q or R. What I care about is if you 1) truly understand the fundamentals and if you can 2) apply that knowledge to create high quality software.
Technology moves so fast that I'm not sure it even pays to become the actual expert anymore
Don't master the 'surface' technology, master the underlying concepts. For example, rather than trying to master this week's cool machine learning library, master the underlying mathematics and you'll not only be far ahead of most people who only mastered the library, but you'll happily be able to transfer your skills to the next machine learning library with minimal effort for the rest of your career.
I think the big picture hasn't changed that much over the last 20 years. Obviously the scale has changed but the fundamental challenges are pretty much the same. The only thing that has changed is the language/framework on top but the basics are still the same. It always surprises me how little really changes.
I have many years experience with all aspects of Excel, including VBA and I understood Excel better than anyone else I knew. At one stage I had the arrogance to think of myself as an expert in Excel. Fortunately, I changed companies to work at a hedge fund and realized, with some shock, that I was very far from an expert in Excel. Those guys were doing things with Excel that made my jaw drop. I had got complacent and thought I knew everything that was worth knowing.
The funny thing was that this was not the first time this had happened to me. I underwent a very similar experience with C programming. I had read all the books, thought I understood everything there was to know about the language, then got exposed to some real C experts at a small high-tech company. That was a humbling experience as well.
Needless to say, after getting humbled twice, I will be very careful before I ever call myself an expert at anything in the future!
I'd be interested to know what sort of things you saw the hedge fund employees use Excel for. I'm probably at that 'local maximum' point with Excel, and would be interested in knowing what areas I could look into to further my skills. The only 'growth area' I'm currently considering is Apps for Office.
I recommend reading the whole series of posts; I am only part way through, but it has been very enlightening.[0]
Getting out of this trap is what motivated my first two job changes. I think there are a few things that are useful in staying on the narrow, difficult road to true expertise[1]:
- Engagement with the wider technology community. You need to know where the global maxima are
- An insistence on objective measurement and argument, rather than subjective assessment
- A low tolerance for cognitive dissonance or sacrifices in quality to meet a deadline
- A willingness to follow through and see the fruits of one's labor
- As a corollary to the previous point, an insistence on shortening the feedback cycle as much as possible
- Actively working to make it safe for others to criticize you and a willingness to say "I don't know" (in case you didn't know, criticizing others is genuinely very frightening for most people)
- Greater graciousness towards subordinates, less towards superiors (the reverse of typical corporate culture)
[1] Not that I am an expert, just that I know I'm not an expert; and that I have met enough of both real experts and expert beginners to tell the difference.
Also, I have a hypothesis that Impostor Syndrome is the last defense of the rational mind against the descent into Expert Beginnerism. It certainly saved my bacon[0]. Listen to those doubts and seek out a mentor or a new job.
[0] In the sense of "How in the hell did the success of this project end up resting in my hands?" or "Why am I making fundamental revisions of the architecture?"
Published 3 years ago?? I thought he was commenting on whats going on now...
I think a great example of my issue with this is my father and I. He taught me the basics and got me to the Adv Beginner stage which allowed me to progress on my own. However, I chose web and he stayed with .NET for a long time. Only after a lot of pushing he started doing web like 5-6 years ago.
I, an expert beginner at the time (and probably still), thought I was way better than my dad. How could this guy not be better than me already? No answers to my questions. etc. In hindsight, yea I was better but his experience meant he learned things I never did cause I never knew I need them. HE also knew things from his several decades of experience that let him think through problems or only accept a certain level of quality in his work that let him solve and deliver things much better than what I can/could.
That said, we argued a lot about things. A father and son like us can have those debates, some times a little too heated, and be okay. But, if I was hiring I would be cautious (not opposed) about brining on people who would be too opposed to the way things are. The problem is that we (humans) avoid conflict and begin to play politics. If they don't avoid the conflict then we have open hostility. Either way, groups start forming a them/us mentality takes hold instead of the company working as a whole. Thats basically my general fear if I was in a position to hire. Thats what I feel "bad culture fit" would mean.
I see this a lot in large enterprise environments. You have the "one person" or "few people" who implemented something 10 years ago and those architectural decisions are then re-implemented in any new project.
Because that person has knowledge of legacy and carries it over to new, they are compensated and promoted accordingly. Meanwhile any new ideas or better designs are sometimes dismissed because they're outside the comfort zone of the development team that has a collective 50+ years experience in that company.
Of course, many of us are resistant to new ideas regardless, but I see this pattern play out most often at large organizations.
Which is part of why startups can be successful, right? If large cos took the same risks and did the same things as startups, startups would not exist.
The "expert beginner" concept almost gets it right, but it needs a little tweaking. The key insight is that growth stalls out when people lock into a sub-par set of habits ... and then spend years perfecting this not-so-good approach.
I've seen the same thing happen with journalists (oh, my God, it is chronic and horrible there), and with chess players, musicians and all sorts of other specialists at various crafts and creative skills. These people trap themselves with habits that prevent them from ever being great, yet are just marketable enough that they can earn a living for a long time.
The rot doesn't always set in exactly at the "advanced beginner" stage. It occurs whenever people's willingness to rebuild their game disappears, or whenever they fall under the sway of a mentor/boss who demands conformity to B-minus work practices.
I like this article. I think im somewhere between the "competente" and "proficient" level learning and working with C++ and CUDA/C. As long as you dont consider yourself "an expert", you`re good. Experts are rly rare and otherwise you are most likely an expert-beginner stuck in the dead-end of the fork.
Two things i may add:
1.) I think the only way out (beside getting help from others) of the expert-beginner dead-end is through gaining more knowledge, instead of gaining more experience.
2.) In applications, theres a massive, i call it "invasion" of "experts", just because everyone is claiming to be an "expert", not to be sorted out by HR. HR is most likely not a domain specialist in programming stuff. Now, given you state in your CV, you are "proficient", but an "expert-beginner" states "hes an expert", your kicked out of the interview stage. What a mess!
There is a time-salary curve where it's socially acceptable to be a beginner. If your years of experience or salary are great enough, it takes a very honest, humble, and rare person to say "Look, I see and hear everything you're showing me. I clearly have no idea what I'm doing. Help."
The most important part of the article is this:
> ...and for whatever reason doesn’t have much interaction with peers?
At some point you need to be shown what you don't know, and it's very rare for that to be a self-guided learning experience.
It's a u shaped curve though, sufficiently experienced people actually gain reputationally by admitting lack of expertise in a particular area. Only really works though if you're already respected for something else.
If you want to break out of the 'Expert Beginner' mindset, here are some helpful things that can challenge you to grow:
- commit one new mistake every day
- read about a theory, concept, model, or idea you didn't know before
- look up the history of one tool, language, or software package you rely on and learn a little more about it
- look up, and read at least one page in documentation for a tool you use
Making a daily habit of some or all of these tasks will force you out of your plateau. There's no telling in which direction your learning will grow - but it's hard to stay stagnant in your skills when continually exposed to new ideas. So make a habit out of exposing yourself to, and generating new ideas!
Can someone propose a test or at least some heuristic to check if you, yourself haven't fallen in that pit? Because this seems like something that would be very easy to diagnose in others, but almost impossible to see in yourself.
The people I know that have fallen into this trap tend to have a lot of hubris and arrogance. They probably couldn't even fathom the notion that the label might be applicable. If you're even asking the question, I'd say there's a good chance that you're safe.
More practically: As stated above, if you think you're the most competent person in the room, start looking for other rooms. You don't necessarily have to find new employment to do this—attending meetups and conferences, doing a side project with others, etc. can provide a barometer of where you stand among a wider community.
I propose to study technical literature. Study advanced books at a university library. If what is written inside is new to yourself AND you consider yourself an expert, you are in the expert-beginner pit.
You can't know everything there's far too much tech to keep up with; so everyone's expertise is some kind of local optimum. The question is just how local? i.e. How narrow is the pit that you're in? How filtered are the ideas that you receive?
So looking a bit wider, e.g. "meetups and conferences" if you don't already attend, might help.
Beyond that, look at people working in parallel programming languages - What is the main alternative to the languages that you use daily? And how do the people there do things? In what ways is it better?
Maybe: have you recently questioned whether doing X is the best approach for a given problem,and possibly investigated alternatives or sought input from others? For 'simple' things this still applies, even if your day job has unsexy issues.
> They’ve officially become Expert Beginners, and they’re ready to entrench themselves into some niche in an organization and collect a huge paycheck because no one around them, including them, realizes that they can do a lot better.
I think article is a bit naive. Nerds love learning for sake of it, but that is not usual. In what way the Expert Beginner could do better? Collect even bigger pay check? Or do less work for the same salary? Being N times better developer does not usually bring N times more rewards.
I have seen this happen several times. Some, not all, programmers and IT professionals are nerds as you describe them. In most Professional positions I have held, maybe 1 in 50 people programmed outside of work and maybe 1 in 20 chose to learn beyond the minimum required to get by.
Startups seem to have more of these types and big companies, fortune 500 sized seem to have almost none.
As for how it betters oneself to learn, you cannot know until you learn it. The new tech exists because someone tried to solve the problems of the past, sometimes it works. You can't know the benefits of object oriented or functional programming if you are still writing the same cobol you did in the past or for a more modern analogy you will need to stand up more apache servers to get the same throughout if you have never learned about nginx.
At jobs like this article is referring to, we need to remember that you’re never going to improve in life if you keep competing with people who stink. No offense, those who are not well versed. You gotta challenge yourself. If you don’t, complacency sets in. And bad things happen when you become complacent.
[+] [-] eranation|10 years ago|reply
But at companies who are employing the top 5% of the top 5% you will probably won't even make the first round of phone screens.
Get out of your comfort zone, and simply learn something new. Go wide, go deep or go both just realize that the moment you feel you are an expert on something it just means you are probably just ready to start learning it for real.
tl;dr Knowing more than your peers doesn't make you an expert. You are at a local maximum and you need to look at the big picture to avoid being stuck there forever
[+] [-] devonkim|10 years ago|reply
It is very important to recognize that "comfort zone" also means you must have room to fail, which is actually tough for companies to hire for because most companies are actually super risk averse when it comes to hiring. Why else would they want to hire people that know as much about their stack as a filter before asking questions about their potential?
I went (foolishly, in hindsight) into areas on the thesis that a lot of organizations simply need some motivation from one or two highly capable people to raise the standards for everyone and that this form of leadership would be a good career path because people are oftentimes rewarded quite well for saving failing / ailing companies. Instead, I was beaten severely for trying to do create too much change for people that just wanted to a 9-to-5 job or (more importantly) given no projects with any risk or even much value even if it succeeded.
I've come to realize that organizations without risk or without any sense of leaving their comfort zones are the same thing as people - these are beginner-expert organizations. These are companies who implement a working Hadoop cluster in production and give themselves a big pat on the back... in 2015. These are companies that implement some CMDB... in 2014. These are companies that are rolling out SOAP services seriously on a roadmap... for 2018. The aversion to risk leads inevitably to worse results than if you had accepted some failures, but this only makes sense anyway when your organization is capable of speed. And this becomes the ultimate chicken and the egg problem with large companies. My answer is that you must break your egg to create a new chicken - if you do not sacrifice something, you will lose everything for sure.
[+] [-] kdamken|10 years ago|reply
At my last job I was the only developer at a small web agency, along with a designer and a project manager. Basically every problem and solution I had to figure out myself, and while I did that, due to time constraints I often had to go with just what worked, rather than figuring out the best of all possible options.
At my current job, there are developers who know a lot more than me, and in the time I've spent working with them I've found I learn so much more so much more quickly than I did when I was working on my own.
[+] [-] baldfat|10 years ago|reply
I liked Steven Covey's 7 Habits take on this much more "Sharpen the Saw." This approach and wording puts all the blame on those around you. That is very good to think your above those around you and that you are above average.
A) Nothing wrong with average half the people are below average
B) Rating someone top 5% is totally a perception unless your in something that can be measured easily (Think fast 100m Dash or the author's bowling)
C) Having hired dozens of people for different jobs I can tell you that my top 5% at higher usually ended up being drama and the one person I just hired because I needed a body ASAP ended up being hands down my best employee. (Look at how Google has changed their hiring practices because hiring is close to impossible to get right, think NCAA Brackets)
D) Self-deception - Everyone believes their kid is above average and self-delusion inflates our own self-assessment. Blaming those around you give you a great out of self-responsibility.
[+] [-] Delmania|10 years ago|reply
Ultimately, I'm looking to make the leap into a more challenging job, but for now, these will have to do.
[+] [-] kafkaesq|10 years ago|reply
But at companies who are employing the top 5% of the top 5% you will probably won't even make the first round of phone screens.
There's so much noise, context, and (as you acknowledge) subjectivity in how performers are evaluated that a statement like "We hire only the top .25%" can't possibly have any meaning. Top 5% might be about as far as you can push it. But even at that level, at best it's just a metaphor. And by itself, it doesn't provide us with any tools to reliably determine membership in that category.
Other than, of course, the tried-and-true method of throwing out a series of hoops for people to jump through over the phone, on your live coding portal, and at the whiteboard (ignoring all the built-in selection biases in this process: from whether candidates had had that very problem fed to them in another interview somewhere; to whether they spent 3 weeks to 3 months doing nothing but prepping for your hoops, day and night; to the simple matter of whether they're having a good day that day).
And then stack-rank: "See, only 5% of email applicants made it through our phone screen and take home test (which we had to re-design midway through because we realized we weren't stating the requirements properly, but whatever). Then we brought in 10 or so of those for interviews, until basically we got tired of interviewing and decided we had to hire someone. Ergo, we only hire the top .5%."
[+] [-] alexeiz|10 years ago|reply
What are those mythical companies? Really, I'd like to know. Name a few.
[+] [-] allsystemsgo|10 years ago|reply
[+] [-] tunichtgut|10 years ago|reply
(improvement is always welcome, but be careful flipping corporations)
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] sklogic|10 years ago|reply
[+] [-] mcbrown|10 years ago|reply
This is why I (for one) am strongly biased towards hiring older developers.
[+] [-] Karunamon|10 years ago|reply
With age comes experience and also comes a strengthening of biases. Older people, so the stereotype goes, are inflexible and set in their ways, if very experienced in those ways.
It's not really paradoxical, it just depends on what tradeoffs you're willing to make as the person responsible for hiring, which depends on your line of business. There are few things more tiresome than someone making mistakes you already made two decades ago and tried to warn about, and the same applies to someone ignoring the new and improved ways to get things done just because they've always done it that way and know it the best.
[+] [-] Terr_|10 years ago|reply
Survivorship bias? Perhaps all the bad 50-year-old programmers transitioned out or became "incompetent dinosaurs" in low-challenge areas where you can't easily see them.
[+] [-] dsmithatx|10 years ago|reply
When hiring I usually looked for guys that were smart and could quickly learn new things or jacks of all trades. Now if trying to write new kernel drivers maybe I'd get a Kernel/C expert who values himself at 120k/year (probably contract so I could use him for a month or two). But, lets face it most of the time companies want to hire the 3 smart enough guys at 80k/year than 2 geniuses at one specific language or technology. At least that has been my experience, then again, I usually work at normal smaller/midsize and non tech large companies. I'm sure if you work at Google your experience would be very different.
The point is I don't care about being the expert anymore as it requires a lot of my unpaid personal time. Then after investing my time for free I find the tech trending down and have to go back to the drawing board again.
[+] [-] rmah|10 years ago|reply
The state of the art of software development does NOT move fast, it moves glacially slowly. The fundamental technologies of 20 years ago are very similar to what is in use today. The tools are similar, the languages are similar, the frameworks and libraries are similar. Mostly, they have simply now more polished and have a few more features.
A handful of things that were leading edge 20 years ago have gained popularity. These include things like object frameworks, event-oriented programming and the like. Some things that some call new are actually things that existed in the 80's that have just come back into fashion. Take asynchronous programming using callbacks (popular with javascript/node). We used these techniques in the late 80's quite extensively. There are a few things on the leading edge today that did not exist decades ago (or at least I wasn't aware of them). But these are far and few between. The basics though, those have not changed.
What changes rapidly is tech fashion (for want of a better phrase).
When I hire, I simply do not care if you know framework X or Y. Or even if you know language P, Q or R. What I care about is if you 1) truly understand the fundamentals and if you can 2) apply that knowledge to create high quality software.
[+] [-] dagw|10 years ago|reply
Don't master the 'surface' technology, master the underlying concepts. For example, rather than trying to master this week's cool machine learning library, master the underlying mathematics and you'll not only be far ahead of most people who only mastered the library, but you'll happily be able to transfer your skills to the next machine learning library with minimal effort for the rest of your career.
[+] [-] maxxxxx|10 years ago|reply
[+] [-] sklogic|10 years ago|reply
I've heard this many times before, but have not seen any evidence yet. Mind listing the technologies that got really, totally obsolete?
[+] [-] SeanDav|10 years ago|reply
The funny thing was that this was not the first time this had happened to me. I underwent a very similar experience with C programming. I had read all the books, thought I understood everything there was to know about the language, then got exposed to some real C experts at a small high-tech company. That was a humbling experience as well.
Needless to say, after getting humbled twice, I will be very careful before I ever call myself an expert at anything in the future!
[+] [-] ZenoArrow|10 years ago|reply
[+] [-] lliamander|10 years ago|reply
Getting out of this trap is what motivated my first two job changes. I think there are a few things that are useful in staying on the narrow, difficult road to true expertise[1]:
- Engagement with the wider technology community. You need to know where the global maxima are
- An insistence on objective measurement and argument, rather than subjective assessment
- A low tolerance for cognitive dissonance or sacrifices in quality to meet a deadline
- A willingness to follow through and see the fruits of one's labor
- As a corollary to the previous point, an insistence on shortening the feedback cycle as much as possible
- Actively working to make it safe for others to criticize you and a willingness to say "I don't know" (in case you didn't know, criticizing others is genuinely very frightening for most people)
- Greater graciousness towards subordinates, less towards superiors (the reverse of typical corporate culture)
[0] http://www.daedtech.com/tag/expert-beginner/
[1] Not that I am an expert, just that I know I'm not an expert; and that I have met enough of both real experts and expert beginners to tell the difference.
[+] [-] lliamander|10 years ago|reply
[0] In the sense of "How in the hell did the success of this project end up resting in my hands?" or "Why am I making fundamental revisions of the architecture?"
[+] [-] 0xCMP|10 years ago|reply
I think a great example of my issue with this is my father and I. He taught me the basics and got me to the Adv Beginner stage which allowed me to progress on my own. However, I chose web and he stayed with .NET for a long time. Only after a lot of pushing he started doing web like 5-6 years ago.
I, an expert beginner at the time (and probably still), thought I was way better than my dad. How could this guy not be better than me already? No answers to my questions. etc. In hindsight, yea I was better but his experience meant he learned things I never did cause I never knew I need them. HE also knew things from his several decades of experience that let him think through problems or only accept a certain level of quality in his work that let him solve and deliver things much better than what I can/could.
That said, we argued a lot about things. A father and son like us can have those debates, some times a little too heated, and be okay. But, if I was hiring I would be cautious (not opposed) about brining on people who would be too opposed to the way things are. The problem is that we (humans) avoid conflict and begin to play politics. If they don't avoid the conflict then we have open hostility. Either way, groups start forming a them/us mentality takes hold instead of the company working as a whole. Thats basically my general fear if I was in a position to hire. Thats what I feel "bad culture fit" would mean.
[+] [-] supergeek133|10 years ago|reply
Because that person has knowledge of legacy and carries it over to new, they are compensated and promoted accordingly. Meanwhile any new ideas or better designs are sometimes dismissed because they're outside the comfort zone of the development team that has a collective 50+ years experience in that company.
Of course, many of us are resistant to new ideas regardless, but I see this pattern play out most often at large organizations.
[+] [-] brianwawok|10 years ago|reply
[+] [-] GCA10|10 years ago|reply
I've seen the same thing happen with journalists (oh, my God, it is chronic and horrible there), and with chess players, musicians and all sorts of other specialists at various crafts and creative skills. These people trap themselves with habits that prevent them from ever being great, yet are just marketable enough that they can earn a living for a long time.
The rot doesn't always set in exactly at the "advanced beginner" stage. It occurs whenever people's willingness to rebuild their game disappears, or whenever they fall under the sway of a mentor/boss who demands conformity to B-minus work practices.
[+] [-] tunichtgut|10 years ago|reply
Two things i may add:
1.) I think the only way out (beside getting help from others) of the expert-beginner dead-end is through gaining more knowledge, instead of gaining more experience.
2.) In applications, theres a massive, i call it "invasion" of "experts", just because everyone is claiming to be an "expert", not to be sorted out by HR. HR is most likely not a domain specialist in programming stuff. Now, given you state in your CV, you are "proficient", but an "expert-beginner" states "hes an expert", your kicked out of the interview stage. What a mess!
[+] [-] moomin|10 years ago|reply
[+] [-] debacle|10 years ago|reply
The most important part of the article is this:
> ...and for whatever reason doesn’t have much interaction with peers?
At some point you need to be shown what you don't know, and it's very rare for that to be a self-guided learning experience.
[+] [-] Mvandenbergh|10 years ago|reply
[+] [-] err4nt|10 years ago|reply
- commit one new mistake every day
- read about a theory, concept, model, or idea you didn't know before
- look up the history of one tool, language, or software package you rely on and learn a little more about it
- look up, and read at least one page in documentation for a tool you use
Making a daily habit of some or all of these tasks will force you out of your plateau. There's no telling in which direction your learning will grow - but it's hard to stay stagnant in your skills when continually exposed to new ideas. So make a habit out of exposing yourself to, and generating new ideas!
[+] [-] golergka|10 years ago|reply
[+] [-] organsnyder|10 years ago|reply
More practically: As stated above, if you think you're the most competent person in the room, start looking for other rooms. You don't necessarily have to find new employment to do this—attending meetups and conferences, doing a side project with others, etc. can provide a barometer of where you stand among a wider community.
[+] [-] tunichtgut|10 years ago|reply
[+] [-] SideburnsOfDoom|10 years ago|reply
So looking a bit wider, e.g. "meetups and conferences" if you don't already attend, might help.
Beyond that, look at people working in parallel programming languages - What is the main alternative to the languages that you use daily? And how do the people there do things? In what ways is it better?
[+] [-] riffraff|10 years ago|reply
[+] [-] jkot|10 years ago|reply
I think article is a bit naive. Nerds love learning for sake of it, but that is not usual. In what way the Expert Beginner could do better? Collect even bigger pay check? Or do less work for the same salary? Being N times better developer does not usually bring N times more rewards.
[+] [-] sqeaky|10 years ago|reply
Startups seem to have more of these types and big companies, fortune 500 sized seem to have almost none.
As for how it betters oneself to learn, you cannot know until you learn it. The new tech exists because someone tried to solve the problems of the past, sometimes it works. You can't know the benefits of object oriented or functional programming if you are still writing the same cobol you did in the past or for a more modern analogy you will need to stand up more apache servers to get the same throughout if you have never learned about nginx.
[+] [-] debacle|10 years ago|reply
[+] [-] girkyturkey|10 years ago|reply
[+] [-] ourmandave|10 years ago|reply
Kurt Cobain