
How Developers Stop Learning: Rise of the Expert Beginner (2012) - DerCommodore
https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/
======
dorkwood
I feel like a lot of people here are missing the point of the article.

I've worked with several 'expert beginners' over my career. They think they're
near the skill ceiling, but they're actually much closer to the bottom. They
rose through the ranks despite not being particularly great at their jobs, and
now find themselves having to indoctrinate others into their way of doing
things. Any suggestion on how to improve the process is usually met with some
form of "that's not how we do things around here", since the expert beginner
feels threatened.

Preventing yourself from becoming an expert beginner doesn't mean you have to
dedicate all your spare time to learning 200 different technologies, as some
here have suggested. It's more about accepting that learning is a life-long
practice. Knowing that less experienced coworkers still have things they can
teach you. Understanding that there is still so much out there for you to
learn, and being humble about that fact.

~~~
lliamander
Indeed. For every new job, new project, and new professional relationship, you
have to be willing to ask yourself "what can I learn from this experience?"
Learning is often best done when you are working on problems you don't yet
know how to solve.

But there is a countervailing force, which is the pressure to appear confident
and that you know what you are doing. Being transparent about your ignorance,
but confident in you're ability to learn is a difficult balance to pull off.

------
lmilcin
I personally think there are multiple reasons for this situation.

* It is fun to learn initially, to see something new working. Once you get something working not many people see fun in spending a lot of time in getting it to work better.

* There is huge amount of introductory materials (guides, tutorials, examples) but the amount of available materials falls drastically as you start to progress.

* Only some people are able to actually think in abstract terms required to "create" new knowledge based on existing facts. Beginners can advance quickly by "recreating" \-- executing tutorials, copying existing code, etc. It is relatively easy to use these as building blocks for a simple application. But as you progress you have to figure out more and more new knowledge, understand underlying principles. This is what many people either don't feel comfortable doing or don't feel is necessary to do or are just plainly incapable.

* It gets more difficult to work with other people in your team as you create knowledge in a given topic. There is tendency to push back when team member tries to introduce something new that is not clearly recreation of accomplishment of somebody else available on the Internet.

* Creating new knowledge in the topic is a huge risk in that it is unknown payoff for large amount of honest work. There is not much risk in following existing tutorials, it is pretty much guaranteed that it is possible to recreate accomplishment others did. When you create new knowledge (for example new patterns, principles, guidelines) it is likely you are going to make mistakes. This fact may cause people uneasy and dissuade them from further advancement in the topic.

* Getting mediocre in any specific topic is frequently seen as good return on investment. For example, as an architect I would maybe not want to get expert at any of the frameworks I know. I see this as a reasonable tradeoff which allows me to tackle other problems as soon as I think I know "enough" about particular topic.

~~~
blaser-waffle
> * There is huge amount of introductory materials (guides, tutorials,
> examples) but the amount of available materials falls drastically as you
> start to progress.

Aye. My coworker described it as being able to find 100 guides on how to
hammer nails and build a small bench. "Shed building for beginners" or
something. But then the next exercise is "build a house" and the one after
that is "build a shopping mall".

