
The Eternal Novice Trap - signa11
https://feoh.org/2019/12/27/the-eternal-novice-trap/
======
lmilcin
I know intelligent people who fell into this trap and can't get out.

I know a guy who is seeking enlightenment writing web frameworks. He is
streaming new frameworks at ever increasing pace. Unfortunately, he never gets
around to supporting what he has created, thus, he never learns how to make
something that actually makes life easier in the long run. His frameworks are
pure zen, but only to him. The rest of the team while their days trying to
convince management that their high regard for the guys capabilities is
completely misplaced.

I know a bunch of people that spend their entire time learning new
technologies. New frameworks, languages, patterns. The learning is typically
shallow as it ends the moment the person knows how to do anything with it or
when he/she finds some kind of huge disadvantage. Then there is a switch to
another language/framework/library/tool/paradigm and the eternal cycle
repeats.

Stick with a project/problem until completion. Don't be satisfied with first
80% and neither with second 80% of the task. You need to go all the way. Try
to learn everything there is to learn about it. Try to figure out all
different ways to improve it and then try to figure out why those might not be
the best ideas. Go discuss with your team, your architect. Listen to their
problems, then figure out how your ideas do/do not help solve them. Understand
why.

Try to make things so simple everybody can understand them. Try to be able to
explain every decision and how those decisions interact with each other.

~~~
throwaway8291
This is great advice and would be even better, if our industry was not that
hype driven. Tell someone, you are a JavaScript expert and you had great
success in the past with jQuery and knockoutjs. People will reject you, you
won't have a job and no money.

And if you are one of these poor fools, who depend on work for income, than
good luck not at least partially follow up on trends, them being silly or not.

------
forthewyn
FWIW this is my post. I didn't post it here because I'm not really involved
with this community very much.

Any feedback would be very much appreciated.

~~~
tofflos
It's well written and pretty much spot on. The difficult thing with advice is
that one first needs to figure out where one is in the spectrum before
determining whether it's applicable - i.e. overweight people could benefit
from eating less, underweight people could benefit from eating more.

------
rectang
To avoid the "eternal novice" trap, learn computer science fundamentals. If
you can, choose projects and jobs which don't force you to burn time learning
superficial material which will become obsolete in a few years.

I agree with this post (except for swearing allegiance to any specific
programming language): learning programming languages is a poor way to
prioritize. Learning algorithms, or math, or operating systems, or compilers,
is more effective — and will make it easier to pick up a new language when you
need to.

~~~
izacus
That won't teach you how to build maintainable software in the long run
though. It will give you a lot of groundwork, but one of the major issues I
see in eternal novices is the fact that they never had to maintain software
beyond 2-3 years. Maintaining software in the long run demands certain
discipline so it doesn't bite you in the ass and many developers simply never
had to deal with something like that. Even the ones styled with "senior"
titles.

~~~
jjeaff
I'm just learning this now. I have built lots of stuff over the years but I
have always had to balance my time between actually coding, managing the
coders, and running the business side of things.

Now, over the last few years we have actually experienced a lot of growth and
our code has started to require some scale and I have had time to focus a bit
more on the code.

I feel like I have learned more in the last 2 years than the 20 before that.

I've had to focus so much more on actually architecting the system, thinking
about how the data is stored in the DB, creating a smooth developer
experience, creating maintainable code, and actually tracking and logging tons
of detail about the app so we can find and diagnose bottlenecks before the
become a problem.

So in my case, it hasn't been so much about having to maintain it for more
than a few years (I have projects I have maintained for 10 years now), but the
fact that this one is experiencing some real scale has really laid bare my bad
(and good) decisions and forced me to learn about and start making better more
informed decisions.

~~~
bcrosby95
A lot of it is just encountering new challenges you haven't faced before.

Learning to scale an application was certainly one for me. Another was writing
a webapp where accessing the primary datastore was a 50ms round trip. Another
was writing warehouse software that had to interface with hardware. And
another was building a somewhat complex multi-system application that ran an
ecommerce business.

------
weeksie
Yes and no. I'm very glad that I followed the Pragmatic Programmer approach
early on in my career. It's partly why I learned Ruby back in 2003, and was
exposed to Lua and Haskell and others around the same time (and built pretty
neat production software in all of the above languages)

Over time it becomes less necessary to deep dive on new languages, but that
doesn't mean you should altogether stop, it just means that you're more of an
expert now and learning a new language to the point of mastery that you are
used to in your day to day work is a lot bigger task.

What the author describes is the dilemma with any kind of knowledge
acquisition. You always need to be learning more, but you have to balance that
against being productive with what you actually know. As an expert or senior
or whatever, I have a pretty good understanding of what the knowledge
landscape looks like. As a junior there's a lot more utility in doing a broad
survey before diving too deep.

------
fiddlerwoaroof
I think this sort of misses the point of the Pragmatic Programmer’s advice:
you should learn a new language every year for exposure to the ideas that
language has (e.g. Prolog to get a sense of how logic programming works, J for
array programming, etc.). This doesn’t necessarily mean learning the language
well enough to write production code and it certainly doesn’t mean switch your
primary go-to language every year.

