How Developers Stop Learning: Rise of the Expert Beginner (2013)
daedtech.com
daedtech.com
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
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.
Any examples you can share?
For instance. . . .
After leaving a very small local company I was working at, this is what I found after doing a few months of research and interviews:
I had several interviews, every single one for a front-end role. They ran the gamut of JS frameworks. Do you know Backbone? AngularJS, Polymer, Typescript, ReactJS? A combination of some? or none at all? Not a single interviewer asked me about jQuery or my "vanilla" JS skills - NONE. Every company big and small was using some kind of framework, in some capacity - albeit in vastly different ways.
The point here is there's no way for you to predict how your next great learning experience is actually going to help you down the road. Our landscape is changing virtually by the hour. I have now given up on trying to have a learning opportunity whereby I can add some really good skills to my resume not only for now - but for future opportunities.
It's made me a bit jaded that our industry is so fragmented that even by learning a new library or framework, you effectively remove yourself from consideration from a host of companies because you didn't pick the "sexy" framework
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.
(improvement is always welcome, but be careful flipping corporations)
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 isn't necessarily true. Imagine a system where we could rate developers. There are 4 'A' developers (92,95,97,91) and 2 'B' developers (83, 85). Only 1/3 of the developers are 'below average' as compared to below median, and flip those numbers around and 2/3 are below average. This is kind of important when evaluating the type of company culture that you're in. Is it a place where there are a lot of 'top 5%' developers, and a short tail of good, but not great developers. Or is it a place where there are just one or two developers that doing 'A' work, but a long tail of developers doing solid, but not great work. The 'average' could be misleading in these cases.
Average = Average you have 100 developers 49 and below are bellow average :P
Not exactly. Average is defined as the 50th percentile, which if you have 100 developers, and can (objectively) rank them in order from 1 to 100, then there is a chance that 49 and below are not "average" or "worse than average." Consider a sample distribution where all 100 employees rank exactly the same. Now all 100 are average. Consider a sample distribution that takes on a bi or tri-modal form, where employee groups cluster at certain knowledge or experience levels. Here you might find that "average" is hard to quantify, as it is not well defined when your distribution does not follow "normal" rules.
We are talking rank so top person ranked 10,000 and the bottom is 1. 10,000 - 5,000 are Above Average and the 4,999 to 1 are Bellow Average.
What you showed was some abstract numbers that have nothing to do with ranking.
But even assuming it's a ranking - in a ranking there's possibility of equal rankings, right?
So, you can have rankings [1, 1, 1, 1, ..., 1, 10000], and the "average=median" assumption is violated again.
Most real-world distributions have different average and median values, the "50% is below average" is a common misconception that should be cleared out.
For one important example see average salary - huge majority of people in (almost) every country earn less than average salary in that country.
EDIT: Oh I think you looking at this like average house hold income with Bill Gates throwing off the average possibly? Well we are talking about only one thing and that is the skills of a programmer compared to the skills fo other programmers. Just the same as the average math skills of children. This is why we have percentiles and my argument still holds on. Skills are not like money where one person has $60,000,000,000 and another has $100.
> the turning of something abstract into a concrete thing or object
We're talking abstractions from the start. The only abstraction all my posts here rely on is the assumption that skill level is 1-dimensional. And you started using that assumption (by referring to average developer).
Real world example:
There are 10000 programmers. Many of the programmers that are just starting to learn have similar skills to each other. Some of them work for a few years already. Their skill levels start to diverge. Many of them never develop their skills too much (because they never need to and aren't self-motivated enough). Some of the programmers got lucky, work in places that allow/require them to learn forever, and become very, very good. There are few of them, and their skills vary widely.
There are tons of people near the bottom, and very few people near the top. It's natural consequence of the amount of work and focus it takes to move from the bottom to the top.
Ranking them hides some of the differences, but not all (because it's much more common for people to have the same rank near the low end of the spectrum, where there is much more of them, than near the top - where there is just a few people separated by big gaps). So, when you took ranks from these people you would get sth like below (1=worst, 10000=best, if your ranking works the other way - reverse it it still works the same)
[1 (repeated 20 times), 2 (repeated 15 times), 3 (repeated 10 times), 4(repeated 5 times), ..., 100, ..., 10000] - so the distribution would still be skewed and the average would still be different from the median value.
Real world example: It is still an non-measurable skill set.
> so the distribution would still be skewed and the average would still be different from the median value
You also mixing up vocabulary your still taking average = mean BUT average also means median.
Here is real world ranking of skills (Math, Science, English and Reading) http://blog.prepscholar.com/act-percentiles-and-score-rankin...
Once again what scores are you comparing? When I went to Graduate School I had to do GRE and MAT test and I needed to be over 70% percentile on the test just to be average in my field of study (Theology (highest of all fields of study while Education had one of the lowest scores which makes me laugh) This had HUGE implications on my later PhD program acceptance. I couldn't say I was above average in my field because I scored really high. I had to be better then well over 75% of the people taking the test in my field of study. Just because there are a ton of beginners that start and leave that doesn't mean that there isn't a middle and that middle ground will have great skills above the learners. I counter the argument on this paper discounting average developers and placing the blame on their co-workers and environment. Average workers are not to be looked down on.
What is the average fruit from a set of 10 different apples and 3 different oranges?
It was your assumption that skill level of 2 developers can be compared.
And it's not an useless theorethical distinction. In lay terms: most programmers are worse than average skill level of all programmers.
I even showed you real world example. IT is growing very fast, so most people are beginners.
I'm not trying to look down on anybody. Being better developer doesn't mean you are a better person, and I'm not above average IMO anyway.
EDIT: I looked it up (I'm not native English speaker), and you were right about the math terminology. In Polish average=mean=średnia. Damn false friends. So, if you meant average as median I agree.
Due look at the link for ACT Test (For college admission) this kind of shows how to make an average of skills and rank them with a population group. In statistics you can do just about anything and it can be scary but there is always a middle and it just depends on your decision on what is the best tool to use.
Have a great day.
How has Google changed their hiring practices?
Ultimately, I'm looking to make the leap into a more challenging job, but for now, these will have to do.
What are those mythical companies? Really, I'd like to know. Name a few.
RenTec is a hedge fund that has done something like 30% annual gains over like 30+ years.
But can someone tell us where, exactly, this top .25% figure comes from? Other than the swirling mass of air about their heads, as they typed it?
I'm not asking this to be snarky. It's just that people keep talking about the "top .1%" as if it's not just a thing, but a quantifiable, measurable thing. It's neither, of course; basically it's just a hunch people have. With an arbitrary number slapped on it to make it sound more, you know... authoritative.
Meanwhile, some stories of the top .25% at Jane Street, getting busy at the task of finding the other top .25%:
My interview is scheduled at 10:00am. However, I wait until 10:15am but no one called. Then I received an email saying the interviewer was wrapping up with an issue and he would call around 10:30am. Then I wait until 10:45 am still no one called. I received another email saying he was still working on the issue and will call in a minute. Then I continue to wait to 11:15am.…
Another:
They ended up calling 40 minutes late, the interviewer was very incompetent at even asking the questions. I found it very unprofessional and chose to not move on in the interviewing process after speaking with friends who told me this was not uncharacteristic of them.
Source: glasdoor.com
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%."
This is why I (for one) am strongly biased towards hiring older developers.
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.
Like most stereotypes, it might be true in some cases but far from universal. The literal two best developers I know, both over 50, are FAR from set in their ways. They are both constantly seeking new ways of doing things, exploring new languages and technologies, sometimes playing with low level projects (like making lights blink in interesting ways on breadboards), sometimes playing with high level projects (spawning hundreds or thousands of cloud instances to see how it works), but always looking for new things.
They might SEEM set in their ways when they shoot down bad ideas from expert beginners, but that's only because the expert beginner is confusing wisdom for lack of flexibility.
I'm a musician. I've been playing guitar since I was a teenager. As a technician, I've peaked out. I will probably never play faster, cleaner, or more complex than I do now. If anything, I'll start to go downhill as age takes its toll on my hands. But as a musician, I'm always getting better. I'm growing more conscious, more sensitive, more subtle, more sophisticated. I'm a better musician now than I was a year ago, and a far better musician than I was five years ago.
There's a similar thing in software. When you're still learning, still approaching real expertise, it's easy to think that being a great software engineer is about technique. It's not. I know a bunch of over-50 programmers. Sure, many are basically dead in the water, but many are not, and are constantly improving. It's not because they learn a new language, or a new framework. It's because they learn better taste. They learn more and more what is and is not important, how long things will take, best use of resources, translating requirements more effectively... these things will all make you a better engineer than writing glorified Hello Worlds in framework-of-the-month ever will.
In the end the real 'problem' with older developers is they expose problems with your organization by providing what you ask for. If you keep asking for tight deadlines thinking people are going to ignore them you squeeze out creativity.
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.
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.
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've heard this many times before, but have not seen any evidence yet. Mind listing the technologies that got really, totally obsolete?
So often I see the next great thing hype turn out to be a reinvention of an existing concept, or a slight rearrangement of concepts that are positively ancient. Sometimes this includes an incremental improvement over the past.
A lot of the velocity of "tech moves fast" is just backfilling tooling, features, concepts, and edge cases into the new language or framework.
Here I am now working entirely with the AWS infrastructure. First we shoved things in Puppet. Then we started shoving things in Git and using Ansible. Maybe development wise things don't seem that different but for an old ops guy like me having to go devops it is changing very fast.
I never said that old technologies are obsolete but, jobs for supporting them fade and we must learn to survive in the new world.
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.
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!
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.
[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?"
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.
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.
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.
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!
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.
- 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!
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.
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?
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.
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.
Double signed. Barely anyone is using his free time to learn more than needed at the workplace (which means the employees are stuck at the "minimum knowledge level"). And this is not just true for the IT branch.
One the one hand it made me feel a bit less stressed and a bit more confident about my own abilities. On the other hand it was a warning for me to keep trying to find the fun and challenge in my work, to treat it like a craft and not just a job, because every single one of these developers seemed to me to have relatively low job security, and I couldn't imagine many other companies hiring these people...
Kurt Cobain