~~~
hobs
A natural consequence of bikeshedding[0]
[0][https://en.wiktionary.org/wiki/bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)

~~~
Ma8ee
No, this is not related to bikeshedding, see your own link.

------
netcan
I like these sorts of analysis, whether I agree or not.

I've come to believe though, that they need humour. There's always a tendency
to over-extrapolate, get hung up on typologies which crack under weight and to
assume the model is the main thing going on. Humour gives them a productive
"playing with ideas" vibe, keeps it honest.

In software development, for example, I always think that demographics play a
big role. Every decade we get more young programmers than the last. Many older
programmers "graduate out" one way or another. The resulting demographics are
unusual, with a years of experience pyramid more like the military than most
professions.

Technology, methods and philosophy change rapidly. This is both exasperated by
and causal to the demographics, and the youth/pace of the field itself. A lot
of software culture has this relationship with the demographics. Maybe 60yo
developers are more likely to produce important new things, but they are
outnumbered 100-1 by 20-somethings... enforcing youth biases, etc.

I think a lot of this essays thoughts on learning might be affected by
software demographics. A lawyer, accountant or aviation engineer's thoughts on
learning and career progression probably encompasses much longer time periods.
In software, we think in much shorter timescales. Between the age of 22 & 27,
a programmer has progressed through a "career." Between the age of 22 & 27, an
accountant has progressed through a cadetship.

~~~
partyboat1586
The difference is no accountant does accountancy in their bedroom for fun as a
teenager. The software engineer who has significantly progressed their career
by 27 probably started as a teenager, not as a 22 year old. It's more like
being a musician than being a lawyer or an accountant.

~~~
netcan
There are plenty of cases where programmers only start programming for real at
a post-college job. The majority case, even.

That said, sure. There are differences in substance, history, everything.
Those might be the reason for differences between professions, but the
question is "how much?"

I think we overemphasize legible, logical reasons for culture, but often it's
incidental reasons path dependence, demographics, etc.

~~~
partyboat1586
I think that programmers who first start programming for real at a post
college job don't make significant career progression by 27 unless they are
very talented. You are looking at outliers and saying look these outliers
don't exist in accounting and law, and you would be right because very few
people in those professions are so crazy about them that they live and breath
it.

------
zubspace
_As such, Advanced Beginners can break one of two ways: they can move to
Competent and start to grasp the big picture and their place in it, or they
can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to
Expert._

I think, that viewpoint is a bit narrow. The example, where the author tells
the story how he started bowling the wrong way and reached a plateau, where he
could not further progress, is a good one. And I'm sure there are numerous
examples each one of us can tell of own experiences made when learning new
skills.

In my opinion learning new skills fast is a great skill. And nowadays there
are many resources available to us make this easy. But you will always reach a
plateau, where further progression gets increasingly difficult. It's
fascinating how this corresponds to larger patterns like the Gartner Hype
Cycle [1].

The question is, what do you do when you reach a plateau? Do you invest more
time and money? Maybe the skill level suits you well and you don't feel a need
to progress further? Maybe deeper understanding is not necessary to do your
job well? Maybe it's better to acquire different skills which you can combine
instead of being an expert in one area alone?

I think there are many nuanced answers to that question and simply put blame
on the expert beginner is not useful.

[1]
[https://blogs.gartner.com/smarterwithgartner/files/2019/08/C...](https://blogs.gartner.com/smarterwithgartner/files/2019/08/CTMKT_741609_CTMKT_for_Emerging_Tech_Hype_Cycle_LargerText-1-1024x974.png)

~~~
scarface74
_But you will always reach a plateau, where further progression gets
increasingly difficult. It 's fascinating how this corresponds to larger
patterns like the Gartner Hype Cycle [1]_

It’s not just about skill progression. To stay relevant and not be seen as an
old out of touch developer, you have to know how and when to jump on the next
hype cycle.

~~~
pjmlp
Kind of true, when one wants to be seen as "Developer in Tech X" and that is
only how they sell themselves to companies selling software solutions.

However there is also the path of understanding business domains, brushing up
soft skills and embrace being polyglot across multiple stacks, delivering
working solutions for companies that couldn't care one second what their IT
cost center runs on, as long as they stay in business selling socks or
whatever they actually care about.

~~~
scarface74
Independent consultants are the first to get cut when the economy goes bad.
Companies aren’t looking for “Enterprise Architects” and “Digital
Transformation Consultants” when they are just trying to keep the lights on.

No, you can’t be 45 years old (I’m 46) and say I understand the business
domain and I can give you a really cool VB6 Active X control to solve your
problem that only works in IE6 on a Windows XP VM.

Yes, if the CTO doesn’t care that he is using somewhat modern technology he
should be fired for incompetence. He’s going to find that he has a hard time
recruiting developers who know how to write FORTRAN for a Stratus VOS
mainframe. Yes I’m that old. Been there done that.

Saying you know the business domain but not keeping up with technology is just
an excuse that people make and then scream ageism the minute no one will hire
them because their idea of cutting edge technology is ASP.Net WebForms or
Enterprise Java Beans.

Yes, my current position is a technical consultant working remotely for Big
Tech who has to understand business problems and not just know how to reverse
a binary tree on a whiteboard. But, if push came to shove and a meteor struck
all of their data centers world wide, I could put my resume out their and get
a job with a tech stack that is at the right point on the hype curve.

~~~
OGWhales
I currently develop for mainframes and I can say they are still very relevant
today in multiple industries. For my own company, we get a lot more bang for
our buck than if we were constantly worried about the hype cycles.

>if the CTO doesn’t care that he is using somewhat modern technology he should
be fired for incompetence

A ridiculous statement. The last concern of the CTO should be "are we using
the latest tech for the sake of having the latest tech". Their concerns should
be about cost, what the business actually needs, and what the future will
entail. Finding new developers isn't that difficult, even for something like
mainframes which most college grads today are totally unfamiliar with.

Your point about being more easily hireable by staying up to date with the
current hype is true and valid. However the CTO doesn't have the same concerns
as you. This is the important difference.

~~~
scarface74
Tell that to all the states struggling to get unemployment benefits out
because they can’t find enough COBOL programmers to keep their systems from
melting....

------
ferros
When interviewing new candidates it's interesting to see the difference
between beginner/mid and seniors. The beginner/mid group seem to have a lot
more confidence in their skills and not be as aware of what they don't know.
The seniors seem to be more aware of what they don't know and maybe also a
little harder on themselves.

~~~
BossingAround
I think this is a common viewpoint, and a misconception.

I've seen a number of juniors who were very humble, and this humility was
perceived as lack of knowledge.

I've interviewed some seniors who were not humble at all (nothing was an
issue).

In general, skill level has little to do with humility and other personal
traits. However, we like to project our reasoning into other's emotions, and
we love to pattern match, e.g. "she's humble because she has 20 years of
experience".

It's another bias you should look for when interviewing candidates. This one
definitely does not serve you well.

~~~
codegladiator
> I think this is a common viewpoint, and a misconception.

Probably a common viewpoint, but definitely not a misconception.

I have had freshers tell me wrong answers which they know they are answering
wrong with so much confidence. And you keep digging them on their answer and
they would keep coming up with even more wrong stuff.

It would probably be about 2 or 3 out of 10 freshers who can say "i don't know
that".

~~~
sokoloff
I have sometimes interviewed to specifically find whether a candidate could
utter “I don’t know” (and ideally add “, but here’s how I’d handle it, find
out, learn it, etc.”)

It’s amazing (and a little amusing) how many people literally can’t admit they
don’t know something. I have “passed” some otherwise very strong candidates
who couldn’t admit that and made it a point to advise them after hiring how
dangerous that limitation is both when doing the actual work and when
interviewing. A not at all surprising fraction of them couldn’t
admit/understand they even did it, of course.

~~~
wott
> It’s amazing (and a little amusing) how many people literally can’t admit
> they don’t know something.

It is a matter of culture too.

I'll take the example of the desk clerks you have to face as a citizen or
customer in administrations and companies.

When I lived in a country of Northern Europe, they would often say "I am not
sure, wait a minute and let me check in that book" or "I don't know, I will
ask/check and call/mail you right away". And they did it and it was fine. A
tiny delay and everything is solved for good. You come out from there with a
smile and they have learned something for the next time they meet the case.

Now that I am back in my Southern European country, the guys (well, it's 99%
women) in the same position will _never_ admit they don't know or they aren't
sure of something. They will assert whatever weird/outdated/wrong assumption
comes through their mind with definite certainty. Even if _you_ gathered
information beforehand and tell them that the rule says otherwise. They feel
that checking or asking for help would undermine their authority or make them
look incompetent (as if anyone still had any hope about that...). And they
will only call the higher up when, after 2 months and the 3rd visit for
nothing except getting contradictory information and requirements, you start
yelling and they feel that they are less than 30 seconds away from getting
punched in their face. Then the higher up solves the problem (which should
never have become a problem in first place) in 2 minutes. But they will keep
on 'working' like this for 40 years, they'll never recognise that their work
and service would be much more efficient if they just said "I don't know"
instead of inventing wrong rules.

~~~
partyboat1586
How do you find yourself in so many of these on-the-verge-of-a-facepunch
situations?

~~~
barrenko
I think the Souther Europe part covers it. That's my experience as well.

------
kiba
On skill development: I mainly think of it as an exercise in emotional
management, just like procrastination, or physical activities, and so forth.

It doesn't seem to ever become easy for me. I am always running into
challenges and difficult obstacles once I overcome the procrastination issue.
I am bullhorned about it, so I'll eventually get through. That, more than any
particular strategy for learning, is the most important in skill acquisition.

Another component of skill acquisition is skill retention. You'll get rusty
when you don't practice your skills, and in enough time, you'll lose your
progress. This is probably more than anything else, a lifetime commitment so
that you don't lose your progress in the knowledge or skills you picked up, so
that in the long run you become better and better over time.

Think of it this way: You learned 10,000 useful "stable" facts about the world
one year. Next year, you learned another 10K facts. But retention is
exponential. Practice it long enough, the facts will last a lifetime.

Suppose a person have no strategy for retention. Let say he learned 10K facts,
75% decays away. Next year, he learned another 10K facts, but another 75%
decays away. So he retained only 5,000 facts, but you retained 20,000 facts.
Obviously, this is contrived, but it does illustrate why colleges and high
schools aren't very effective. It's not that they don't teach, it's that the
students forgot what they learned as soon as they finished a course.

I often get interested in a subject matter and then drop it some point. This
often result in surface understanding of the subject. Just enough to sound
smart. However the knowledge is retained. Should I ever return to a subject,
I'll retain the knowledge from scratch, as sometime I do.

Sometime I was able to keep at a subject long enough to acquire some amount of
true mastery.

~~~
nonbirithm
> the students forgot what they learned as soon as they finished a course

A lot of times this is enough to dissuade me from learning about anything I
have only a passing interest in. One time I blocked out an entire two months
out of free time after school in an attempt to learn electronics, by
assembling a commonly produced headphone amp. A month passed after classes
ramped up and I forgot almost all of it, and moreover no longer cared. I still
just don't care about electronics since then, honestly, and don't know why. So
in my book that was just two months I spent doing nothing that would
ultimately contribute to my future knowledge. I mean, it was an attempt, but
only an attempt. I never got the circuit to work in the end either. If I had
known that was the result ahead of time I would have just worked on a
programming project instead because I was better at programming and I wanted
to finish it, and also was competent enough to actually finish it.

Unsurprisingly the majority of my college education turned out exactly like
this also, but at least I got the paper in the end.

Nowadays it feels like all I care about are the things I care too much about
to ever forget, like the skills necessary for my job. As in, not knowing what
the point of learning all this is if I don't care enough to remember it after
a month. I feel this is a horribly limiting mindset for me to have, but I
don't see any way around the "not caring" part. If I know I don't care,
nothing I do to sweeten the deal like gamification or dreaming of the finished
project will ever work, because I know I'm only doing that because I don't
care, so my mind will defeat itself.

I especially don't like it because all these people around me are learning
about machine learning and all these bleeding edge technologies that are
having a material impact on the world, and I just sit there unable to care, as
if I'm somehow allergic to learning. It becomes a "so you're just going to
deny the existence of the entire field of X because you don't care and sit
around playing video games instead" kind of irrational thing. I don't know how
to resolve this, or if I even should.

One thing I will never forget is me talking to someone I knew for a long time
and asking what they were doing, and they said "learning about nuclear
fusion." For some reason I never felt brave enough to talk to them again since
then.

~~~
seer
You're totally right that "motivation" is probably the key to learning
anything. We're taught that kids have aptitude for different stuff from birth,
but I think the curiosity and intrinsic motivation parts are the most
important. If something is fun enough you spend the time to become good, and
then people say "oh how talented you are", but in reality you've just spent a
lot more time working at it.

One way I've seen I can "hack" it myself is if I stumble on things that are
actually fun and it becomes a "wedge" into an area I was too shy to try out.
For example "Kerbal Space Program" taught me way more about rocket science
than I've thought possible, but more than that, once I understood the core
concepts and could play around with them in my mind it actually did become
fun. I still remember how I was doing some hochman transfer calculations to
figure out when should I do a lunch to get to Duna (KSP's Mars) with the
limited tech I had unlocked in the game, and a sudden realisation hit me, I'm
actually doing rocket science math for a game ... This got me into reading
about rocket engines and I ended up reading through the whole of the
"biblical" Ignition book just for fun.

Now I'm a web dev and as far away from Aerospace as you can probably get and
still be somewhat of an engineer, but it opened a would of interesting news,
data, discussions and theories at the bleeding edge of science, for which I'll
be eternally grateful.

I guess what I mean is it's possible to start caring for something that's
outside of your domain expertise, you just need to find somethings that's fun
enough to keep you there.

------
greatgib
As said in one comment, PART2 (link at the bottom of the page), is where this
begin to be added value compared to the existing theory.

That being said, very great article that describe well and nicely what I have
personally experienced in a sme company that was bought by a big tech group at
some point: \- when I arrived, the core team was already there with some
having personal ties. A few beginners that took the mediocre manager as
mentor, that took himself his manager as mentor \- they learnt by themselves,
mostly there, they were responding to diverging opinion with anger. \- over
the years, a few 'outsiders' arrived and try to change things by showing the
problems and explaining that outside world do differently. \- but each of them
had to face the seniority argument reinforced by the group effect to justify
that they can't be wrong. (Listen, we are 3, you are 1, it means that we are
right and you are a pain in the ass to think otherwise. Doesn't count that you
say that out of the company are unanimous on the subject...)

The worst (almost funny) case I remember was that:

\- Person 1 (p1) and person 2 (p2) have a disagreement on how something has to
be implemented.

\- p1 is the boss favorite, so he is always right... so his solution will be
implemented. No one listen to p2 that says that it is an inefficient idea,
possibly problematic and that is why no-one does it this way outside. (No-one?
In fact they found one case over 100 of outside projects that did that, so
that gave them confirmation that they were right...)

\- p1 engine solution is implemented and p2 has to do a component working with
that, but that does not work well at all, very slow for basic operations, lots
of unexpected deadlocks and issues like that. Another manager complains about
the issues.

\- P2 decides to give a try reimplementing the engine with his solution. That
is completed is no time and it is excellent: performance x1000, no lockup, no
more issues with basic operations.

\- results are shown to mediocre manager. But instead of accepting and going
this way, he blocks the thing and can't accept that his favorite was wrong. So
says that there should be a bug in P1 implementation and give him as much time
as needed to test and look at it.

\- after 1 months, P1 did everything he could with his solution to fix it
without using the solution of P2. He comes proudly with his engine is now 10x
faster than initially.

\- but so, 10x vs 1000x is a no match, and P1 solution was still rigged with
issues. So it is finally P2 solution that is used 'out of choices'. BUT... as
manager still does not accept that he and P1 were not right. He said: ok we
use P2 solution, but you will have to embed and support P1 implementation in
the final product. Not to be used but maybe one day...

\- conclusion of the story? Evaluation time arrived. Did P2 got a good eval?
That would be logic, he saved the product, gave an important perf and
stability boost to the solution. But no, he got the worst! Manager said that
P1 had to take depression pills because of P2... Not because his solution was
wrong and couldn't accept, learn and improve from it. Buuuut: P1 got the
maximum grade!

~~~
top_kekeroni_m8
Wow, this reads like a high-school drama. Why do people put so many emotions
into their professional lives?

------
ChrisMarshallNY
I’m not sure the “10,000 hours/5 years” rule is a particularly relevant one,
these days. Tech mutates so quickly, it's near impossible to become an
"expert." Also, many developers are...how can I put this... _a wee bit
obsessive_. It’s quite possible to hit 10K hours well before 5 years.

I liked the analogy about the quirky bowling style.

That has happened to me -several times.

I’m primarily self-taught in most of my tech. It has tended to result in very
highly-developed, but narrow, skillsets. Not necessarily a bad thing, but
“brittle.” It has happened so many times, that I no longer feel that I am an
“expert.” I am now “experienced.” At least the first five letters match.

But it has been a long road to where I am now. Humility has been forced upon
me, and I now have a _lot_ of “narrow skillsets,” to the point that they
inform each other. For example, a lot of the stuff I did in PHP has helped
inform my work in Swift, and vice-versa.

I’m choosing to specialize in a specific discipline and tech stack, which,
just by itself, gives me a lot to learn. I am working to develop a “broad
base” in a small-ish venue, with a lot of “sharp peaks.”

It’s really humbling. The more I know, the more I know I don’t know. Also,
since I am constantly trying out stuff I don’t already know, I’m a perennial
“n00b.” Usually, this manifests by not always being aware of the jargon (I
know the tech, but not the name). This may result, I suspect, in my being
treated rather shabbily by folks in the field (It may also have to do with my
age. I have found that the way people treat me changes radically, as soon as
they find out that I'm "long in the tooth," so I now make it obvious to avoid
that). This has helped me to just keep my damn mouth shut, and open it only to
eat my humble pie.

I write about that here: [https://medium.com/chrismarshallny/thats-not-what-
ships-are-...](https://medium.com/chrismarshallny/thats-not-what-ships-are-
built-for-595f4ae2c284)

~~~
rimliu
There is a point in your development where you realize that tech _does not_
mutate as quickly as it may seem.

~~~
zomglings
I haven't hit that point yet. It can get pretty close to overwhelming how
quickly people are building new things and it's often not clear to me what
problems the new things are solving (which likely means that I don't have
those problems and shouldn't even worry about those new things).

Do you remember how it felt when you had that insight that tech is not
mutating as quickly as it may seem?

~~~
ChrisMarshallNY
What I got from it, is that there's a solid "baseline" of technology/technique
that tends to remain fairly constant and relevant.

It will often be "discovered" anew, and repackaged with jargon, but the basics
are still the same.

My experience is that the mutations are more of an "accretion," rather than a
change. New stuff is added. An old technique might be formalized (like SOLID
isn't actually anything new, but the definition is relatively new), which is
really a way of "adding" to the older technique. We find ways to combine
"classic" techniques, or specialize/derive from them, to provide a different
service.

It's hard to find teachers that will keep up with the times. As someone who
has done training, I can tell you that creating a course is a fraught process.
It has to be correct. That means _a lot_ of testing/review, and often "after
the fact" fixes and refactoring, as students (invariably) find problems.

Keeping it updated is a pain. Also, it's entirely possible that the entire
class may need to be binned, as the tech becomes irrelevant (I have a whole
bunch of DU -Apple Developer University- certificates that are pretty much
worthless).

Also, scope and scale. Projects are much bigger, nowadays, than they used to
be, and we have found ways to apply classic techniques in new ways. Instead of
learning how to write a device driver, we learn a device interface SDK. That's
not a bad thing (as long as we choose a good SDK), as it frees us to do a
better job on the higher levels.

One example I give, is that I started Apple programming with MPW[0]/Pascal
(not Object Pascal)/ASM. It could take a week or two to produce a relatively
simple GUI app.

Nowadays, with Xcode and Cocoa, I can spin up a fairly full-featured app in
just a couple of hours.

Very little of what I learned with MPW will help me today, but the discipline
that I earned is quite valid, and much of what I had to do by hand, is now
done in the framework, so I do have a bit of an understanding of what is going
on "beneath the sheets."

[0]
[https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works...](https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop)

~~~
zomglings
I see - strong fundamentals are always worth cultivating because they are
invariant under shifting fads and trends.

The thing that I find difficult is how quickly trends and fads shift in this
industry. I came out of mathematics, which moves much more slowly than tech in
terms of what's fashionable. I think it's a function of the sheer number of
people working on tech compared to math.

------
barrkel
I don't really buy the analogy.

Writing software is a bit like playing multiple sports. You can be good at one
thing and poor at another, and as a result do great work on one project and be
mediocre on another.

Writing code in the small, optimizing; architecting for change; architecting
for scale in development; architecting for scale under load; architecting for
scaling out vs up; all different skills.

Writing code functionally, vs procedurally, vs message oriented. Writing code
with control flow vs data flow, and toggling between them. Crafting
abstractions vs composing them. Many small parts put together elegantly vs one
straightforward transparent monolith. Some skills are alternates, you can go
either way and get as good results.

There are people who only know a few things. But on a suitably scoped project,
that may be fine.

~~~
munchbunny
Sounds like you're contradicting the analogy but not the main point.

Many people would be completely happy with bowling a 160. In many contexts
that's a great outcome.

But if you as a developer want to break past the equivalent stage of
(beginner) expertise in any of the possible specializations or fields, you
have to understand how to keep learning past the "know enough to be dangerous"
phase.

 _Writing code functionally, vs procedurally, vs message oriented. Writing
code with control flow vs data flow, and toggling between them. Crafting
abstractions vs composing them. Many small parts put together elegantly vs one
straightforward transparent monolith. Some skills are alternates, you can go
either way and get as good results._

Many developers stop at one paradigm and avoid stretching themselves further
out of discomfort. Other developers learn a new paradigm but never reach the
point of understanding its limitations, while having convinced themselves that
they're an expert on that paradigm. From what I've seen it doesn't really
matter which paradigm, language, toolset, or discipline you're talking about,
this particular behavior happens all the time, and it matches the "expert
beginner" label pretty well.

~~~
bigwavedave
To be fair, the very first line in the OP says they don't buy the analogy, not
that they don't buy the main point.

~~~
munchbunny
It wasn't obvious to me that it was purely about the analogy:

 _There are people who only know a few things. But on a suitably scoped
project, that may be fine._

That's sort of a counterpoint to the main point, which is why I wanted to pull
the discussion back to the main point.

------
cosmodisk
I think the main problem is that most businesses are more than OK with
mediocre developers. There's only a small number of companies on this planet
where boundaries beimg pushed to extremes and it requires the top devs to keep
going further and further. It's like football: there are lots of kids playing
football,but we only need a few hundred,maybe a thousand that are at the very
top of it. And to get and to keep yourself at the top does require very
different mental capabilities than to get from a mediocre one to a good
developer.

~~~
randcraw
I agree, except instead of 'mediocre' I'd use 'competent'.

As long as technical wizardry doesn't add significant value, or it isn't
essential to the business, most companies would rather not pay for it. They
believe they don't need experts. And most computing folks at most companies
know that rising technically is not the way to advance your career. If it
were, more companies would be crying out to hire experienced 'expert' 50 year
olds. But they're not.

From what I've seen, expertise is overrated. And competence is underrated.
Adding real value to an enterprise comes from achieving multiple avenues of
competence (technical, business, social, etc), and then anticipating the needs
of the enterprise before experts have to be drafted to rescue a misdirected
effort (or a disaster that never should have happened if sufficient competence
had been employed).

A lack of emphasis on expertise is probably a good thing. Answering clever
interview questions well, like taking tests well, is at best a surrogate
measure for street smarts -- the skills that really matter outside academe.

~~~
partyboat1586
Very true. I knew a C++ developer who knew the language inside and out,
incredible skill, 100% on a written test where most people get hired with a
score of 60%+. He offered very little to the company other than optimising the
build to run faster. He just wasn't motivated to solve the problems the
company needed solving or engage in the product. Unsurprisingly he wanted to
play with C++ all day long.

I also knew a developer who came from a coding bootcamp, adequate CS
fundamentals and basic knowledge of JavaScript and Java. He was the most
productive developer I've ever worked with. Laser like focus and great social
skills. He occasionally needed guidance from more technical developers but he
knew when to ask for help and he got the job done.

------
cjfd
Identifying the good developer with the frequent job hopper and the expert
beginner with the developer who stays at the same place seems rather
unfounded. I have also seen the job hopper who left just before it became
clear that his architecture was actually not all that great. Also, wanting to
use the standard stuff vs. rolling out your own is more a thing of incentives.
If you are a frequent job hopper it is nice to learn something standard. If
you stay at the same place you will have to suffer from the standard
boilerplate that the not-so-great framework requires and that has to be typed
over-and-over. It is more a matter of incentives than that one thing is
necessarily better than the other, I think. One great advantage of the
programmer who stays is that his decisions are backed by skin-in-the-game.
S/he has to suffer through the consequences of his choices.

------
gerland
I don't really buy the "expert beginner" thing. How does it relate to having
the "T-shaped" skills? One is the frowned upon and the other is desired for
some reason.

The reality of programming is that most often than not you do not need to be
an expert to do a job well. I would even say that being an expert programmer
is all about sticking to only basic things. The more you try to be smart and
"on the edge" the more you or someone who inherits your code will fail. If I
would get 1$ for every trendy abstraction or framework, then I would not
retire, but probably could buy a new PC or something.

IMHO it all boils down to ego trips. Everyone thinks he is the superstar,
ninja or 10x and everyone else just a poser. "I'm the smartest one" should be
the motto of IT. If you think that you are the one that can push the whole
community forward then you are probably delusional. I think I'm a moderately
advanced developer, but some of the people that I met along the way were just
crazy smart, highly productive and - here is the surprise - nowhere near the
top. This delusion of grandeur is especially common in people that are
pampered in the business. If I would name them, then I would be instantly
downvoted, but just stop and try to imagine what people I mean. I'm guessing
you won't have any problem.

In the end, your project does not need you to be an expert, your team does not
need it, the business does not as well. Only your ego.

Long live the "expert beginner"!

~~~
partyboat1586
The problem is people in industry like to massage developers egos because they
need them for their own ends.

You need to learn to judge yourself objectively rather than what people say to
you. Measurable stuff like how many times does your feature come back from QA?
How many times did you come up with a creative solution during a project that
lead to a net positive effect? How long did it take you to be productive in X
framework vs your peers? On the micro scale compete on the codewars website
and look at other solutions to the problem. Often you will see creative things
that hadn't even crossed your mind.

This contact with reality is harsh and you can always make up excuses but it's
necessary because people around you don't tell the truth. Then after this it's
important to realise that your technical skill isn't your only asset and
working on interpersonal skills is just as valuable if not more valuable above
a certain threshold of technical skill.

------
austincheney
> As such, Advanced Beginners can break one of two ways

Perhaps a more clear way to think of that is in terms of comfort and bell
curves. The left extreme of the bell curve is easy to both identify and
understand for anybody beyond the left end. Those are the people at the low
end who perform below accepted baselines.

Less well understood are people at the right end of the bell curve, who
drastically out perform other developers. In all objectivity the people at the
right end of a bell curve have as much as in common with the median population
swelling into the middle of the curve as the supposedly incompetent people on
the left end.

Think of this in terms of risk and popularity. When you are below the middle
of the bell curve everything to the right of you is better performing. You can
increase your performance by moving closer to the middle of the curve by doing
what is popular.

Once you get to the middle of the curve you have to make a firm decision:
remain comfortable in your current posture and let popularity dictate your
approach or take risks to further increase performance beyond the population
median. In that regard the populations at both the extreme left and right ends
of the bell curve are doing things that are extremely unpopular. _You cannot
become an expert without fully embracing that reality._

An expert beginner is a person at the median of the bell curve or just to the
left of it. They have mastered their skills to that point and refuse to make
changes or take risks necessary to advance further.

As a front-end developer I frequently encounter expert beginners. People who
have mastered some framework/convention, but doesn't really understand how
their technology really works and are hostile to improvements that don't make
use of their favorite framework/convention. To outside observers the expert
beginner is clearly identifiable as performance is objectively measured with
numbers without regard for approach.

------
plorntus
I feel like that article took way too long to get to the actual point of it
then unfortunately abruptly ended as soon as it got interesting.

~~~
plorntus
Ah its first in a series, the first time Next up links hasn't just been
completely irrelevant articles.

~~~
hyperman1
You know, I've seen this article a few times before, and I never even tried to
click Next up. Thanks.

PART 2 [https://daedtech.com/how-software-groups-rot-legacy-of-
the-e...](https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-
beginner/)

PART 3 [https://daedtech.com/how-stagnation-is-justified-language-
of...](https://daedtech.com/how-stagnation-is-justified-language-of-the-
expert-beginner/)

PART 4 [https://daedtech.com/up-or-not-ambition-of-the-expert-
beginn...](https://daedtech.com/up-or-not-ambition-of-the-expert-beginner/)

------
irrational
My problem is that I’m expected to learn so many things that I never have time
to become an expert in any of them. Html, css, sass, JS, Vue, Vue router,
vuex, react, other react libraries, lodash, jest, webpack, Python, node.js,
Java, sql, Oracle, Postgres, bash, regex, docker, kubernetes, aws, azure, etc.
ad infinitium.

~~~
SahAssar
Looking at that list I’d say learn html, css, js, js browser apis like DOM,
one backend language, sql, and Linux sysadmin. IMO if you understand those you
get a lot of the rest by looking at where they fit and you can build a
solution without having to use a lot of product-specific APIs.

~~~
irrational
Oh, I already “know” all of these things (I’ve been doing web development
since the mid 90s). But it seems like as soon as I start to get a decent grasp
on a technology, a new version comes along, or it is replaced by something
new, or my boss/company directs me to use this other technology, or the
industry as a whole moves. SVN > GIT, jQuery > Angular > Vue/React, JS >
ES2015, managing our own servers > the cloud, etc. Jack of all trades, master
of none.

------
ragona
I didn’t really find anything I felt like specializing in for the first
decade-ish of my career. I was working on games, I don’t think 3D math is that
cool, and I wasn’t excited. I was tired of coding games over and over. I don’t
think I was an expert beginner but I wasn’t an expert in anything I wanted to
continue doing.

I took a break to be a manager for a while, which turned out to both be an
incredible learning experience AND enough pressure relieved from the daily
code grind that I was able to rekindle my passion for code.

Started writing a lot outside of work, realized I really like cryptography,
studied that, became competent enough to even figure out what TYPE of beginner
I want to be, etc. it’s very satisfying.

I’m around four years into that journey now, I’ve returned to a coding path
where I get to actually learn while building, and I’m excited.

The expert beginner is a surprisingly easy trap to fall into. I also think we
do this TO people when we trap them in a role and give them very little
flexibility in execution.

They will begin to specialize in doing a bad thing well without understanding
what they’re doing, especially if they aren’t given mentorship.

~~~
redisman
It's easy to fall into since it's usually what's expected day-to-day. Not that
many people have a chance to dive really deep into a topic at most companies.
Usually you're churning out fairly similar stuff for most of your tickets.
It's also dangerous for your career if you pick your specialization wrong.
Maybe 5 or 10 years later that technology is obsolete. Earlier in my career I
was something of a (Adobe) Flash expert but there's no way I would even
mention that these days. Much of it translates to other technologies but not
in a way that makes me an expert in them.

~~~
ragona
YO, same, I bet we hung out on Kirupa at the same time haha.

I worked on flash games at Disney, PopCap, Sony and Amazon. That was the shit
for a while for 2D games. But I actually went from social to mobile to PC
games and found myself less and less interested. Don’t get me wrong it’s very
cool code and quaternions solve a lot of the pain so some of the math is
frankly less fiddly than 2D, but I wasn’t in love.

It’s been nice to fully pivot towards cryptography and security since I get to
work on a lot more projects and do a better job on them. No one cares about
bugs in games. Everyone cares about bugs in crypto. It’s nicer for the
engineers.

Plus it’s frankly so deep that I have very little risk of mistaking myself for
an expert. Even PhD’s only have a narrow specialty, it’s very comforting how
hard it is.

------
gitgud
Similar to the rise of the StackOverflow programmer. You can get pretty far
just by Googling error-codes and brute-forcing a problem in a domain without
any experience (I should know).

Maybe not the best way to learn, but in such a technologically complex world,
it can sometimes be more effective...

~~~
kypro
Even when I know how to potentially solve a problem I often search it on
StackOverflow anyway because I know often I'll find a much better solution
from developers who are either more talented than myself or have simply spent
longer thinking about all the edge cases.

------
tarsinge
What is a good developer? Isn't there more than one axis? For my case over the
years I have honed my skills at problem solving, seeing the big picture, and
finding the most efficient technical solution from a business perspective (not
GAFAM scale obviously, but that's the exception). As a result, I can save
companies a lot of time and money because I will help reshape the problem and
rework the scope to find the max added value / work ratio, to deliver in days
a working solution, instead of a big year long project with all the overhead.
My productivity is high because I know where to cut the crap.

More than once I have seen a peer or a whole engineering department of
brilliant people going down a technical rabbit hole for weeks for intellectual
satisfaction, where instead I will just take a step back, walk to the manager
and try to work a different take for a solution that can be implemented in a
few hours/days even if the business goal is slightly moved.

Yet I'm definitely not a good professional software developer in terms of code
"quality", and don't consider myself very smart compared to my peers.

Edit: formating

~~~
dwd
You nailed it in the first sentence - businesses don't need developers, they
really need problem solvers - but we often don't get a seat at that table to
turn around a problem before it lands on our desk as a request to code some
poorly understood idea someone had.

1) Identify the problem - it invariably isn't to do with code but a
combination of time and cost. 2) Can the problem be solved without a line of
code, such as changing the process and removing the issue that way? 3) Is
there an off-the-shelf application, software or component that will solve the
problem. 4) Maybe you do need to code something.

We are also all too quick to just dive straight in at (4) because that's what
we identify as, that's what we enjoy and unfortunately what we get paid to do
rather than getting paid to think, advise and value-add.

~~~
ptero
Some ideas that look poorly thought out are in fact pretty good, just
different from what we would do ourselves.

In my experience it is a key skill to objectively evaluate ideas that are
different from my preferences and accept those that are good enough, but not
use my preferred way of doing things. This is a quick path to get a seat at
the table and getting your opinions heard. My 2c.

~~~
mgkimsal
> Some ideas that look poorly thought out are in fact pretty good

The only times I've ever found that to be true is when there's other details
available that I'm not aware of. Business constraints "everyone knows" about
but aren't documented anywhere, for example. Decisions made in a meeting that
aren't communicated out, meaning, essentially, that you only are given a
portion of the problem and request. This gets back to the 'seat at the table'
concern above.

The 'seat at the table' is far more related to interpersonal/political skills
than technical ones, but can be chicken/egg in some places.

~~~
ptero
My opinion is certainly skewed by my personal experience, so take it with a
grain of salt.

That said, engineers are a highly opinionated bunch and a group of 5 will have
5 different personal preferences. But they are smart and will quickly
recognize an objective opinion that is not hard-driven by personal
preferences. Folks with good technical judgement who are willing to accept a
different approach quickly become a highly respected member of the community.
They frequently end up with more tables offering them seats, in a technical
expert role, than they care to occupy.

~~~
dwd
This is one of those places where strong opinions, loosely held should be
applied. And I can imagine those people getting more invites simply on the
basis of possibly being more agreeable to interact with.

Programming is an abstraction (a perspective on what the computer is really
doing) that is very much shaped by the tools we choose to use. Meta-religion
is probably a fair way to describe it, and can be every bit as divisive in
some circles.

------
ChrisRR
I work with an expert beginner and I don't know how he's survived. He's got
about 30 years of experience, but writes code like he's got 1 year of
experience.

His code has absolutely no sense of quality, doesn't employ any sort of
standard design patterns or style, has no semblance of architecture and is an
absolute hacky rats nest of code that falls apart with any change because of
how interdependent it is.

The other day I was sent some of his updated code, which had no version
control and had randomly added an extra 150 files to the project. It turns out
the majority of those files where duplicated from elsewhere in the project and
apparently it was my job to find where the changes were among that mess.

It's like he learnt to program decades ago and then never opened a book or
looked at anyone else's code since.

~~~
twic
And he's still got a job. So who's the real genius here?

I don't want to be that guy, and i don't want to work with that guy, but i
have to confess to a certain jealousy that people like him have figured out
how to sit back and just phone it in and collect pay cheques for thirty years.

~~~
caymanjim
I've worked with innumerable people like this over the decades. The thing is,
they're usually not phoning it in. They're really trying hard. They just suck.
It looks like they're working hard, because they often show up early, stay
late, ask a lot of questions, and produce a lot of output.

It's hard to fire them, because to many outsiders, they're workhorses. They
know just enough to scrape by on each task, but they also have institutional
knowledge and social connections that make them seem invaluable. Often that
institutional knowledge is that they're the only person who understands their
own shitty code. Their more-capable peers usually know that they're
incompetent, but management doesn't.

There are many reasons people like this can survive. Peers don't want to
explicitly throw them under the bus. The best of their peers simply move on--
to other projects in the same company, or more often, to greener pastures at
another company. Their peers cover for them, because it's easier to work
around a millstone like this than it is to get them removed. It takes months
of concerted effort to get a peer fired for underperforming. If you want to
try to get someone like this fired, it starts to look like you're the asshole
with a personal vendetta. Especially because they've been there for a decade
and you probably just arrived.

These millstones aren't outright incompetent. On paper they've got extensive
experience. Socially they're well-regarded by everyone at the company except
their immediate peers who know they suck. They've been faking it and faking it
well since long before you arrived, and they'll be doing it long after you've
departed.

Make no mistake, though. These people are rarely phoning it in. They are
busting ass to tread water. Sometimes they believe their own lies, but more
often they are terrified that someone will find out just how bad they are.
That's why they work so hard.

~~~
SwiftyBug
Damn, that's me in 10 years. I'm so bad at my job that my only hope is that I
go by unnoticed long enough so my time in the company becomes a strong reason
not to fire me. It's been almost two years so far. The thing is I really try
to improve, and in some ways I even do, but at a painfully slow pace. Even
though I've been in this company for nearly two years I've been working as a
software developer since 2012. And it hurts so much to see people coming fresh
out of college outperforming me by orders of magnitude. It makes me feel
really stupid. But is a really well paying job in a somewhat big company, so I
hold onto the hope that if I don't screw up things too much my employers won't
even acknowledge my existence. In the end I only feel bad for the people I
work with (not those I work for) because they are nice and talented people and
it must suck to work with someone that lowers the team's bar.

~~~
caymanjim
Maybe there's a better job out there for you? Either at another company where
you'll get mentoring and support for growth, or in an entirely different
career. It doesn't sound like you enjoy what you're doing now.

I've stagnated at jobs in the past. I've thought it was my problem. Then I
moved on to better places, where coworkers helped each other to excel, where
people placed a premium on improvement and education.

If your company shoves everyone into a cubicle and assigns them individual
tasks, how are you ever going to learn? If you can get a job somewhere that
embraces pair programming, you might find a whole different world. You can be
mentored by your coworkers and collectively solve problems, instead of feeling
like you need to put your head down and produce something on your own that may
be beyond your expertise.

Fresh grads, especially grads out of code schools, often arrive with a lot of
buzzwords ready to go, and a script of practices they've been told are the
right way, but that's all flash and no substance. It can lead to
overconfidence. There's something to be said for it, though; you can fake it
until you make it. The important part is that you actually make it in the end,
and to do that, you need mentoring. It sounds like you're not getting the
mentoring.

I know it's hard to quit a well-paid job and take a chance, but I think that's
better than going to work every day hoping you won't get fired, and not
growing as an individual.

~~~
SwiftyBug
I actually like this job. We do pair programming regularly, which is the
source of most of my worries that I'm not good enough. My team has a dedicated
manager whose job is to mentor us in our careers. I like him and he seems to
like me, he is always willing to listen and to offer help. I think the company
is outstanding in providing a healthy environment. Which is why I feel so out
of place. Everyone is so smart and grows so notably much and I feel I'm
falling behind.

------
Garlef
I think blaming this all on learners not realizing their missing potential is
a bit one sided.

Other influences:

* Skill level of coworkers * No time is dedicated by the team to abstractions / refactoring due to deadlines, or personal preference etc. * The technology being used is limiting or used in a limiting way.

If you never push your boundaries you'll never get better. Going to 100% one
time will have a lasting effect. If you instead only go to 80% all the time
you'll only get better at doing a mediocre job.

However, the goals might be misaligned here: Your employer and coworkers might
not be interested in your personal growth. Instead they want you to "Get stuff
done."

------
zoomablemind
I find the article while thoughtful and provoking, paints a myopic view of
self-advancement. The analogy with sports is what throws it off. Sports can be
individual and could be team-based. There's an importance to individual skill,
no doubt, but the team apect is what lets one not only assess own standing,
but have a chance at advancing it without the adversarial pressure. If you
choose to retool, the team would pick up the slack meanwhile until you're back
(hopefully stronger).

The skill degrees indeed are relative, and in the field of programming are
dynamic. Of any one skill to put in permanence is perhaps an open-mindedness.
It is a readiness to learn, not much an ability to master.

Lots of excellent programmers don't stop learning, they just discover the
wisdom of 'good enough for the time-being'.

Expertship is lonely, beginnership is open an dynamic. The author projected
the whole skill advancement spectrum onto the single grade of Beginner, as if
beyond Expert lied a void or infinity.

I believe, paradoxically, beyond Expert is ... a Beginner. Either by
humbleness, or by need to discover a new field, or by age, or boredom, or
wisdom.

Programming has to be a team activity. If you happen to handle a project part
by yourself, your future self or someone to work on your code after you is
your current team.

If you're on the team already, then you keep learning from your mates as long
as you let your mind stay open to it.

------
aneutron
Or maybe they stop learning because at some point, you realize your employer
doesn't give two shits about doing incremental changes to your infrastructure
/ code, let alone breaking changes, but instead pursues paying outside
contractors to do broken shit you'll add the pile of things to fix.

Or maybe that's just me. Also, I'm not going to work on mathematical proofs
for something good, just to see my work disregarded because it's "too
complicated".

------
microcolonel
I think that there's often something simpler going on here. Some people are
simple and small-minded, they simply do not enjoy learning new technical
knowledge and skills, and would rather run what they have to failure even if
it means losing out on a lot of income.

A fine example of this is a new hire getting anxious and defensive because the
git branching strategy at the company isn't the branded one they're accustomed
to (e.g. git flow).

------
imnotlost
Developers are supposed to do all this learning on their own time as well,
right? No budget or time for training. In fact, why don't you do some overtime
paid in pizza?

Learn new stuff at home on your own time, put it on github, it'll be fun,
ignore your family and your friends.

And the helpful comments here for someone who is doing 12-hour days is to
meditate and go for a walk?

Work 7 hours and go home, your life will be better.

------
Discombulator
While the topic is interesting, I don’t think the analysis presented in the
article series (at least in the first two articles) is particularly
compelling.

For one, it relies much on hypotheses about internal though processes, which
makes it basically unfalsifiable. Then the author is in my view shooting
himself in the foot with the bowling analogy, namely by describing how he
noted that he didn’t improve anymore and went to ask a colleague for advice.
How would the same not be possible or even likely for the “expert beginner”?

All of this is much more easily and briefly explained by motivation - for many
people in technology, technology is simply not a passion! For them it is just
a tool and like also the article mentions, there are few reasons in many
companies to spend more time on perfecting your craft - in fact, it might be
strictly worse than building career-enhancing relationships. This is
especially true as someone not in a technical position is often not able to
assess the quality of the output.

------
blickentwapft
If you are a developer, what is the last significant thing you learned, and
when did you learn it?

~~~
gitgud
The other day I learnt that in Chrome's Dev Tools you can easily replay
requests.

1\. Network -> Select Request -> "copy as fetch".

2\. Then paste the fetch() statement in the JS console, and look at the
network tab for results...

Pretty easy and handy for replaying random requests during development.

------
ivanhoe
The only problem here is that building things, unlike bowling, is a team
effort, and also goals are very different, you don't win the game by having
the highest score in the end. IMHO big question is if it's worth to invest
into "getting your score over 160" in terms of benefits for you and/or
company? Can that time be better used? Will your project benefit more from
moving your bowling from 160 to 200 - or you can get your role covered just
fine with 160, so perhaps invest time instead into getting at least 1600 ELO
in chess which will be needed on the next project, and will also give you a
wider perspective?

------
heisenbit
Any discussion of software competency that does not take into account the
rapid aging of some skills is incomplete.

~~~
rmoriz
Also any discussion of software competency without market analysis is
incomplete. We have seen a big change from indy culture towards monopolies and
their rules in the last 10 years. Almost all developers are required to play
by the rules or Google (Chrome, Go, k8s), Apple, AWS.

------
mgrennan
After 40+ years as in electronic, software developer, OS and App, Networking,
SysAdmin, DBA and DevOps I see it all as a multi discipline. Knowledge in
Electronics, CPU design, Compiler development, OS design, communications,
Business management and user interfaces all relate and a "Rock Star" would
need to be an expert in them all.

Most Dev's stop with App dev and business design. Some go on to UI or compiler
performance. System a little and communications and electronics almost never.

~~~
PaulStatezny
Sounds like you have a pretty impressive set of competencies. Well done!

> and a "Rock Star" would need to be an expert in them all.

Need... in order to do what? Run a business? Be qualified to make every
decision for... a chip manufacturer that also does OS development and
application development? (Apple?)

I agree that it's worthwhile to become proficient in many areas, but your
comment seems too specific and absolute to be useful. It discounts the value
that people (who aren't your definition of "Rock Star") can bring.

------
ErikAugust
People respond to incentives.

As the author puts it, many a developer gets hired and eventually they
"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".

In my experience, that is what does happen. There is no incentive to do
better, and the paychecks in IT happen to be pretty large.

I progressed the most as a software developer when I wanted to be hired again
after striking out on my own for a bit.

What I learned from striking out on my own was that my software development
knowledge and abilities may have worked in previous contexts but not where I
wanted to be as a next step of my career. While I could have been promoted at
a previous job that wouldn't have proven anything on the open job market. This
is probably where a lot of dissonance often occurs. People are Senior or Lead
developers at one place for a long time then suddenly are out of a job and
cannot find another one.

So I worked hard to improve in a number of ways because I was highly
incentivized to do so - there was no "current position" to fall back on.

------
honkycat
This article addresses a very particular person who definitely does exist.
Expert beginners are absolutely a thing and things have only gotten worse with
the "HIRE EVERYBODY! NO TRAINING REQUIRED" approach to hiring a lot of shops
moved to.

I had not experienced it until the past year. If this article does not
resonate, if you have not worked with one, count yourself lucky.

I am regularly astounded by the lack of extremely basic skills I have seen in
the places I have worked recently. For the love of god, just read a single
book or take a single class on software development.

People argue: "Well, most shops don't really need good developers." I call BS
on this. Every place I have worked at are trying to make money and keep the
team from getting canned, and a bad developer will take you two steps back for
every one step forward.

There was a person at my last job, nobody knew why they kept him around. He
had a good 10 years on most of the team, but his code was easily the lowest
quality, and he constantly fought with the rest of the team around attempts to
improve code quality.

We hated him. He was totally stale and had given up on self improvement. We
wanted him GONE. What happened? Most of the team quit and he is still there.

------
netcan
I think there is long term culture clash between old and new ways of learning,
in the "over a career" sense.

The old way is the formal, with external motivations and structures. Maybe
there's a curriculum, like accountancy has. Maybe there's a coach, like in
sports. One can spend a long time in the "infant stage," learning by mimicry.

A young karateka spends years practicing motions in the air, with form
carefully observed and corrected by a teacher. This lets learners access the
knowledge of karate as a whole, without needing an intuitive understanding of
why this elbow must point that way while performing kick two in exercise X.

To jive with the author's bowling analogy... Imagine a child bowling with just
a ball. No pins. No aley. A teacher corrects form: posture, the swing of the
arm, the final position. Once the child starts bowling for real, all their
habits will be good. The known deficiencies of poor form are avoided, and the
risk of hitting an "expert beginner" dead end is low.

This kind of formality is only possible when the domain is well known, and
"correct form" is well understood. I suspect that these systems require
generations to build. They also run the risk of devolving into ritual,
superstition even.

The informal, more autodidactic culture does risk an "expert beginner trap," a
premature peaks in skill that requires formal (or intentional) training to
defeat. OTOH, "expert beginner" is not just a trap. It's a useful goal, for a
lot of situations.

If you are going to fight the bully next week, karate is not a good answer.
Those highly refined skills have little intrinsic short term roi.

------
OJFord
Judging from the '7 years ago' comment 'dates', and the article's '30 Sept'
'date' (!), this is (2012)?

------
oldandboring
I'm going to risk echoing what other like-minded contrarians here have posted.
This essay makes some good observations about what happens to developers in
their careers, but colors those observations with opinions about what's good
and bad. And, as is usual in the developer community, continuously learning
new technologies and layering in more "best practice" structure (presumably in
one's own free time) is always king when it comes to these folks.

It's hard not to read this and sense a bit of bellyaching about how the market
for software engineers isn't a pure meritocracy where those who are using all
the latest tools with pitch-perfect architecture are the only ones who get
hired and promoted. And it seems to totally ignore the real world in which
legacy software, with all its warts, does exist and can't be thrown out.

------
adverbly
Good article but I disagree.

"Bowling is like Software" does a good job at pointing out a common
problem(You can develop and get stuck using a style which has a lower ceiling
than other styles).

I still think "Bowling is like Software" is a bad analogy though.

Bowling is a one-dimensional task: Its the same problem every time, so some
styles will likely have much higher ceilings than others. Software is far more
complex: some styles work well for some problems but poorly for others. If
there is actually a generic fix-all style, its likely very abstract, difficult
to grock, and probably involves a lot more math than we'd like to admit.

So I don't think theres anything wrong with getting good at one style, even if
it has a low ceiling because even if you learn another style later, you will
probably want to go back in your toolbox at some point in the future to mix in
some of the original style.

~~~
redisman
Software and business are also too human unlike something artificial like
bowling. Creating beautifully architected and amazing abstractions with full
test coverage at a startup churning out MVPs is actually a very bad approach
even if it's objectively following "best" practices.

------
softwaredoug
It feels like self-admitted beginnerism is actually the mark of a great
developer (not assumed expert). Regardless of whether the “expert” is
genuinely earned or not.

Indeed this is the idea behind the beginners mindset[1], where we assume our
knowledge and experience may be faulty. That we have to unlearn our skills to
make a further leap. That when you assume you’re an expert, you’ve already
lost.

So I tend to question the Dreyfus model in general. I want to see how capable
people are at getting skills, but also how readily they can discard hard won
skills. Similar to a sunk cost trap, we can needlessly hold onto our skills
and hesitant to think we need to let them go and rethink the whole approach.

[1] -
[https://en.m.wikipedia.org/wiki/Shoshin](https://en.m.wikipedia.org/wiki/Shoshin)

~~~
redisman
Self-admitted yes but I think the OP article is talking about ignorance about
your own beginnerism. Definitely as someone who invested heavily into
"getting" OOP early in my career, I can now see that I have a lot to unlearn
and mold my understanding of software in a less dogmatic way.

------
monksy
1\. It's a lack of discipline (If it's anything from the testing post we saw
yesterday)

2\. Aggressive pushes to deliver over creating something solid or
experimenting with different archs

3\. The selection process doesn't look for experience.. they have been looking
for leetcoders that haven't changed since college

------
Peckingjay
Links to previous discussions:

[https://news.ycombinator.com/item?id=11327669](https://news.ycombinator.com/item?id=11327669)

[https://news.ycombinator.com/item?id=19467367](https://news.ycombinator.com/item?id=19467367)

------
bobobob420
In my opinion experienced developers are mostly pretty dumb even at top firms.
Yes they are GREAT at the particular thing they have invested the most into
labeling themselves but are often stuck in some tunnel vision or just do not
care to learn new things. Many young developers are eager, learning multiple
technologies/languages at once, work across back-end, front-end, network, dev
ops..to be a successful new developer the wall is much much higher than it was
for developers 20 years ago. These old guys can't do much tbh and are so slow
at adapting, they don't even have excitement in meetings or anything. So
boring. You can do what you want in life but don't complain if you are
replaced.

------
deltron3030
Developer = programmer, or are devs expected to have more general and higher
level big picture knowledge?

Is every carpenter without interest in furniture design an expert beginner, or
just a carpenter?

Aren't developers who aren't into design/business just programmers? Why is
this bad?

------
twicetwice
This is a really neat article. I feel like just this week I reverted from
Expert Beginner to Advanced Beginner—or maybe glimmers of Competent—as working
on my current project has revealed to me just how much I don't know about what
I thought I knew well.

------
tracerbulletx
This is a valid interpretation of a trap that people can fall in to but there
is also a positive interpretation of being an "expert beginner". Developers
encounter so many new technologies at such a rapid pace over their careers,
especially recently. People who are constantly trying new technologies at a
shallow level can have access to more tools to solve problems and be
successful in a rapidly changing environment as long as they don't over do it,
and narrow their scope to relevant topics that support each other. I think
there is a line to walk between falling into a lack of mastery, vs not
absorbing new things at a beneficial rate.

------
pontifier
This hits hard. I know that I'm missing some truly fundamental techniques in
my development such as testing and ORMs, but I can't seem to bring myself to
take the massive steps to abandon the way I'm doing things now.

Every time I try to start doing things "The Right Way" I end up getting
nothing done. In frustration, I revert back to my old technical debt building
ways just to try to move forward at all.

-side note- I didn't even know it was possible to bowl without sticking your fingers in the holes... it's almost as absurd as not doing any automated testing.

------
jart
Sounds like fake it until you make it. People, especially self-taught ones,
aren't going to pursue something if they believe they're bad at it. Be nice.

------
marcus_holmes
This really hit me.

Am I an Expert Beginner suffering from Dunning-Kruger and delusions of
competence?

Or am I an actual Expert suffering from Imposter Syndrome?

I'm working as tech co-founder in a small team with junior devs, and I do some
things "differently" for what seem to me to be good reasons.

How do I tell?

~~~
titzer
If you have less than 5 years experience doing _anything_ , it's safe to
conclude you are not an expert.

If you can't identify a single person who is better than you at something
important you need to do, then you are a probably a terrible judge of
competency and therefore not an expert.

If you haven't failed, you're not an expert.

~~~
marcus_holmes
I have over 25 years of experience.

Is it 25 years of experience, or the same year 25 times?

How do I tell?

~~~
solraph
From my personal experience, are you still writing things the same way you
were six months, a a year, two years ago?

I look at code I wrote a couple of years ago, and not only can I identify how
I would write it differently, I can identify /why/ I would write it
differently - both what technique, concept, or methodology I have since
learned, and how that would make the code better.

If you cannot, you have probably plateaued, like I did for a (far too long)
while.

~~~
marcus_holmes
I noticed yesterday that I've implemented the same type of CRUD API call in 3
different ways in code I've written in the last 2 years. And I can see why I
did that and what I was trying to optimise for in each case. I'm sure I would
write it differently now, but would I write it better? I have no idea what
"better" is any more. Faster? Easier to read/maintain? More loosely coupled?
All of these?

I spent two weeks building a Go version of Webpack last month because it was
either that or implement Webpack because the Vue components we're writing
needed unit tests. Was that wise? It works fine, I don't have the gajillion
shitty dependencies of Webpack, and it compiles, bundles, uglifies and
minifies our entire Vue front end in <200ms but is that a good thing? Was I an
idiot reinventing the wheel, or was I wise avoiding exposing us to the
insanity of npm? When it needs maintenance in a few months and I have to spend
a few days fixing it, is that time wasted, or have I saved time because every
time Webpack updates a version everything breaks and we don't have that
hassle?

How do I tell?

~~~
solraph
To me, that sounds like you've hit a ceiling in your current stack, and
probably workplace, and lack examples of people around you to learn from. What
the solution to that is depends on your situation. Change of workplace? New
career direction? New hobby?

> I have no idea what "better" is any more. Faster? Easier to read/maintain?
> More loosely coupled? All of these? "It depends." As a gross generalisation,
> most juniors optimise for their bug-bear of one of these at the expense of
> all of the others. Most mid level devs try to balance them out, and
> hopefully, most seniors pick which ever is appropriate for the task at hand,
> with an eye on the long term consequences of their design - if there even is
> a long term consequence.

Re webpack replacement; Given the amount of time I've wasted dealing with
webpack and it's madness, I'd back you up and say it's probably a net win - as
long as it's documented enough to avoid the bus factor. It's not like golang
is some esoteric language where it's impossible to find devs for.

P.s: I want to clarify here that I'm not necessarily a good programmer, I've
just spent enough time stuck as a niche programmer & probable expert beginner
and fighting my way out of it that I recognise the patterns. I'm probably a
better study of dev behaviour than actual dev.

~~~
marcus_holmes
being the only senior in a tiny startup, I'm definitely lacking examples. I
think I'll look for a Go expert freelancer to be that, when the startup is
making enough money. Thanks :)

------
Tomis02
> On the other hand, the least talented developers are more likely to stay put
> since they’ll have a hard time convincing other companies to hire them.

Terrible fallacy on so many levels. "I can't convince you to hire me,
therefore I'm bad". "I can convince you to hire me, therefore I'm great".

------
one2know
Bleh. All I see here are all the same old ageism tropes and noob programmers
trying to rationalize their age bias.

------
raiflip
I've dealt with whole teams of these kinds of people. They also get extremely
defensive about anything they don't know. Even worse, this was particularly
the case around proper testing. Suffice to say the team committed a lot of
bugs to production.

------
SMAAART
Expert Beginner? That's not just a Developers' phenomenon, it's actually more
prevalent in business where "I have X years of experience...." what if they
have been doing it wrong for x-years?

------
Sniffnoy
(2012)

------
dadoge
Most “Super Senior Principal” engineers I see at larger companies are ones
that have been there for 5+ yrs, so I disagree that the best engineers always
run to greener pastures.

~~~
valuearb
The point is the most talented ones left and you are seeing the dregs that got
rush promoted to replace them.

And he was talking about companies going through hard times, good companies
should be able to keep their best employees.

------
courtf
I remember this one, there are lots of good articles on this blog. This one is
a little aggressive, but this is a real phenomenon. In many companies, styles
and expectations fluctuate too much for anyone to get comfortable for long.
Lots of others move glacially, and within those walls, the outside world can
barely be heard.

I've bounced around quite a bit myself, but some of the best work I've done
has been in situations where I could have slacked off and phoned it in. That
was typically prevented by the opportunity to perform challenging work that
allowed me to learn, not by fear of falling behind some imaginary peer.

The problem with many workplaces is that challenging, interesting problems are
few and far between and that is by design. Why take on the risk to the
business by having technical knowledge in-house to solve the hard stuff? It's
expensive, and large chunks of that investment can just walk out the door.
Most companies would happily pay for solutions from other businesses that
specialize, and then ask devs to glue these mismatched pieces into a semi-
cohesive whole.

This sort of glue-work is ubiquitous, even in companies that ostensibly
specialize in making their own software. How much time is spent wrangling all
those amazing, productivity-enhancing dev tools that have proliferated? The
goal is typically to offload work for a fraction of what it costs to keep a
dev employed. New businesses are cropping up all the time trying to sell tools
to the big boys, so they can in turn keep their devs focused on core
competencies. The companies that specialize in tooling of course all sell to
each other as well, it's a little bit of a cartel, but this endless cycle of
tool churn is nothing new.

If you approach this environment as a newbie, and you are concerned about
becoming an expert, it's likely that you'll only make progress on that goal in
fits and starts. Companies grow, job roles become both over-specified in their
requirements and narrower in their responsibilities, and all the while you are
expected to learn new tools that allow your employer to save on skilled labor.
It's rare to find a job where mentoring and career advancement are given
genuine care. Employers have an incentive to keep employees tuned for
specific, ever-narrowing roles.

One of the few consistent places I've been able to find learning opportunities
has been in start-ups. The overarching trend is the same there too, but at the
beginning those roles are not yet so clearly defined and you can bite off as
much as you want. You probably won't be rewarded for doing so, and it's a bit
of a crapshoot, but it is one small advantage to those environments.

------
kuharich
Prior comments:
[https://news.ycombinator.com/item?id=11327669](https://news.ycombinator.com/item?id=11327669)

------
classics2
Hiring is not a meritocracy and programming is not bowling.

------
HugoDias
Not sure if its just me but its very hard to read this website font. Had to
bookmark and read it on Pocket.

------
brianolson
Some people have 10 years experience. Some people have the same year of
experience 10 times.

------
musicale
This essay seems to be short on specifics.

------
ai_ja_nai
Very lucid analysis, nice piece

------
Amlan123
From india

------
Amlan123
Hii

------
knorker
I really hate it when articles exactly date their stories, but don't provide a
year.

"Sep 30", this one says. Hmm… can't be 2019, because I read this years ago,
I'm sure.

The only indicator of year I could find is that the _comments_ to the article
are 7 years old.

~~~
jasode
If you "view source", there's a JSON blob that has this:

    
    
      ,"datePublished":"2012-09-30T23:48:21+00:00","dateModified":"2019-06-06T01:20:40+00:00",
    

Looking at raw html source isn't always a reliable indicator but the older
date looks legit in this case.

[Can someone explain the downvotes? I'd like to know if my information is
incorrect.]

~~~
jansan
Nice hack, but this should not be the preferred way to find the year of an
article, even for a nerd.

------
r34
Maybe developers stop learning because they realize that that to learn how to
do the same thing with 167 technologies is not a real development. Maybe they
realize (they should) that self-development should be we well balanced, so
after programming workday they should invest their time into sports and work
with their emotions and take care of interpersonal aspect of their lives.

The older I am the more I'm convinced that development is not individual thing
- it's a team sport.

Hey, company: divide your workday into 4h work for external projects and 4h
work for team development.

Smart, mature developer, will realize that the most inhibiting phenomenon for
him is usually the job itself.

~~~
scarface74
And then when your company decides to either to “take the company in a
different direction” or you notice that it is bringing new employees in at
market rate that has gone up 20% in 3 years while HR is giving you 3% cost of
living raises, you are out there in your mid 40s, can’t get a job and you
start complaining about ageism.

I was there a little over 10 years ago at 35. I belatedly learned how to play
the game. Until my current job, it was all about resume driven development and
job hopping the minute my salary or what I am doing at my current job got out
of whack with the market.

~~~
oblio
You need to do this and do it early. All those years of missed revenue add up
quickly.

~~~
_bxg1
I don't like this mentality. Maximizing lifetime revenue isn't some emergency
to panic about. It's one goal to balance against many other important things
in life. If your income provides you a lifestyle you're happy with and is
poised to continue doing so (which in this context is almost certainly the
case), there is no emergency.

~~~
swagonomixxx
The obsession with constantly increasing your salary year-on-year is very much
alive and well, at least in the US.

I'm not European, but I imagine that this isn't the case in Europe as it
doesn't have the same culture around work.

~~~
necrotic_comp
In the US, I think part of the reason why this is the case is because the cost
of living goes up significantly more than the cost of living adjustments.

For example, while landlords aren't supposed to raise the rent by more than 2%
per year, I've had my landlord surprise me with a 5% change, but moving is too
expensive to realistically consider [1].

Factor in all the additional costs of living, and if you don't get significant
raises every year, you're going to fall further behind each year and be unable
to afford a family, a house, or an emergency.

It's not great.

1 - When I moved to a good neighborhood in NYC, I had to pay a brokers fee of
15% + moving costs + up front costs to the landlord. Say my rent was 3k, this
would be 5400 (0.15 * 3000 * 12) + ~500 + 9000 (first + last + security), or
approximately 15k just to move into a place you don't own.

~~~
scarface74
What’s this about what the landlords are “suppose to do”? Most of the US isn’t
rent controlled. My apartment that I moved into after getting married in 2012
went from $1300 to $1750 by 2016 when I left. It was $2000/month last year.

My mortgage is less than $2200 for a 3100 square foot house brand new build
and that wont go up besides property taxes and insurance.

~~~
necrotic_comp
"supposed to" means legally. 5 percent isn't allowed but they can get away
with it because fighting it isn't worth it.

------
geuis
Look Mr Blogger, take this in the kind hearted intent it’s meant by a 40yr old
engineer who doesn’t have time for bullshit anymore.

Get to the point, fast and quick.

I’m sure you have many valid and interesting points of view about your job,
experiences, and wants. I’m interested to hear about them. You could offer
some unique experiences I can learn from or maybe there’s some tidbit I can
offer you.

But unless you learn how to get to the point first, I don’t care. Even now
after 3 minutes of perusing your entry I’ve lost any sense of what it was
about.

To finish up, I’m not trying to be evocative, negative, or anything. I just
want to encourage better ways of writing, thinking, and publishing.

Always consider your readers first. They don’t have as much time to parse what
you write as it takes you to write it.

~~~
blickentwapft
Intolerance for long form writing is relatively new and an outcome of the
Internet shortening attention spans.

I used to do some long form writing and I still remember feeling offended when
I first got “too long didn’t read” comments.

~~~
Tomis02
Long-form writing is fine as long as you have something to say. The best thing
to come out of the article was the title, unfortunately.

