
Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer? - krat0sprakhar
Hi HN,<p>Very recently I stumbled onto a comment by Rich Hickey which I&#x27;ve reformatted in a gist[0] (unfortunately, the source is no longer available). Honestly, Rich Hickey is one of my programming heros and I&#x27;m a big fan of his ideas about programming. However, reading the response below, I couldn&#x27;t help but feel disheartened.<p>Rich Hickey says - <i>You don&#x27;t level up by switching games all the time, but by sticking with one long enough to gain advanced skills. And, you need to be careful to recognize the actual game involved. Programming mastery has little to do with languages, paradigms, platforms, building blocks, open source, conferences etc</i>.<p>Quite seriously, this is more or less opposite of what I&#x27;ve lived by in my career till now. As a backend engineer I can&#x27;t help not getting excited by React or not spending a month learning OCaml or building side-projects tangential to my 9-5 line of work. The worst part is, that till now I always felt that it is a sure fire way to level up as a developer.<p>The confusing part is that Peter Norvig, another great programmer has quite the opposite to say[1] (although one can argue that overall they mean the same) - <i>Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).</i><p>At this point, I&#x27;m really confused and I spent better part of the day mulling over whether I should go through the lectures of a recent Coursera course that I&#x27;m doing or should I dive deeper in my current stack e.g. Python &#x2F; Django.<p>What are your thoughts? Is there one school of thought that you agree to?<p>[0] - https:&#x2F;&#x2F;gist.github.com&#x2F;prakhar1989&#x2F;1b0a2c9849b2e1e912fb
[1] - http:&#x2F;&#x2F;norvig.com&#x2F;21-days.html
======
dsp1234
Whenever a question like this comes up among the people that I am mentoring, I
like to show them the "T-Shaped Employee" section of the Valve Employee
handbook [0]:

 _" We value “T-shaped” people.

That is, people who are both generalists (highly skilled at a broad set of
valuable things—the top of the T) and also experts (among the best in their
field within a narrow discipline—the vertical leg of the T). This recipe is
important for success at Valve. We often have to pass on people who are very
strong generalists without expertise, or vice versa. An expert who is too
narrow has difficulty collaborating. A generalist who doesn’t go deep enough
in a single area ends up on the margins, not really contributing as an
individual."_

[0] -
[http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)
page 46

~~~
boomzilla
This is exactly why a lot of people want to do a start up, or at least start a
side project that solves a specific problem. You get to to be the expert in
that domain, and in order to get the complete product out, you need to be a
generalist.

Another meme that's been thrown around is: "You are not the complete developer
if you've not written a compiler." I don't necessarily buy that, but there is
some merit: there is a lot of different skills required in a compiler, from
domain modelling and DSL design, to theoretical CS like grammars and parsing,
to very practical software engineering such as IO handling, string
manipulation, encoding, documentation, etc.

~~~
atmosx
> This is exactly why a lot of people want to do a start up, or at least start
> a side project that solves a specific problem. You get to to be the expert
> in that domain, and in order to get the complete product out, you need to be
> a generalist.

Hm, funny thing you mentioned startups. Apart programming related startups, I
don't think that startup-ers are "great programmers". I get the feeling that
most startup programmers (not all of them, but most of them) are somewhere
between average and novice level.

I get the feeling that most "great programmers" are not that interested in
startup (making money, living the thrill or whatever).

Most famous programmers, work in big corps for medium-to-huge salaries and
(most of the times) even getting paid to work on their side-projects (Dropbox
pays G.V. Rossum for Python-dev, Heroku pays Matz for Ruby-dev, etc.).

~~~
ankitml
FYI : Heroku and dropbox are not big corps.

------
btilly
Both are right, and they agree with each other. But you have to understand
what they are talking about to get it.

The point of Peter Norvig's advice is that once one has learned 3 different
ways to do one thing, it is easier to abstract out the fundamental principles
and think about when to take one approach or another. Which makes it easier to
understand the actual game.

Which leads into Rich Hickey's advice. Recognize that the game you are in is
programming. Which is the art of keeping software doing what we want to it to
subject to various constraints including timelines, changing requirements, and
so on. This is not the accumulation of esoteric information. This is not the
accumulation of prebuilt solutions. Those are necessary, but not sufficient.
You need both a skill set and a mind set.

I used to like chess so I'll use a chess analogy. In chess, and many other
games, there is a clear difference between tactics and strategy. Tactics is,
"I do this, he does that, I respond like so..." Strategy is the abstraction
across tactical situations to recognize things like the importance of
controlling the center, that attacks naturally proceed along the line of pawn
chains, and what affects the relative value of pieces in different situations.

You cannot learn strategy without knowing tactics. Because the accumulation of
strategic advantages is useless without the tactical skills to notice and use
the opportunities that arise. And mumbled slogans do not a coherent strategy
make. So learn tactics first. But to become a great chess player, you will
need to master strategy.

