Hacker News Reader

"And a manager who was a distinguished developer will be much better suited for leading a team of developers -- even if he doesn't program any longer. "

I am not so sure about that. I would say a distinguished manager who was a developer might satisfy your criterion. Social skills, leadership, empathy, and other such traits might be (perhaps even overwhelmingly) more important. That suggests an interesting application of the Peter principle. It seems to me quite possible that promoting the worst developers will lead to (on average) better managers, since we would not be removing the best developers from the development pool (and thus lowering the average competency of the developers), while--assuming people skills are in the large independent from coding skills and come from a normal distribution--the promotee's people skills will likely be better than their coding skills.

Really quite counterintuitive, but to me, a cool idea.

That's a much better point than the one I made.

I have to disagree with that. I've met many people, especially in larger enterprises, who started in development but then became more abstract over time. They weren't bad people, in fact, they were excellent at their job.

This neither confirms nor infirms Paul Graham's thesis. In fact, while PG's assertion was a bit too specific--pointy-haired boss means in general "bad manager", not "programmer turned manager"--I don't think you can deny that people want promotions, and in some places the only way to get promoted is to go into management. PG is of course correct in suggesting that if you want to keep programming, don't accept a promotion to a non-programming role. However, if you find this stunts your career growth, you can either look for a job in a company that will allow you to grow as a programmer, or you can choose to go into management. That many programmers are averse to this doesn't make it a bad choice. You just have to know what you're getting into, and hopefully how to do it well.

Programming to me has never been something that has to be continually pursued in order to stay fluent or able, but merely something that reflects your more basic skills and talents.

Depends on what your goal is. It's perfectly possible to build a good career without keeping up with the bleeding edge of research. You don't have to know what monads are to be well compensated (at least in a Western country). However, neither will you be the next Peter Norvig. If you want to make money, there's many ways to do that. If you want to eventually get a Turing Award... there's fewer ways to do that.

And the traits that make you a good programmer help you in other fields, even management. Yes, large corporations have structures, but we need structure to manage them. And we need managers. And a manager who was a distinguished developer will be much better suited for leading a team of developers -- even if he doesn't program any longer. This is a valid career path, and an interesting one at that.

A manager who is a good programmer will be golden at interview time. Whether he will also be a good lead is unclear. Like iand said, they should get out of the way and enable programmers to work optimally. As an aside, the structure of corporations and how it affects programming is an interesting topic worthy of its own discussion thread.

PG is of course correct in suggesting that if you want to keep programming, don't accept a promotion to a non-programming role.

That's not what he is suggesting though: His statement doesn't include "if you want". He formulates it as an at-all-costs mantra -- stay in programming, for the worst could happen. It can be absolutely horrid advice to a number of people who would excel even more at other IT roles or management roles (see interesting comment from robertk [1]). I myself was long not considering applying to non-development roles, because many of those great opportunities are more and more looked down upon as "not programming". I know some people who've come as far as "Be Mark Zuckerberg or die trying", completely rejecting any business model that isn't two guys coding in a garage. I didn't actually read PG's comment like that -- I have the utmost respect for PG; but this is the background for why I authored such an opposing comment. I don't actually think the RAQs we are discussing were designed to be put under lawyer-like scrutiny ;)

Depends on what your goal is

Completely agree. Casual focus will rarely lead to greatness.

they should get out of the way and enable programmers to work optimally

For someone to get out of the way, he first has to be in the way. You make the general assumption that a manager is bad unless he actively changes his style. I cannot challenge this assumption for I have no data or ideas on where to find some concerning if managers are universally good or bad. And even then employee satisfaction might not be the only metric to measure success. Although I do think that having fun at work is one of the most, if not the most important metric. Many things would be better if everyone enjoyed their work.

[1] http://news.ycombinator.com/item?id=3012765

I know some people who've come as far as "Be Mark Zuckerberg or die trying", completely rejecting any business model that isn't two guys coding in a garage.

I believe the idea behind that perspective is that the aggressive startup model will lead to either failure or fabulous success, whereas a more traditional career will lead to only incremental improvements to your lot in life. Some people are attracted to that.

For someone to get out of the way, he first has to be in the way. You make the general assumption that a manager is bad unless he actively changes his style. I cannot challenge this assumption for I have no data or ideas on where to find some concerning if managers are universally good or bad. And even then employee satisfaction might not be the only metric to measure success. Although I do think that having fun at work is one of the most, if not the most important metric. Many things would be better if everyone enjoyed their work.

No no, that was merely short-hand. To say "they should get out of the way" is to say the manager should create a good working environment for the programmers, while not micro-managing. So yes on the nice office with few distractions, yes on the manager being the sole gateway between the team and the rest of the company, no on the manager dictating what sorting algorithm to use. See for instance this article by Joel Spolsky: http://www.joelonsoftware.com/items/2009/03/09.html

My attitude is when you hire enough programmers that are better than you the best thing to do is get out of their way and focus on building the best environment for them. Call that role management if it helps.

I find this to be a fairly hostile attitude toward management roles and unfortunately it's one that many people share. And it's ruining part of this industry. Not every manager is a 20-year old MBA grad who's out to ruin your business.

What you're describing -- a small team of independent programmers -- accounts for only one part of software engineering projects: programmers are at the center of the efforts, everything else is just overhead.

Many projects are more complex. Development spans multiple long-termed iterations, is time and safety-critical, very expensive and only an integrated part of a larger development process (e.g. automotive, aeronautics, ...). A lot of the man hours on these projects go into tasks that don't directly include programming. These are not necessarily management roles. You have Architects, Test Designers, ... not to count all the roles that have nothing to do with IT at all (if you design a car, what percentage or project members are programmers?).

I personally think that anyone who works in software engineering should have a strong background in programming/development. But active programming is not necessarily part of many roles in many software engineering projects today.

