111–120 of 133 posts
Earlier quoted context omitted.
A small sample size would just imply greater deviation. There's no reason to assume the programmers outside your sample would be x10 better than those in your sample.
That only works when you can assume your sample is representative of the global population. Since people are not evenly distributed according to their abilities, that assumption will not hold.
Earlier quoted context omitted.
It's worse than that. There is a standard way of assesing programmers productivity and is the worst it could be: kLOC's.
Actually, I've always seen kLOC as a divisor: defects/kLOC, branches/kLOC, etc. Even metrics like functions/kLOC are useful, if you believe in small functions.
Earlier quoted context omitted.
Never meaningfully demonstrated? Have you tried to verify the claim? Go read Peopleware . You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences. There is other research on the topic as well. For in…
Well, I just googled the peopleware citation and it seems the study backing this often repeated claim is from the 1960s and people have plenty of questions about its methodology. I'll easily buy 2X or 3X productivity difference. I'm not buying these casually tossed off claims about 10X or 30X productivity differences without the supporting research discussed in detail front and center. Unacknowledged differences of t…
Only if "programmer productivity" is a primary limiting factor and one can reliably distinguish relative productivity beforehand, both of which strike me as unlikely in most situations.
The other comments are correct; if you aren't willing to take any risk, then you don't deserve the benefits. If you think you are good, put your money where your mouth is :)
Earlier quoted context omitted.
Never meaningfully demonstrated? Have you tried to verify the claim? Go read Peopleware . You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences. There is other research on the topic as well. For in…
I thought the Peopleware claim was that some teams are 10x more productive than other teams. I could easily buy this, because it's very easy to generate more internal communication work than it produces, i.e. be negatively productive. I'm not sure I buy it for individuals, except in the limiting case of someone completely not knowing what they're doing and having no idea where to start. I guess it's also possible wit…
They found an order of 10 productivity difference that showed up under any of a number of possible measures. The also found that the best predictor of a given person's productivity was the productivity of the other person from the same organization. They also identified a number of workplace environment issues that were strongly correlated with productivity.
This overall picture comes with many caveats. Individual productivity differences were still quite significant. They didn't have any way to tell correlation versus causation. (To what extent does a better environment make programmers better, versus correlate with being able to hire and retain them?) The coding assignments were fairly small. So don't read too much into the result.
But given the size of the difference, and that it is one of the few attempts to quantify these issues, it isn't a result to take lightly either.
Earlier quoted context omitted.
I feel best when I'm deleting other's code, and accomplishing the same thing with much less code.
100% agree with this, less code = less maintenance. Very few people truly understand this and why it's important.
It strikes me that I'm seemingly one of the few people at my workplace who can handle abstracted functionality comfortable and make use of third party code/libraries without fear.
tl;dr, I wrote a customer service app for my company in about a week flat.
The author has not ever worked with the truly 10x more productive programmers. Most people do not get the chance to work with these programmers. They do get paid in proportion to their productivity. There are so many horrible programmers that you can be mediocre and be 10x more productive than the guy next to you. Thus you think you're in the 10x crew. But you really aren't. It's not because you're really that good.…
How did he get that good?
Ask Justin?
Maybe someone here who knows him can ask him and post the reply, oeven better, ask him to post. Once of the reasons I enjoyed "Coders At work" was that this question in (at least implicitly) answered by some great programmers.
Earlier quoted context omitted.
i might be proud at first, but then i would be sad to think that others have failed so terribly and with so little guidance or wisdom. i would be saddened by my pitiful pride at a product so limited by its single creator. my proudest moments are when i'm collaborating with such flow that no one knows exactly where each idea came from, and at the end we have a powerful, awesome product that none of us could have built…
You seem to have a very strict requirement for pride; I wasn't aware there was a "pitiful" tier. I feel like life would be pretty depressing if I needed to create something greater than me for the social good that had a purpose just to feel proud of my accomplishment. You can only save the whales once. Anyway, as is the saying, "whatever gets you off". If I've managed to be particularly clever or efficient or solved…
I don't know, I recall an (unnecessarily) hard-coded HTML form in a Django project with extremely poor input validation that somebody I knew wrote. It was a single field, single button form too, I might add.
I refactored it with extreme prejudice.
From the comments: > I’d love to see some metrics on the average life expectancy of a line of code for different programmers. I know that some of my best code was written and has sat there with minimal changes ever since. Now that 's an interesting idea.
I wrote a crappy Python script one afternoon about eight years ago to address a client requirement discovered very close to implementation time. I think it's still running in a production environment -- at least I was told so as of a couple years ago. Was it great code? Nope. It split one file into four based on a particular column's value in a CSV.