~~~
Chris2048
> you should learn a new language every year for exposure to the ideas that
> language has (e.g. Prolog to get a sense of how logic programming works, J
> for array programming, etc.)

But why? what does that give you?

~~~
techbio
I can only assume this is revealed in the process or not at all.

------
TrackerFF
I've been a musician for far longer than I've been a programmer. During the
first 3-5 years of playing, I'd play for many, many hours. At my peak, I'd
practice for up to 8-10 hours a day. Before school, during school, after
school. I had my trusty one guitar, which worked for everything I needed.

Then I started earning money, and began purchasing stuff. This avalanches into
a full-blown addiction of constantly chasing / trying out new stuff. My
playing suffered, my practice routines died, my creativity went to shit.

Even though I was still quite skillful, I found myself playing/noodling the
same stuff, caring about pretty much everything BUT the actual playing/music.

I'm now back to owning a couple of guitars, and focusing on what's important.
Writing music, getting ahead, and improving.

And for some reason, that mirrors my experience with programming, too.

I'm not sure, maybe some people are just prone to that kind of stuff? Getting
caught up with the superficial things.

~~~
carlosdagos
Well I have an anecdote that works as a parallel:

During my first few years of surfing, I would try (and buy) lots of different
surfboards. Also happened to me that as I earned money, I spent more and more
on surfboards.

I moved countries a few years ago and sold all my boards back at home, and
just got two boards here (one for small waves, one for larger waves). That
turned out to be so much better for me. I don't spend so much time looking at
every detail of the surfboard, instead I just go surf. I try new things on the
surfboards I have, and it tends to be about techniques and less so about the
boards themselves. Occasionally I will try my mate's surfboards and I think
that they're nice, but not enough to justify spending more money on another
board.

I don't believe it's 100% about proneness to get caught up in that kind of
stuff. I guess for me it was more just trying to get the most out of the
experience. Ironically enough I wasn't surfing as much before moving to a
different country, whereas where I currently live I surf 2-3 times a week.
Maybe there's some parallels there? As in the more you actually practice X,
the more you're likely to find the subset of tools that actually work for you?

That said, I do still believe (and agree with the link) in a few times a year
testing out new languages, frameworks, etc, so see what the fuss is about, and
in the process learn new things that I might bring back to my current project
or toolset.

------
smitty1e
Tangentially related Is the idea that we should not eat any more learning
curve than absolutely necessary during a project.

The technical risk of integrating some fresh technology has bigger, sharper
teeth than most risk predators seeking to devour our success.

~~~
swiley
It’s done probably because that’s how the authors are making time to learn new
things.

------
chrismmay
For a long time it was fashionable to write server side java using POJOs and
Spring running in Tomcat or Jetty, and you could get very far just being very
good at Java and Spring. You still can.

With the advent and surging popularity of multiple server-side alternatives to
Java such as Javascript via Node.js, Python, Go, and others, Java is now
viewed as "slow to startup" in comparison and therefore less suitable for
cloud-scale deployments that must spin-up instances very quickly to handle the
massive bursts of traffic that cloud-scale platforms have been designed to
service.

I'm curious what people think is the best alternative to Java for cloud-scale
deployments. Javascript - ala Node.js? Python? Go? Something else entirely?

~~~
chucky_z
I believe Go is eating Java currently.

If you look at companies they're all quite different though. Apple uses a lot
of languages. Google uses a lot of C++. Facebook is a combination of things,
but AFAIK their main platform is still written in Hack. Netflix is probably
still mostly Java. Uber is Python + Go.

I honestly think Java is going to come back in fashion at some point after all
the recent updates, along with all the newer JVM languages ala Scala, Clojure,
and Kotlin.

If you're asking this for "what language should I learn?" I think knowing
anything typed + Python is an extremely strong combo.

~~~
DonHopkins
These days I don't think you can get away with not knowing JavaScript, unless
your thing is pretending to be a luddite, in which case you shouldn't actually
be using computers if you're actually a luddite.

~~~
chucky_z
What would you call "knowing JavaScript?"

I've written some greasemonkey scripts for automating work-related tasks, and
done some very basic editing for helping others with visual stuff. I've fixed
some folks node code, but that was just reading docs and applying the few
lines of change.

There are a lot of positions that never really touch js. My most recent
project was working a lot with Chef, which is just ruby all the time.

~~~
DonHopkins
That's part of the spectrum of "knowing JavaScript" that I mean, since you're
not afraid to get your hands dirty. But some "linguistically pure" programmers
hold themselves above it all and refuse to learn it out of pride because it's
deeply flawed and they don't want to sully themselves. Well guess what: every
language (and CPU architecture) is deeply flawed and riddled with historical
baggage, and programming is about getting your hands dirty and dealing with it
anyway. Even if you're programming in Lisp or whatever your idea of the
perfect language is, there's still a lot of tedious shit work and hacking
you're never going to be able to avoid if you want to get the job done. The
people who wrote the compiler that translates your favorite perfect language
into x86 instruction codes had to get their hands really dirty with deeply
flawed technology, and you have to respect them, because they didn't boycott
the x86 because the PowerPC was more beautiful.

