Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Super-star programmers

economist.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: Super-star programmers

#81

Post by rwallace »

drharris wrote: post #40
larrys wrote: post #34

Earlier quoted context omitted.

"Forgive potential ignorance here" "Don't get me wrong; I think Joel has a lot of good ideas in general" The saying that comes to mind is perhaps the following. "Those who can, do, those who can't teach." I'm guessing that Joel, by his writings, is a combination of the two and as a result his output is not "rockstar" quality. Another example might be Steve Blank. Who no doubt achieved more fame as a teacher then he e…

Indeed; and my post was never intended to belittle Joel himself. He has provided great value to the industry in both capacities. I'm mainly challenging the notion that if he truly hires only developers he considers to be rockstars, then why doesn't the company have a more compelling domain than bug tracking and PM?

Choosing a good domain is a challenge in itself, quite separate from executing well once the choice is made. Programmers who don't explicitly tackle that challenge will tend to drift into writing stuff they would use themselves, which obviously means going where the low-hanging fruit has been scoured terribly clean; looked at that way, it is a testimony to Fog Creek's execution skills that they can stay in business at New York living costs at all.

Re: Super-star programmers

#82

Post by ilaksh »

Side issue with this article/tenXer press release: the thing about constantly reworking code being a sign of a bad programmer was wrong -- it actually takes more skill to be able to do routine refactoring. Not to say that that is always practical.

Also, taking advantage of existing software makes a huge difference in 'productivity' at least as far as business people can measure. And someone who does that without acknowledging that they are doing it may appear to be a 'superstar' to management.

For example, someone may just consider all of the source code they have ever written, regardless of the circumstances they wrote it in, to be a code library they can copy and paste in whatever company they currently work at. And not even acknowledge that they are reusing code they wrote years ago.

So that sort of dishonesty irritates me, but generally I think taking advantage of existing software is the right thing to do and is the number one factor in what non-technical people would perceive as productivity. There is a huge difference in the time required to build a system using an easily configurable base like WordPress with plugins or components or by integrating open source software or libraries versus building various parts or all of the system from scratch.

That's where you will see orders of magnitude difference in productivity where one person or group is reinventing a bunch of wheels that another group is not. And again there are many different ways of avoiding reinventing wheels, from using Google to basing software on existing open source programs to selecting more practical application programming languages/tools (like ones with things like garbage collection or more straightforward syntax or support for interactively configurable graphical components/plugins), or for example doing test driven development or in general having any type of automated QA rather than relying on a manual QA process entirely.

Re: Super-star programmers

#83

Post by edwinnathaniel »

marshallp wrote: post #72
ajross wrote: post #67

Earlier quoted context omitted.

The answer, of course, is that the "good stuff" is subjective (and almost never aligned with "the biggest value opportunities", ick). Yes, CRUD pays. Being able to make more CRUD in less time (and/or CRUD that is better performing or more maintainable, etc...) is a valuable skill. But it's boring . And more, it's just not impressive in the same way that, say, qemu/kvm is (or Mesa, or Linux, or llvm, etc...) That stuf…

I agree, the classic engineers like to work problems with an easily definable end result (so that business types don't tell them what to write). It's a pity though, there's a huge space of products that are needed but the talent is going into slugging it out in societally useless and relatively low paying niches (such as many of the most talented programmers entering the game industry or social networking or linux ke…

While I agree on your remark about talented programmers in game and linux kernels. I don't necessarily agree with lumping social networking with the two fields aforementioned. I also disagree of your remark about SAP.

I don't necessarily agree with SAP or SAP consultants but there are cases where people would prefer to use SAP to implement some of their core: http://www.infoq.com/presentations/Building-a-Hybrid-Cloud-a.... SAP is a complex, specialized tools that requires specific knowledge on how to tame it.

(I'm not arguing if complexity is good, bad, or anything like that. I'm focusing on what SAP is good at).

Re: Super-star programmers

#84

Post by jdlshore »

barrkel wrote: post #71
zmj wrote: post #66

Earlier quoted context omitted.

> I've seen developers who create, rather than reduce technical debt; who take longer to get familiar with codebases; have a hard time focusing in the presence of distractions; and who seem to have difficulty ramping up solution domain knowledge (i.e. programming / software engineering techniques). And all of these things seem to be down to individual ability or motivation, i.e. something about the person, rather tha…

My worthless opinion is based on about 20 years of newsgroup / forum membership, but the few years I spent working in companies whose software product was a cost centre for its customers was particularly enlightening. We (the guys working on framework / architecture stuff) tried to grow some of the people from the domain-specific side of things into roles on our side of things. It was an uphill struggle; these people…

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not.

Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, business value). As architects, I'll bet that you didn't produce much that the company used. You probably produced designs, frameworks, or other tools for domain programmers to use. But the real software capability was produced by those domain experts you're criticizing, which means that they were the important actors and you were assistants at best. At worst, you could have been an impediment; I've seen "core" teams whose architecture-astronaut frameworks actually have to be subverted in order for the domain teams to get their work done.