If you don't wish to work in such an environment, no one is forcing you to. If you are, and you are unhappy, explore different options. But don't underestimate the incredible importance that non-programmer roles play in many, many, many projects.

> ... Architects, Test Designers...

The two examples you use, would have to be the best examples of 'waste' in the software industry.

I liken them to having someone on your team who is "The Debugger" where all he does is debug the developers code.

Developers should know how to test their code/app and should know how to design their app, and know how to debug their app. Sure they could 'specialise' one or more of these areas but they should all be able to build software (i.e write code).

Specialization is an adaptation that seems wasteful when it isn't needed but makes a huge increase to efficiency when it is.

Yes, architects and test designers can be a waste. But they can also act to make developer's lives easier.

Good architects can code, but usually act at a higher level - making sure different projects (a) know about each other, and (b) work together. That's important because teams tend to focus on their own success without always taking account of the bigger picture.

> Good architects can code...

Is synonymous with good developers are also good architects.

I think (if I can articulate my thoughts correctly) my meaning was, that there is an obsession with breaking tasks into specific roles that are then the sole responsibility of one person. To the point of inefficiency (given the number of people you have to talk to for a given feature).

I don't agree that specialisation is wasteful (for the project at least). If it isn't needed, the person can still be a 'standard' dev. But if it is needed, they contribute more. (The only waste is to the individual if they specialise in an un-needed skill).

> Is synonymous with good developers are also good architects.

But, most architects are lazy genius. Only way to utilize their skills is not allowing them to code, but letting them designs and coach.

I agree. Architects should just be senior coders - the people whose strategic decisions are usually right (mostly because they know how to test their assumptions). Having a specific person who doesn't do anything else but architect is broken - APIs are for programmers. If you aren't eating your own cooking you have absolutely no right to be claiming you did it well.

Similarly, you could hire a developer on the strength of their testing and get them to champion a stronger infrastructure but like the architect they need to be an active developer to judge the usefulness of their solutions.

I'd say managers (of coders) need to be coders too. They can survive not being if they're great managers, but they're doing it with a handicap of not being able to understand the tools and see the big-picture their team is missing. And the state of the art, not whatever they used in school twenty years ago.

But, conversely I think I was a lousy employee early on (in terms of value created for the core product / hours spent) because I wasn't thinking of the business aspects of the company. So while I think everyone needs active programming skills to participate meaningfully in programming, I also think those programmers need to be aware of the business they're in, the entire industry trends, and that of the problem domain the work is in. If you design/make/sell a farming GPS, for instance, you'd better have farming experience.

Perhaps the loosely overlapping networks of broadly-skilled individuals managing their own (but with input from an on the rest of the company) doesn't scale well, but I've yet to see a better idea.

I didn't intend it to be a hostile comment/attitude. It's just pragmatic. I can code, I can design and I can architect. That's great when it's me and a few others, but as a business scales up I should be able to recognise when there are better coders than me. If I refuse to get out of the way then I'm just a hindrance. Therefore I should adapt to the new business size and use my experience etc to help those better coders.

> Almost anyone can learn playing the guitar, but it takes a special talent to excel at it.

Curious about this notion of 'special talent' - So some people are just born to be better guitar players? Are you saying that something in the brain is pre-wired to be a better guitar player?

I'd say for a claim like that, you need a citation (preferably multiple).

In my opinion: You can excel at anything you like, you just have to work at it (it helps if you do it when you're really young, as your brain has higher plasticity). Get rid of this "special talent" notion.

I partially agree with the GP, except I would say it takes a special talent to excel at it in a given amount of time. A "special talent" in this case would be a predisposition to learning how to play a guitar.

>Are you saying that something in the brain is pre-wired to be a better guitar player?

Yes, whether due to nature or nurture, I would say certain people will be faster at learning how to play the guitar, and thus, be a better guitar player given an equal amount of exposure. Of course, you could always put more time into it, but there is only a finite amount of time available to a given individual.

No citations, but I believe this agrees with the general consensus. In fact, I would be greatly interested if anyone could provide studies showing the contrary.

What about Salman Khan's TED talk, where he shows that it is a frequent occurrence that kids stumble on a math concept, but then rapidly catch up or exceed their peers. If learning as a general phenomenon occurs in plateaus, but turns out linearly the same in the long run for most everybody (like a graph of the prime counting function seems choppy up close but a line out far), perhaps it is the case we intuitively think some people have a talent, because they didn't experience any early plateaus, but experience some later instead, when they aren't under as careful scrutiny. In other words, it might be a statistical phenomenon of the learning progression (assuming the plateaus are uniformly randomly distributed). Having thought a lot about this issue, I think it is closer to the truth.

In any case, I second the request for more studies.

What you're talking about is known generically as the General Learning, which is an aptitude in itself. Some people learn better than others. It also depends on what you learn.

Nurture: At various ages, the ability to learn changes (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....). It might well be true that there is a lot of optimization to be done in the way we teach -- something that Salman Khan illustrates well with his new teaching methodologies. That doesn't necessarily mean however that at all stages, ages, circumstances, people will be equally able to learn something.

Nature: Some people have an innate aptitude; I won't look for papers, as I find this to be truly obvious.

I wasn't actually arguing that people are born to be better at anything, although I suppose this is the general consensus.

Talent = "a special natural ability or aptitude" (http://dictionary.reference.com/browse/Talent)

Aptitude = "capability; ability; innate or acquired capacity for something" (http://dictionary.reference.com/browse/aptitude)

Like tentonwire argued, whether it's nature or nurture, people are better at some things than others.

From what I understand, you are effectively making the argument that anyone can excel at anything. In this case, I also concur with tentonwire, that the burden might be on you to prove that hypothesis.