It's hard to outweigh the advantage of using the same language in both the
client and the server, and right now, JavaScript is the only universally
practical choice on the client side, so it rules both sides now, in spite of
all of node's and npm's problems. WebAssembly will loosen JavaScript's
monopoly as it gradually matures, but right now all other languages but
JavaScript are second-class citizens on the client side, and it will be that
way for a while.

~~~
chrismmay
Transpiling TypeScript to ECMAScript5 using Webpack (as is done in Angular and
React) seems to be how folks are solving this. It does strike me as a rather
convoluted solution, but it’s a solution.

------
whiddershins
It’s all in the definition of “learn” in the sentence “learn at least one new
programming language a year.”

If you calibrate the definition of “learn” appropriately for your skills and
goals that advice is great.

~~~
AstralStorm
There's no way to properly learn a language in a year. Even for an advanced
programmer who understands many concepts, getting up to speed and
understanding idioms takes notably longer. I'm talking someone who has a few
years of in depth experience which is usually focused practice, not coding the
same thing over and over or playing around. You cannot learn those things at
work nor doing algorithmic challenges - maybe someone can actually make a set
of such exercises.

The advanced programmer in other language can fall into many traps and produce
non-idiomatic (usually overcomplicated) code.

Goes the same when learning a big enough framework.

~~~
AshamedCaptain
There is definitely enough time to master a new programming language in a a
year. This is not rocket science, programming languages are purposely designed
to be easy to grasp. I'd say less than a month for most languages, perhaps
only more if it's a family change.

Most people can learn to speak a new (human) language from the same "larger
family" (e.g. french from english) in less than 25 weeks.

~~~
Ididntdothis
You can be reasonably competent quite quickly but “mastery” is something else
and takes much longer. I have done C# for a decade now but I still discover
new stuff all the time or finally understand things I knew about but didn’t
really get.

Same with languages. You can be conversational pretty quickly but to truly
understand a language takes many years.

~~~
jniedrauer
Bear in mind that all programming languages are not created equal. The surface
area for a language with a lot of history like C# is much larger than the
surface area for a younger language like Go, for example. I've been writing
production Go for about three years now, and I feel like I have a solid grasp
on it. I've been writing production Python for more than twice that long, and
I still learn new things every few weeks.

------
JumpCrisscross
I separate my “learning” into deep and broad. At work, I’ll take on new
categories of assignments (broad) while maintaining a portfolio of profitable,
hard problems in my domain (deep).

Personally, I’ll study new languages or cultures or technologies or games. But
I’ll also develop—and necessarily, ditch—ones I’ve previously learned.

It’s easy to get caught up in learning lots of basics. Right after the basics
is the hard part of integration, which leads to deeper understanding. It’s
also easy to do the same thing every day, tricking yourself into the illusion
of mastery, and risking becoming the best in a dying field.

------
odyssey7
> THE BRIGHT, SHINY, INFINITE RABBIT HOLE

Wow, what an apt metaphor.

------
darkkindness
Key insight IMO:

> You can talk the talk like a champ, and be up with the latest buzz, but in
> some corner of your mind you may recognize that your basic skills are
> fundamentally lacking.

Learning for learning's sake is admirable, and it's easy to snub practical
application. But it's much like how you can only read a few thousand books in
your life -- the modern world is so full of novelties that you must carefully
choose what you learn. There is an inherent opportunity cost in all learning.

My personal razor for deciding what's not worth learning is: if I can't
justify teaching others what I've learned, it's probably not worth learning.

~~~
partyboat1586
I find it so hard to choose since almost everything is fascinating to me. I'm
terribly afraid that if I commit to any one school of anything I will miss the
truth buried elsewhere. I find it easy if I have a fixed end goal to pick the
most pragmatic options but outside of that I'm lost.

------
Animats
This seems to be a curse of the Javascript world. Every few months there's a
new "framework".

Also, for each new language, there's a new build system, with a different
directory layout.

------
JanisL
I think the main issue with trying to learn too many languages is that it is
exceedingly taxing on your memory capacity. Being a regular developer in a
language comes with a lot of context that you have to keep in mind. This gets
hard to do if you are constantly switching between languages/frameworks all
the time.

So there's definitely some balance that is good to strike between learning a
greater number of concepts and paradigms vs going deeper into fewer
languages/frameworks.

------
bsaul
I don’t see this being a trap to anyone working in a real company doing
software developpent for a living. Managers won’t let you recode the same
thing over and over in various languages, and you’ll somehow have to maintain
the software you’ve developped, optimize it, debug it, etc.. and that means go
pretty deep into one technology..

------
rb808
I have this problem. The OP talked about languages but didn't mention
frameworks, tools, cloud vendors, programming styles etc etc. It sucks because
you go to interviews where they only care about one language and one framework
and you dont know it all that well - same as the 99 others.

------
christiansakai
Can totally relate. I just stopped doing this recently.