The same applies to programming. Programming tactics include languages,
paradigms, platforms, building blocks, open source, conferences etc. These do
not constitute strategy. Learn strategy. But you cannot do that without
learning programming tactics first.

~~~
e12e
I like that: strategy enables tactics. Much like logistics enables strategy.

------
pron
Programming languages matter some, but algorithms and data structures matter a
hell of a lot more.

While it is true that learning different programming paradigms can help you
evolve as a programmer, I strongly believe (I have been programming
professionally for about 20 years) that that is far from the best way to
evolve as a developer, and learning algorithms and data structures will help
you "level up" faster and better.

The reason is simple. Programming languages are a medium of transforming
programmer intent into something the computer can execute (perhaps
indirectly). This is not an easy task by any means, but all an ideal
(nonexistent) general purpose programming language can hope to achieve is the
reduction of what is known as _accidental_ complexity. Programming languages
vary only in how much burden, and -- just as important -- _what kind of
burden_ they place on you when you commit your chosen algorithm from your mind
to code on the screen.

Knowledge of algorithms, on the other hand, will help you tackle the far more
important _essential_ complexity of the problem at hand.

So, in a way, focusing on programming languages is indeed a distraction, at
least as long as you haven't yet familiarized yourself with the more
fundamental -- and more useful -- tools of computer science.

~~~
robotkilla
When people talk about learning algorithms, what do they mean?

I recently spent a few hours reading about and implementing A* for the NPCs in
a video game I'm working on.

Are you talking about being able to write A* and other algorithms from scratch
with no reference material?

~~~
coldtea
First of all, you should know that there exists an A* , and what it can be
used for.

Second, you should know when to use A* or something else, the trade-offs etc.

Third, you should know how to implement A* , when needed, with reference
material (you'd be surprised how many programmers can't read/understand the
reference material even when its given to them, or don't know enough
programming to put it in code).

Of course you could get by with never using A* or tries or whatever advanced
algorithm, not even in some ready-made API form. E.g. if you just do some CRUD
or some simple web programming. But for the kind of programmers we're talking
here, those three are paramount.

The thing you mention, implementing it from scratch with no reference material
might be impressive, but it's more of a circus act.

~~~
danenania
Aside from as a learning experience or display of prowess, what's the point of
implementing A* yourself?

In my experience, knowing which prebuilt algorithms and data structures to
reach for matters more than being able to implement them myself. Not saying
there isn't value in learning or that it doesn't help flex the problem solving
muscles, but in most software domains, I think that practically speaking there
are more important skills to focus on after you've mastered the basics of time
and space complexity.

~~~
coldtea
> _Aside from as a learning experience or display of prowess, what 's the
> point of implementing A_ yourself?*

Because for people working in those kinds of problems we're talking about (we
started from Valve and games IIRC, but it could also be Google, Facebook
engineers etc) you don't just download some off the shelf API.

You'll need to create something of your own to:

\- have the whole IP

\- mold it specifically to the domain logic you need

\- take control of it's memory and performance characteristics based on your
constraints

\- implement it in the language your company uses, for which no ready made A*
(or some other algorithm) is available

\- you'll need to make it talk to different infrastructure, libs etc

\- you might be the one writing the library API yourself

As I said, this is not about what a CRUD programmer will need. But as you can
see everyday in HN, people write these and other algorithms all the time in
their jobs doing more serious engineering.

