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

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.

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

FYI : Heroku and dropbox are not big corps.

It is a necessary truism at every abstraction layer there is at least one developer (dead or alive) who has the ability to rebuild the abstraction layer from one layer down. Speaking from a society point of view: The meme thrown around ensures developers learn to do exactly that and keeps the developer work force well trained and skilled, to rebuild things where necessary.

You hit the nail on the head.

Beyond the scope of HR, in my experience it's the mix of both breadth of knowledge (context) and the depth of understanding (skill + experience) that is most useful.

Having a high-level understanding allows you to step back outside of the 'work' to instead focus on the objective, and someone with significant background knowledge and experience can utilize that to first conceptualize the optimal approach before hammering the nails.

Knowing what to apply, where, and when is equally as important as how. And there are fantastic programmers & hackers on each end of the spectrum, but in my experience developing that contrast is more intrinsically valuable.

I think this is the key. It's more wise than it may seem at face value. It's important to recognize the importance of both deep specialization and a broad understanding and ability to connect the dots at the same time.

I figure that a degree in CS + some curiosity would give one the horizontal knowlegde, and x years of employment in a specialised field would give the vertial knowlegde.

It's different horizontal

It just sounds to me like they're saying they only want engineers who already know everything about everything. Sure, I'd want that too if I were hiring, but it doesn't seem very realistic.

It also makes me wonder about their ability to manage people with different skill levels and areas of expertise. And of course, having used Steam, I'm not at all surprised.

Not to me. It sounds like they want people who have a wide variety of shallow-ish knowledge (but still an actual understanding of whatever area it is), while also having very deep knowledge in one or two areas in particular.

> It also makes me wonder about their ability to manage people with different skill levels and areas of expertise. And of course, having used Steam, I'm not at all surprised.