I'm playing devil's advocate here, and I'm not entirely serious, but it's with a point: skill in coding isn't important unless it leads to tangible business results. In the short term, in my experience, business savvy outweighs coding skill.

(In the long term, technical debt becomes an overwhelming cost, so programmer skill does matter. But keeping technical debt low is more about maintainability, tests, and boringly understandable design than the kinds of things I see "rock star programmers" emphasize.)

Re: Super-star programmers

#85

Post by gruseom »

jdlshore wrote: post #29

I'm disappointed to see the 10x programmer meme hit a publication like the Economist. There's no scientific evidence of 10x differences in programmer productivity. To quote Laurent Bossavit [1], who's investigated the studies people like McConnell use: "How strong is the support conferred to the 10x claim by the best-reputed list of references, for a reader persistent enough to follow the chain of citations back to p…

It's misleading to single out the 10x meme for the "that's not science" treatment. What beliefs about software development do hold up to the standard of hard (well-designed, controlled, and replicated) experiment? The published literature that I've read is all embarrassingly weak - understandably, given the complexity of what it's trying to study and the minuscule investment in such research.

I haven't read the ebook you're advertising, but a book with an identical pitch, Robert Glass' Facts and Fallacies of Software Engineering, is an example. The difference between his facts and fallacies is that the "facts" tend to have one poorly controlled, never replicated study (usually from 1978) to their name. Better than nothing (maybe), but close to nothing.

My point is that at this stage in history, it's all still folklore. Even you, immediately after playing the science card, followed with mushy folklore of your own ("I've certainly seen...").

Edit: come to think of it, your quotes make it sound like there is empirical evidence for the 10x claim, just that it's old and wasn't replicated. The "old" criticism is weird; it's not at all obvious that the internet invalidated the data. So the critique seems to boil down to: there was a study, but it wasn't bullet-proof and it wasn't properly replicated. What studies of software development isn't that true of?

Re: Super-star programmers

#86

Post by barrkel »

jdlshore wrote: post #84
barrkel wrote: post #71

Earlier quoted context omitted.

My worthless opinion is based on about 20 years of newsgroup / forum membership, but the few years I spent working in companies whose software product was a cost centre for its customers was particularly enlightening. We (the guys working on framework / architecture stuff) tried to grow some of the people from the domain-specific side of things into roles on our side of things. It was an uphill struggle; these people…

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not. Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, b…

Please don't patronize me.

I tried to be specific in what I said; I said that it was OK, and good, that these people existed. I was not making an argument that these people are necessarily less productive; but rather, that there was a qualitative difference in how they approached code that made a difference in what they could accomplish with it.

(Though I think in the medium to long term, they will end up less productive, because of a lack of abstraction and leverage of existing code beyond copy and paste. Probably, we don't disagree that much.)

Re: Super-star programmers

#87

Post by gruseom »

jdlshore wrote: post #84
barrkel wrote: post #71

Earlier quoted context omitted.

My worthless opinion is based on about 20 years of newsgroup / forum membership, but the few years I spent working in companies whose software product was a cost centre for its customers was particularly enlightening. We (the guys working on framework / architecture stuff) tried to grow some of the people from the domain-specific side of things into roles on our side of things. It was an uphill struggle; these people…

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not. Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, b…

You pointed out that productivity can't be measured (though that hasn't stopped you from invoking the concept). Something else that can't be measured? "Business value".

Let alone the "business value" of an individual programmer's commits.

Re: Super-star programmers

#88

Post by gruseom »

The big difference is that the best coders keep more of what they have produced, while the worst constantly have to rework whole sections.

Whoa. Either I'm a worst programmer or this is clueless.

Re: Super-star programmers

#89

Post by jdlshore »

barrkel wrote: post #86
jdlshore wrote: post #84

Earlier quoted context omitted.

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not. Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, b…

Please don't patronize me. I tried to be specific in what I said; I said that it was OK, and good, that these people existed. I was not making an argument that these people are necessarily less productive; but rather, that there was a qualitative difference in how they approached code that made a difference in what they could accomplish with it. (Though I think in the medium to long term, they will end up less produc…

Sorry, I didn't mean to come across as patronizing.

Re: Super-star programmers

#90

Post by jdlshore »

gruseom wrote: post #87
jdlshore wrote: post #84

Earlier quoted context omitted.

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not. Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, b…

You pointed out that productivity can't be measured (though that hasn't stopped you from invoking the concept). Something else that can't be measured? "Business value". Let alone the "business value" of an individual programmer's commits.

Yes, I completely agree. Why do you mention it?
Post reply on HN