------
noahlt
"Beware that an expert at X is not necessarily an expert about becoming an
expert at X." \- Peter Seibel
[https://twitter.com/peterseibel/status/471664135990566912](https://twitter.com/peterseibel/status/471664135990566912)

------
rqebmm
I think you're overemphasizing Hickey's first thought. His second boils down
to "be careful to recognize the actual game involved. Programming mastery has
little to do with languages"

To me it sounds like he's saying "understand the underlying patterns and
techniques that make good programs in any language" not "stick with one, and
only one, language until you know it inside and out".

~~~
gaius
Yes exactly that. In the same way you need a camera to be a photographer, and
you need to be competent in its operation, but the endless search for a better
camera is not what photography is about.

------
blowski
I think what he's getting at is that to be a master programmer, you need to be
master of something - and it doesn't really matter which language.

If you are thinking of learning a new language, ask yourself why. Is it
because it's going to make you a better programmer? Is it because all the cool
kids down at the Club House are talking about it? Is it because you're stuck
with a problem in a language, and instead of overcoming that problem, you're
just jumping to a new language hoping that language won't have any problems?

When you've really mastered one language, mastering a second one is much
easier. Whereas if you learn the basics of one language, and then the basics
of another, ad infinitum, you never really master anything.

Compare to learning to play musical instruments. Who is the better musician -
somebody that can play Chopsticks on 20 instruments, or somebody that can play
Brahams but only on the piano? The first has a lot more to learn than the
second.

Finally, it's better to master a domain than a programming language. In the
long run, it's more rewarding (personally and financially) to be the world's
leading expert in, say, security in C++ than it is to be the world's 10,000th
best developer in Ruby, Clojure, Go, etc.

------
bsima
I think Hickey is referring to more of an abstract "level up", while Norvig is
talking about a general accrual of specific skills.

Think how all programming languages can be reduced to lambda calculus or
Turing machines. And think how design patterns and algorithms can exist across
all programming paradigms. If you can master design patterns and algorithms in
one general-purpose language, then to pick up other languages you just need to
learn the syntax and idioms of that language.

On the other hand, a quick way to expose yourself to different programming
concepts is to take a crash course in very different languages, as Norvig
suggests. The risk with this method is that you never attain mastery in any
one thing ("jack of all trades, master of none", s/trades/programming
languages/)

I think Hickey is right in this one, but fundamentally they are talking about
two different things. Hickey is talking about _mastery_ , while Norvig is
talking about "programming success" ("success" is word with a slippery
definition, but to be "successful" definitely does not require one to be a
"master")

------
j_s
In the venerable 'well actually' StackOverflow tradition of not answering the
question: as a developer, don't consciously invest too much of your time
trying to become a better developer.

Instead, set aside time to become a better marketer. If you're a solo
developer you will need to get the word out to investors and customers about
yourself and what you can do. Working for someone else, you'll additionally
have to sell your ideas to your co-workers and management.

Even in just asking this question, you are demonstrating motivation to do your
best as you create. However, your creations will typically be far better
served by your ability to promote them.

~~~
twic
If the OP's goal is to make more money, this might be good advice. But if
their goal is to become a better programmer, it won't.

~~~
j_s
That is certainly a valid response.

Being able to convince others of the value of one's contributions tends to
create an expectation for even greater contributions - this driving force can
easily be directed toward improvement as a programmer.

------
dfan
Rich Hickey is one guy and this is what worked for him. That does not mean
that his experience generalizes to all developers. Listen to lots of people,
perhaps weight their opinions based on their success and your admiration of
them, and then make your own decisions.

~~~
perfunctory
I am not quite sure how to express it precisely, but the fact that in our
field the phrase "Rich Hickey is one guy and this is what worked for him"
doesn't sound ridicules, makes me a little sad. Mathematicians don't say
"Pythagoras is just one guy and it worked for him."

~~~
dfan
On the contrary, I think exactly the same thing is true in mathematics; not
everyone works or learns the same way, and assuming that imitating the path of
one person, no matter how brilliant or successful, is the only way to succeed,
is very shortsighted.

------
zaphar
When I started programming I was pretty bad at it. I didn't get good until I
focused on "really" learning perl. I mastered perl fairly well quite a few
years ago.

At some point I was no longer learning anything from perl and I tackled
something different. Erlang was my next deep dive.

What Rich is saying has less to do with how many languages you've absorbed
whether a lot or a few. What he is saying is that leveling up requires taking
the time to truly absorb and understand what you are working with.

I'm fairly polyglot these days. But the number of languages that I know deeply
is less probably about 3. With the time spent learning them measured in years
not months.

Peter Norvig is actually saying something similar. He's advocating a slightly
different route to the same goal. Learn the foundations of programming deeply.
The 4 broad categories he lists are foundations of programming that any
developer needs to learn deeply.

Both Rich and Peter advise investing the time to learn something thoroughly.
They just came at it from slightly different directions. I imagine they would
agree with each other though.

------
heleph
I liked what I first heard described as "t shaped" people when I read the
Valve new starter guide [0]. That is people whose experience covers a fair
amount of breadth with pockets of depth. The breadth is good because knowing a
lot about what is out there helps you know where to look when you encounter
new problems. Depth is also good because you don't really develop your
understanding of how things are put together and what the challenges are until
you get into a lot of detail. Multiple areas of depth, particularly where they
are related (say knowing oo and functional style programming well) are
particularly useful because what you learn in one area expands on what you
learnt from the other. You can start to really understand what the design
trade offs were and what works well in different situations.

There isn't one right answer though. The answer depends a lot on what you want
to do. Do you want to lead a team, become an architect, go contracting, become
a consultant, go into academia, join a Google, join a start up, write
financial software, help cure cancer, invent new ways to do things, become an
expert? There are lots of ways you can develop a career in software and
whatever happens will most likely be part chance.

Don't worry about it too much, except to make sure you don't get too
comfortable in a particular area. If you keep trying to challenge yourself and
doing things that are interesting, you will keep getting better. Doing things
that are interesting to you is important because it'll help you avoid getting
too hung up on what everybody else knows and will help fuel you through the
parts that are painful or tedious.

[0] -
[http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

------
gauravmc
Rich Hickey's advice is shaped from his experiences and following his advice
can lead to his kind of career. Rich Hickey and Peter Norvig, although both
successful, have different experiences and hence different careers. If you ask
someone like Bill Gates, he'll have another much different twist to his
advice. Each successful collection of skills (deep, shallow or mixed) will
lead to certain unique career; which one you regard highly is up to you.

Although an important caveat remember is, following some successful person's
specific advice may not even work for you if there's a big difference in your
basic brain circuitry compared to his/her. Your best bet, IMO, is to commit to
the projects you feel 'hell yeah!' for and say no to the rest (more about hell
yeah vs. no here: [http://sivers.org/hellyeah](http://sivers.org/hellyeah)).

The bottom line is: Never ask advice of someone with whom you wouldn’t want to
trade places.

------
austinz
I think the missing piece is here:

"I am not questioning the many benefits of broadening or learning activities,
just the premise that they lead to any sort of mastery." \- Rich Hickey (from
the same gist).

Norvig is speaking about becoming a better developer by becoming exposed to
tools that solve problems in different ways, so that you can internalize those
different problem-solving techniques and apply them when appropriate. But
exposure alone has only a limited benefit - at some point being able to write
a quicksort in a new language is going to produce diminishing returns. At some
point understanding the advanced techniques offered to you by a programming
paradigm is going to require studying that one paradigm to a greater level of
detail.

Hickey is speaking about becoming a better developer through 'mastery' in the
sense of thoroughly understanding a system, having the ability to acquire new
information, identify and solve problems that comes only through extensive
experience.

These are two different ways to become better as a developer. Hickey's point
is that the 'skill ceiling' for the former is very low - once you've been
exposed to a number of different paradigms, you can either continue learning
even more languages for little marginal benefit, or you can begin to master
one or more of the paradigms you've seen. And that mastery builds a whole
different set of skills that will make you a better developer no matter what
toolset you end up using.

> I can't help not getting excited by React or not spending a month learning
> OCaml or building side-projects tangential to my 9-5 line of work...it is a
> sure fire way to level up as a developer.

Do you feel the side-projects you've worked on in the past have made it easier
for you to work on your job, or your current side-projects? Have they given
you more insight? Do you come across solutions more easily because...

* you've seen and solved a similar problem before?

* the month you spent working on OCaml gave you insight into a functional way to reframe the issue?

* your exploration of react.js gave you a better appreciation of client-side engineering issues?

* something else?

If you can honestly say 'yes', you are almost certainly leveling up as a
developer. Otherwise, you might want to examine whether your side-interests
amount to more than dilettantism and whether you might be better served
spending some time focused on a single topic.

------
jlukanta
I don't think the two are mutually exclusive. You need both variety and focus
to excel. The key is to know when to shift gear between the two modes. Why
don't you just do whatever that you find fun and challenging? That's usually
the best indicator of what you should do.

~~~
Ologn
Yes. Donald Knuth sometimes quotes Huxley - a good education is learning
something about everything and everything about something. There should be a
center to studies or you're all over the place, but having extreme tunnel
vision is not helpful either.

------
krat0sprakhar
Clickable links -

[https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb](https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb)

[http://norvig.com/21-days.html](http://norvig.com/21-days.html)

------
davelnewton
You can't master something by switching games all the time, by definition.

"... switching games _all the time_..." is the key.

What does "all the time" mean? Does it mean not dipping your toe into new
waters? Of course not; exploration also deepens your understanding of where
you currently are.

Does it mean never changing your path? Of course not, but changes in direction
should be done mindfully, not at the whim of the current front page of HN (or
anywhere, or anybody, else).

"Spending a month 'learning' OCaml" is barely divergent from the path you're
on. It will affect what you're currently doing, to some degree. A month is
(essentially) nothing.

In any case, everybody is different. The real question is whether or not _you
're_ happy with the direction you're headed.

~~~
cdaven
Yes. Learning new languages and libraries is helpful to a point, but learning
_all_ new languages and libraries is a distraction.

------
zubairq
I totally agree with Rich Hickey. Very important to have mastery in one
language at least. Once mastered feel free to experiment with other languages,
but do not just learn several languages and know them only at a surface level

------
abathur
My thought (predating your post) is that there are two ways you can stay on
the edge of your comfort zone; one of these is by expanding laterally into
things you don't already know much about, and one is by expanding vertically
into things you do already know about.

The risk of expanding laterally is that you can pretty much surf on a fairly
clean wave of documentation, examples, tutorials, SO q&a and github code to
solve most of the "problems" you face (and many of these "problems" are shit
like "learning an API" or "gotcha config files"). This isn't to say that this
is how expanding laterally will work in every case, especially when you're
picking up a lot of knew paradigms.

The upside to expanding vertically is that you're eventually going to run into
problems or questions that you can't just research your way out of. Not to
denigrate all of the other learning we do, but I think these times when we
have to go out into the wilderness and test ourselves against problems that,
even if only by dearth of documentation, are effectively novel, are when a lot
of growth happens.

Of course, it's perfectly possible to work in one domain and never have to
really stretch yourself. It's also possible to be perpetually expanding
laterally into technology so new that you spend more time testing yourself in
the wild than many who go "deep" on more thoroughly-trodded ground.

------
chipsy
I would go with the sort of answer that dodges anything concrete: It's not
about which specific things you do, it's about doing things that seem scary
and unfamiliar.

For some people, that means learning to write really tight low-level code for
tiny hardware. For others, incorporating more advanced mathematical
constructs. And for a third group, learning how to design a certain category
of applications really well.

To round yourself out means not to stay within your comfort zone, but to
attack the missing parts as well so that even if you aren't a master at those,
you have working knowledge. This is also familiar to those who have studied
drawing or playing musical instruments - there are many cases where you can
get by with what you already know, but would do better if you took the time to
study a technique in detail.

When Hickey says "you reset from zero" by only doing new things, he's
specifically referring to repetitively relearning basic tasks in software
development. That's the stuff that you're guided into looking at constantly
because there are slick presentations and hypemen trying to get you to pick up
their tool, and their tool has to look easier(i.e. more basic) than the other
tool because that's the only way you'll pay attention to it.

If your approach involves something that is kind of challenging that you build
from scratch, with new domain problems, that is a Good Thing and you'll surely
get something out of it.

~~~
moeamaya
I would extend this further and suggest you challenge yourself by following
your interests. If you happen upon a C++ graphics library that your favorite
game is built upon, your curiosity will be enough to propel you forward and
learn new things based purely on intrigue.

If ultimately you go the route of wanting to learn a particular programming
paradigm, I would still encourage you to try to solve a problem that resonants
with you personally. The problem itself becomes the method by which you learn
programming and not the other way around.

------
fit2rule
Wow, I'm quite literally floored by what is completely and utterly missing
from this entire discussion: The User.

It doesn't matter what or how you program, as long as you have: The User.

If you have to spend your time competitively learning some new-fangled
slippery, slidey, pretty little ball of tangled chains of bits and pieces of -
whatever - it doesn't matter for a fig if you don't have: The User.

With The User as the principle focus of your goals and career as a developer,
programmer, coder, hacker, binder-of-pretty-gthings, you can escape all misery
and just learn to enjoy the ride completely. Because its The Users' bus, and
if you don't have The User driving it, it ain't going no-Where.

So the whole perspective about Industry standards and real reasons for just
using one thing, and one thing only, and sticking to it and becoming good at
it: this is only ever acknowledged, worth a fig, if you have: The User. I've
still got users of 20+ year old software stacks that I'd love to replace with
some newfangled jangle. Have you?

 _That_ is how you prepare yourself for a career, in service of The User.

~~~
angersock
Question was how to get better as a developer and engineer--relying on The
User is the worst possible way of solving that problem, because they don't
care anything about the tech...they just want results.

Your advice is correct about how to get better serving users, but that was
very much not the question being asked.

~~~
fit2rule
Well, I really mean that in spite of whatever you do to improve yourself as a
developer/engineer, it doesn't mean a thing if you don't have a User. Ever.

And even if Developers can themselves be Users, in the sense that they gain
some sort of joy out of consuming the developer tools of the trade, its still
just navel-gazing until there is actually some sort of _use_ out of the
activity.

Real developers build things for users. It doesn't matter how good or bad they
are, as developers, if there is a User: win.

------
bitwize
You have to learn the big concepts in computing. These include low-level
details like how a Von Neumann architecture works, memory and pointers, I/O,
how the OS, network, and file system work, etc. But it also includes useful
abstractions such as data structures and ADTs, algorithm efficiency, objects,
functional programming and lambda calculus, design patterns, and big-picture
questions of what kind of system should I be building in the first place.
(Should I build one big monolith? Should I break it down into pieces? How
should they communicate? and so forth)

This will necessarily require familiarity with a variety of languages and ways
of thinking about code. When you find a particular style of building software
that suits you well, you can invest a lot of time in becoming expert at
building that kind of system, making it run fast, and making it clean and
maintainable. But you will also have a deep well of knowledge to draw from
because you've looked at the computing field from a variety of perspectives.

In other words, both Hickey and Norvig are right, to an extent.

------
VLM
WRT Norvig if you learn clojure to learn functional and parallelism, you'll
win, but if you learn clojure so you can write visual basic in clojure you'll
lose. He's giving a necessary but not sufficient option for each broad field
you need to understand.

WRT Hickey if you "gain advanced skills" by using the best language for the
job, then the language mattered with respect to the learning process. But once
you understand the "fun" of concurrency, the language you used is no longer
relevant. You can talk ACID compliant transaction using clojure STM as a
vehicle or your favorite SQL, the language just doesn't matter any more.

The point of a reading primer "see spot" "see spot run" isn't to learn about
dogs, and once you can read, you don't need the primer anymore. There are
learning techniques and textbooks that are better at learning than others...
the the mastery, if it ever comes, came from sweat, not the book itself.

------
mikekchar
What you do to level up depends on your level now.

Novice: Keep the scope small. Try not to get confused. Concentrate on small
successes and learning the basic "rules".

Beginner: After building a base, branch out and expose yourself to areas where
the "rules" are different.

Intermediate: You have a base and you also have some idea that there is more
to the world than your base. Write a lot of code. No, really a lot. Read a lot
of code -- twice as much as you write. Become an "expert" in an area and
create an understanding of why the "rules" are the way they are.

Advanced: You are an expert at something, but you realize that you have only
scratched the surface. Question all the "rules". Throw them away. Make new
ones. Explore the world searching for abstractions that you missed before.
Write a ridiculous amount of code. No, I mean epic amounts. Read 4 times as
much code as you write. (My negative alter-ego adds: Despair as you realize
that you aren't so much looking for a needle in a haystack as a needle in a
dung heap. Despair even more when you realize that the dung heap was made by
you).

Novice Again: You have mastered a few subjects. You have rewritten the rules.
You now have reached a state where you can clearly see that you understand
nothing of consequence. Keep the scope small. Try not to get confused.
Concentrate on small successes and learning the basic "rules".

Note that it may take a lifetime to reach the final stage and I would say that
the vast majority of programmers don't reach it. Scale your expectations
accordingly.

Finally, to comment on your question about whether your should review your
Coursera course or dive deeper in your Python / Django stack: Write a lot of
code. Doesn't matter what. Hey, how about implementing something in Python on
the topic of your Coursera course? But not a toy -- write at least 10,000
lines.

------
FLUX-YOU
You already have a job so I'm guessing you have the practical skills needed to
get paid, otherwise I would recommend sticking to one stack.

Personally I feel Norvig's advice wins out here, even if you just run through
books to get some of the basic ideas and never build anything with the
additional languages (you should though!). The point is to get out there and
try new things and maybe something will get your imagination firing on all 12
cylinders and help you decide.

I'm not even sure what Hickey is getting at as he's stripping out all of the
things that we use to communicate between one-another about programming and
putting some nebulous concept (that isn't explained) as the core of
programming mastery. 'Late game' paradigms, building blocks, and platforms ARE
the advanced skills!

------
ribs
The musician analogy is poorly chosen. Playing an instrument is a highly
physical, hand-eye(-mouth)-coordination challenge.

But mastering a platform - be it a language, a framework, a library - will
help make you a much better developer, it is true. If you don't know enough to
exploit the relevant features of the platforms you're using, you'll produce a
poorer solution than otherwise. You'll use more code, or fail to encapsulate.
Your solution will be harder to maintain and adapt.

But then again, if you're busting your ass writing parallel applications in
C++, managing locking and threads, when you could be using actors in Akka,
your solution will have the same shortcomings compared to the one you could
have developed had you been aware of the qualities of that platform.

So yes and no :-)

~~~
code_duck
Learning to play an instrument taught me how to learn complex skills in
general. There are similarities in the processes of learning almost anything -
be it martial arts, glassblowing, flamenco dancing or web programming.

In the beginning, everything is new and it can be overwhelming. Humbleness and
discipline or dedication is required in the beginning. Small successes lead to
pride and enthusiasm, and gradually, over years, your skills grow. In playing
guitar and glassblowing, i recall various times where I was satisfied and or
pleased with my skills, and then looked back at those times years later and
was amazed by how much more sophisticated my skills have become.

With that experience, I never felt frustrated learning Python, JavaScript or
SQL because the process reminded me of my previous learning experiences and I
knew then all I needed to do was put in time and seek information.

As an aside, I might note that there are mathematical aspects to creating,
playing it and even appreciating music. Every system of music has rhythm and a
set of tones that is based in someway on numbers – the 12 notes of the western
octave, time signatures, 8th and 32nd notes and so forth. Learning the complex
relationships of systems like jazz chords on the guitar or piano is very much
a mental exercise as well as a physical one.

------
cliftonk
Breadth and depth are both very important. Too much breadth and you have a
hard time getting any non-trivial job done. Not enough breadth and you use the
wrong tool for the job. If you want to be the best dev possible, it's probably
good to keep up with the latest in terms of adding those alternative solutions
into your own conceptual framework, but it's distracting to spend too much
time with them unless they truly are the best tool for the job at hand (and
marginally so in terms of time invested).

I suppose it's like reading non-fiction books. As soon as you believe you
understand the author's perspective in sufficient detail, it's often best to
set the book aside and move on to the next one. You are under no obligation to
read every page.

------
bjornsing
In my experience great developers rarely focus on the tools (except if that's
what they're building of course). It's like with great authors; what you have
to say is far more important. Most great books were written on a typewriter,
some even with pen and paper.

------
bingo76
Theoretically both works - the single system depth will allow you to encounter
new issues / see how the stuff you developed panned out.

But that's too slow a process IMHO due to how organizations work and i
wouldn't do it unless the field, you are in, is really deep to start with eg
gaming/distributed computing etc. You also face the risk of being in the same
rut over and over again and all of a sudden the rug could get pulled from
underneath you (hopefully so that you will learn new things).

I would say stick around until you gain expertise (and actively do so) in the
domain and know its problems and its typical solutions and then move on 3-4
yrs ?

I was shoved around due to market forces ... its the best thing that happened
to me IMHO

------
brudgers
I enjoy listening to Hickey talk in abstractions because it always gets
grounded in practical considerations. I suspect the "actual game" is solving
problems. At the end of the day, that's my understanding of why he wrote
Clojure and Datomic recently and switched from C++ to Java earlier in his
career.

Because Clojure was targeted at working Java programmers who might benefit
from the power of Lisp and working Common Lisp programmers who might benefit
from the power of the JVM, I don't really see any contradiction between
Hickey's quote and Norvig's. For each, the reason to know "another language"
is it helps a person solve problems.

------
art-of-code
There's no point learning 10 new languages if what you can do with it doesnt
go far for example from a normal CRUD application/Hello World application.
Just set appropriate goals. In the end what you will be very good at is
creating CRUD applications. Be objective in what you will be learning. For
example, being a backend developer, you can learn new tech that further
augment your skills.

For example use Ruby/Rails on the backend or a web app, learn Objective-c to
create an app that gets data from that RoR app, and maybe use go to create an
API for a section that is performance heavy, etc... So that everything builds
up. You need to establish goals.

------
lukasm
Valve has a concept of T-shaped people. You have a broad range of skills and
you have one domain that you know really well. Know 8-12 languages, by good
with 2. Similarly, if you are marketing guy knowing what EBITA is may help
you.

------
freshhawk
I don't see these contradicting each other. I'm also a huge Rich Hickey fan
(my main language is Clojure at the moment), and he certainly has emphasized
the benefits of a broad base of knowledge and experience in various talks.

But here he is saying that you can't only explore the breadth of programming,
you also have to dive deep at some point and get the experience of mastery in
something. I can't see either one disagreeing with the statement that you want
to have some breadth of experience first but that mastery only comes
afterwards from focus.

------
agounaris
I think you need to have a few languages in your arsenal(but not too many), I
like php, python and clojure for example. This doesn't make me an expert to
all of them but given the proper time I am able to create any app in those
languages.

Apart from this, it's true that you need to invest time in learning how to
architecture staff... unix, networking, programming internals, keeping
yourself up to date with whats going on in chaching, queuing, databases.
Patterns and solutions to real life problems are have common solutions to any
language/platform.

------
mgkimsal
Both. You get a better understanding of when/where to focus by understanding
what the similarities and differences are between languages. I'm better now
because I've done PHP, VB, Java, C#, Groovy, Perl, Ruby and some others, even
though I focus about 90% of my time on just 2 of those areas.

You get a better idea of what 'advanced' is both by diving deep in to one
language but also by digging in to other languages - seeing how they do stuff,
what's possible, what's elegant, what's a hack, etc.

------
andreyf
No matter how deep you dive into Python / Django, you will not understand
what's possible with Prolog. I think what Hickey is getting at is that you
should be aware of what computers are capable of, not just Python / Django.

Re: parallelism, as a useful and simple exercise, try writing a load tester in
Python and then try it in Go (simple program that hits yoursite.com as hard as
your network connection will allow).

------
jlees
I subscribe to a bit of both -- the Broken Comb approach. Being a little of
everything but never getting deep into anything is just as dangerous as being
a one-trick pony. [http://spin.atomicobject.com/2013/06/27/broken-comb-
people/](http://spin.atomicobject.com/2013/06/27/broken-comb-people/)

------
hoodoof
Do some things deep, others shallow and pursue your fleeting interests - all
will contribute to your levelling up.

Just make sure you do become deep with some things otherwise you'll be just a
dabbler. You need deep expertise in some fields to be a power developer.

------
random_coder
This seems to be the original discussion.

[http://jasonrudolph.com/blog/2011/08/09/programming-
achievem...](http://jasonrudolph.com/blog/2011/08/09/programming-achievements-
how-to-level-up-as-a-developer/)

------
olafleur
I think you have to balance the two and not put all your eggs in the same
basket.

Choose one or two language and get mastery from these, but also look for other
languages to learn from.

That way, you'll have a balanced portfolio.

~~~
olafleur
Also, maybe look at Valve's "T-shaped person". That can be a useful guideline.

------
calcsam
Do you want to be a really expensive Japanese sushi knife? Or a high-quality,
extremely versatile Swiss army knife?

Those are the two career paths illustrated. Different people have difference
preferences.

------
vespassassina
Is my opinion that your dilemma could be better answered by reading: "Code
Complete". Just read and apply as much of it every day, for next level :)

------
uchooseyourself
From the moment you started focusing on the result (becoming a better
programmer) and you forgot to enjoy the journey (why would you ask if you
should go through the lectures of a recent Coursera course if that's something
you enjoy doing?) you failed.

In my opinion, do what you enjoy doing, nothing else matters as long as you
enjoy what you're doing.

------
Estragon
Where is the original discussion? Googling the text just gives me similar
gists.

------
aerialcombat
Gotta do both, bro.

------
krick
> The worst part is, that till now I always felt that it is a sure fire way to
> level up as a developer.

So here's the thing: you believed in something, were living by this and felt
just fine. Now you've heard some other guy with famous name disagrees with
that and you feel down and confused. Isn't that funny? To be blunt, I think
it's simply ridiculous. Having "a hero" in the strong sense of it is a problem
by itself, but whatever, here you're discussing a practical issue. You think
there's some goal you'd like to achieve, there are some practical advises from
several people on how to achieve it, some are contradictory, as always. If you
have confirmed, that something works, what's the problem? If you didn't
confirm anything and you don't know how to solve it analytically, the only
option you have (well, at least in this case) is following some of the advices
and see what works.

But I'll go as far as saying that even that indecisiveness isn't your problem.
The problem is, as it often happens, that you don't know what you want. You
believe there's _something_ you'd like to achieve, but you don't really know
_what_. You never really formalized it, and hence you cannot judge if some
advice would be helpful or not. Yet you strongly believe you want this
"something", but as you don't know what is that, you cannot really decide on
direction and it worries you. In that case only meaningful advice you can get
is the one Cheshire Cat has given Alice, IYKWIM.

For what it's worth, I also have an opinion on that matter. I don't really
believe in "mastery". I believe there's world full of things you can interact
with and state of some things is different from that you'd like it to be,
which produces a notion of _problem_ , which you are willing to solve. Solving
some specific problem may require skill, domain knowledge, physical strength
or something else. Telling me that learning to make good sushi takes 70 years
will only make me yawn or chuckle, depending on my mood, but sure it takes a
lot of practice. And, generally, to be able to solve skill-related problems
you need to practice. However it is quite likely that subset of problems you'd
like to be able to solve in some domain (even skill-related) requires very
little to none practice, as you can resort to using better tools (maybe
_humans_ ), some clever trick or getting _the essence of it_ is in fact pretty
easy, when you have a good teacher.

So, as I don't believe in "mastery" both Hickey's and Norvig's advices mean
pretty much nothing to me, and I partly agree and partly disagree with both.
Specifically, I almost completely disregard the notion of "being not my
domain", as I've repeatedly found that learning seemingly unrelated fields can
improve my understanding of others and sometimes happens to be just handy
(kinda point to Norvig). However I feel that as long as you have many enough
options to cover all range of problems you'd like to solve, the less tools you
use — the better it is for you, as it removes mental clutter and helps
concentrate on actually _solving the problem_ , not thinking too much about
"what is better option to solve it" (point to Hickey). The famous
presentation, where Hickey compares programmers to musician, I find
compelling, but completely ridiculous when you actually think about that, as
being a programmer has almost nothing to do with being guitar player. I
disregard popular saying about programming being an art. There're more strong
opinions of mine, which I can support with arguments, but that isn't really on
topic and I doubt it would be of any interest to you as my surname isn't
Norvig nor Hickey.

 _But, yeah, well, that 's just, like, my opinion, man._

------
ebbv
He's 100% correct. Learning new languages/frameworks/tools is fun and can be
useful if you have projects that can make use of them. But they don't
contribute to making you a "better developer" very much after a point. There's
diminishing returns on learning new languages. So, once you've learned a
dozen, then learning the thirteenth or the twentieth will not contribute
greatly to your overall developer skills.

Creating a new project unlike any you've done in the past will do more to
contribute to your skills as a developer, whether that project is in a new
language or one you already know, than just picking up a new language and
making your 10th simple blog.

------
shiggerino
I'm going to have to agree with Hickey on that one. But then again, imagine
the horror of dedicating years of your life to a language that turns out to be
complete garbage.

I also think you need to take into consideration that the Norvig essay is
dripping with hyperbole.

------
pfraze
It's a breadth and depth thing. You need both.