Weird that that's the conclusion you come to. Valve is an incredibly successful company with over a billion dollars in the bank. They've produced some of the most influential games of the past two decades (Half-life, Counter Strike, TF2, Left 4 Dead, Portal, DoTA2... it's actually hard to name them all).

They also haven't put out an entirely in-house game since the Orange Box.

The management failures at Valve have been pretty spectacular, and expensive, of late, it's just that because they are a private company, and because Steam makes all of the money, they can continue to have large expensive failures like the VR or the Steambox until doomsday.

Valve is not other companies, and their position is such that it's not advisable to take any too serious advice from how they run things into the real world.

Any links describing the management failures?

Jeri Ellsworth has been quite vivid about the actual, rather than the idealized, version of how Valve actually works; there's some thoughts here: http://www.develop-online.net/news/valve-s-perfect-hiring-hi...

Besides shelving the VR project that she was reportedly working on, there's also the Steambox which still doesn't exist (the only hardware to even pass prototype stage eventually had to abandon SteamOS and release on its own), the utter crapshoot that is their attempts at virtual economies (TF2 hats: prints money, trading cards: useless boondoggle, everything involving Counter-Strike: possibly lucrative now, but PR disaster after PR disaster with their fans).

Valve spins the utopian image, and generally keeps the veil down enough that goodwill and fandom manage to sustain the myth, but I suspect the cart's been off the rails for sometime, and if it weren't for Steam we'd have long seen a very public failure by now.

Sounds like every company, ever.

> (Half-life, Counter Strike, TF2, Left 4 Dead, Portal, DoTA2... it's actually hard to name them all).

Actually, it's not that difficult. Of what you listed, only HL was original IP.

Valve put a lot of work into digital distribution, and have pretty much owned the PC digital distribution market.

With console and mobile gaming dwarfing the PC market, and big publishers like Ubisoft and EA getting into their own digital distribution, I'm curious to see how Valve continues to grow.

That said, I admire them as a company.

Speaking as someone in the game industry, Valve certainly has it's problems, but they aren't platform problems.

PC is stronger this generation than it was last generation, I'm not sure about the numbers but I suspect that it is ahead of both consoles, and it might be ahead of both of them combined, and I'd expect this to only be get more true. Porting to PC is pretty much just porting the parts that interact with the OS or GPU for this generation, due to both consoles using x86-64.

And mobile is a joke. market might be huge, there's a reason very few established game companies care about it at all. It's extremely unpredictable, and the expected price of games is far below what is realistic. Even if you make a hit, the amount of money you'll make is far from the amount of money you make from a hit on any other platform (hell, it doesn't even come close to the budget of most games). Honestly, I think the only way a company can hope to turn a profit on mobile is with IAP or shovelware (or both), and I don't see that displacing console or PC gaming any time soon.

I wouldn't mind seeing steam displaced, but I don't think it will be by EA or Ubisoft, largely due to the fact that they're both about as popular as Comcast, which seems to be due to them being massively out of touch.

Respectfully I disagree with most of what you're written, wrt to growth.

When I see my friends 3 year old daughter playing Geometry Dash on his phone, I know that the PC can't compete with that.

PC ports are still and after thought. Games use a lobby system instead of dedicated servers. Only a few companies (Valve being one of them) target the PC market first. Pretty much every other AAA publisher looks at the PC market as an after thought.

Don't get me wrong, I'm a die hard PC gamer.

The problem with your original statement is that you have combined Mobile and Console together VS PC, which is a pretty bad basis in my opinion.

PC vs Console vs Mobile would be a more reasonable competition.

From some reports PC gaming market seems very healthy indeed from monetary perspective.

http://usfinancepost.com/pc-still-gaming-market-is-double-co... http://www.gamesindustry.biz/articles/2014-01-28-pc-gaming-m...

Mobile has been predicted to reach the size of PC gaming, but not to necessary dwarf it anytime soon.

http://www.mobilemarketer.com/cms/news/research/3892.html

So certainly if you combine mobile and console it's larger than PC. Says a lot that it takes to distinct markets to overtake PC.

In my opinion all the platforms have their pro's and con's, and none of them are going to disappear anytime soon.

> In my opinion all the platforms have their pro's and con's, and none of them are going to disappear anytime soon.

I wasn't suggesting that PC gaming will disappear. However, it's clear that PC gaming isn't a growth sector. Given that is where Valve dominates, where does that leave them?

Valve may not consider themselves a growth oriented company, but they do look for opportunities to innovate.

I should clarify that I have enjoyed some of their games. Particularly the Half-life and Portal series'.

That said, actually using Steam is an awful experience. Literally 50% of the time, when I launch Steam, it immediately stops and gives me a dialog saying I'm not connected to the Internet, despite that I have other Internet-using apps open and working fine. Quitting and immediately restarting works just fine for no apparent reason. I have several examples of things like this that show a lack of quality in their products. In my opinion, that is usually an indication of poor management as they aren't concerned with the quality of their product.

> they want people who have a wide variety of shallow-ish knowledge (but still an actual understanding of whatever area it is), while also having very deep knowledge in one or two areas in particular

Sure; every employer does. But it's dodging the more interesting question, which is: faced with one candidate who has broad but shallow knowledge and another who has deep but narrow knowledge, which do you pick?

If you're Valve, then neither, because you likely have enough T applicants to not have to settle for a | or a __.

I think it's more engineers who know something about everything, and everything about something.

That would be a square employee, not a T-shaped one.

Or perhaps "well rounded"

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.

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

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.

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?

I can't speak for anyone else but I think the important thing is understanding the tradeoffs of different ways of accessing data.

At it's simplest you have things like checking for existence using linear scans of arrays. Anyone with experience sees that as a bad thing to do because they understand that it's inefficient for any sort of sizeable array. But those who don't understand algorithms or data structures won't even know there's an issue. And that's the simplest case really.

When you have a list and you need to efficiently add and remove items from both ends - then you want some sort of double-ended queue. I know where to find the one in my std lib and I know when I need to use it - which it turns out is almost never - I thought I did the other day, then I found a simpler way, which was actually a bit disappointing :)

Then, as you say, you have things like A* or R-trees. The more of these you have an handle on - even just to know they exist, the better position you'll be in when you need them.

