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... page 46

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.

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.

"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

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".

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.

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")

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.

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.

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.

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...

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).

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

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.

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.

Clickable links -

https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb

http://norvig.com/21-days.html

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.

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

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.

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.

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.

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.

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.

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!

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 :-)

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.

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.

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

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.

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.

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.

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.

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.

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.

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).

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/

undefined

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.

This seems to be the original discussion.

http://jasonrudolph.com/blog/2011/08/09/programming-achievem...

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.

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.

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 :)

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.

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

Gotta do both, bro.

> 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.

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.

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.

Programming is a craft. You'll learn to be a good developer by developing applications. Norvig and Hickey are more in the research domain. A far majority of application for any given platform will be written in the same languages, which mainly has to do with tooling. A lot of really good programmers are awful developers.

"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

"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

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.

I don't see these are in conflict at all. Both talk about spending the long period of time needed to attain Mastery. Mastering concepts is essential but mastering your way of working so as to maximize your productivity and the effectiveness of your practice is equally important. You do not want to be a dilettante who knows everything but produces nothing of substance or value.

I wrote a book specifically on how to go from good to great or at least how to become the best you can be... targeted to developers in the first 5 or maybe even 10 years of their career.

Level Up! How to Become a Great Professional Software Developer

https://leanpub.com/level_up

None of it has to do with any specific language or platform. The techniques I describe are not the only way to do it but I guarantee if you take at least some of them to heart, you will improve a great deal. I do espouse going deep on at least one platform or stack for at least several years. You might even get so formal as to build a competency map to track your progress. Much of what you learn is transferrable. 10 years or 10,000 hours will get you there no matter what but following the techniques I describe will get you there faster.

Steven Talcott Smith, Master Developer, Chief Happiness Officer, ÆLOGICA

http://aelogica.com | Great Rails teams for hire

http://appexpress.io | Rapid Application Development

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