"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
Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
41–50 of 114 posts
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#42"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
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#43"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
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#44From 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.
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#45Earlier quoted context omitted.
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 th…
> 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 __.
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#46Earlier quoted context omitted.
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.
That would be a square employee, not a T-shaped one.
Or perhaps "well rounded"
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#47Whenever 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…
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.
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#48You 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.
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#49Earlier quoted context omitted.
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 th…
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…
Any links describing the management failures?
Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?
#50Whenever 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…
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.