But I don't even think that's the most important part of knowing data structures and algorithms (and really, I'm sure none of that's news to you if you're implementing A* searching). For me it's more about understanding efficient patterns for data access. So much of the work I do is about efficiently pushing data around in different forms. Often having a core chunk of data and then a couple of different indexing structures to allow me to interrogate it depending on the info I need.

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.

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.

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

Time an Space complexity are moving targets too. The rapid change of the importance of memory locality will soon make a lot of the hard and fast data structure advice useless. At least if you program in something like C. Those n's are a lot bigger then they used to be.

Some aspects of this in the culture are disturbingly binary and the world has WAY too many people who don't know the engineering application of A* so they just make something up. Knowing that it exists and has certain (detailed) characteristics is probably 95% of the use. Why didn't you use B* (rhetorical question, whats important is you have an answer not what it is) Folks who don't know path algos probably think I'm making up B* but it really exists and was invented just before I started programming and I have a memory for "new" stuff vs old.

Its useful to have a steel beam and know how to apply it to construction. Knowing how its made and the metallurgy and how that impacts the application levels you up. Then there's a whole sea of lower level construction vocational laborers who don't know steel beams exist and they'll just bodge something together with stuff from the junk yard and when it collapses, well, there's no guarantees in life and it was cheap and the academics never know anything anyway so stop complaining, and last but not least the social butterflies who heard the Jones's next door, who are billionaires, built their wall out of recycled plastic so we'll use that to hold up the roof instead of proletarian wood or even this steel beam stuff.

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

No, I mean knowing what algorithms/data-structures are available, what their characteristics are, and how to tweak them. This way you can say stuff like: with those data access patterns, we'll need a B+-tree with links for concurrency, modified to not delete depleted nodes until such-and-such. Or, something like: doing that efficiently requires an optimization that's NP-hard because the problem reduces to graph partitioning, but we can use an approximate solution that should work well-enough in this case.

When programming in high level OO languages, which have ready algorithms and data structures are pretty-much standard, what's your use-case of algorithms?

I've seen entire projects which do not require specific knowledge or application of any algorithm. Even when they do, one can google and find "best algorithm for XYZ", then find a library which has the algorithm implemented and off you go.

I understand the use of algorithms in low level languages and specific domains, but when you need to sort a ruby array you just "array.sort" and a default (IIRC the default in ruby is a version of quick-sort) sorting algorithm is applied, which 9 out of 10 is the faster solution you'll get given the language constrains.

Can you offer an example of specific situation, in any OO-language with reasonable amount of available libraries, where deep knowledge of design and analysis of algorithms is actually required?

"Can you offer an example of specific situation, in any OO-language with reasonable amount of available libraries, where deep knowledge of design and analysis of algorithms is actually required?"

You won't get very many good replies because you are asking the wrong questions. The truth is you don't even need a decent understanding of OO for most day to day dev. You will just produce suboptimal work.

A better question is: "...where reasonable knowledge of design and analysis of algorithms allows you to do a better job?"

And the answer to this more reasonable question is: Every single project I've worked on as an enterprise developer over the last 10+ years. Being able to say "hey actually this problem we are working on can be formulated as a graph problem" can turn a 3 month problem into a 3 day problem.

For example we recently had a rules engine rule dependency issue that turned out to be expressable as graph problem and was then easily solved. If nobody in the team had a good knowledge of algorithms we still could have solved the issue but it just would have taken a lot longer.

And unfortunately until you can phrase the problem in the right way you can't just google "find best algorithm for XYZ".

That is an enlightening answer, thanks.

There are cases where you must adapt a known algorithm to fit your domain. In my job, for example, we work with automatic train dispatch planning [1]. The application is built in Java and one of the main components of the route planning is a custom depth-first search. The search tries to move a train through a series of connected tracks while considering the passage of time and checking for time-dependent constraints such as track blocks, other trains, speed restrictions, etc. This couldn't be done using a standard library implementation.

Also, I believe such knowledge will make you a better programmer, even if you don't have to build everything from scratch. I have seen experienced developers using a list to store unique elements, when the only read operation they would do was to check if an element was in the list. Their solution to speed up the checks was to sort the list every time it was modified and then run a binary search. In this case, better knowledge of algorithm complexity and data structures could lead to a much faster solution, using a set for example.

[1] http://www.academia.edu/6128585/A_Heuristic_Approach_to_Trai...

> Can you offer an example of specific situation, in any OO-language with reasonable amount of available libraries, where deep knowledge of design and analysis of algorithms is actually required?

Interviews :)

Also programming languages and frameworks quickly go out of date, while the fundmentals like algorithms help you out no matter which language you're working in.

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

Exactly this. Hickey, after all, wrote Clojure. So, he's not against learning new languages, but his point is precisely what you state.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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/

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.

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

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

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.

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.

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.

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.

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