Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

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.

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.

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.

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.

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.