Live data from Hacker News

Qualities that I believe make the most difference in programmers’ productivity

antirez.com

71–80 of 321 posts

Re: Qualities that I believe make the most difference in programmers’ productivity

#71
post #22

>The programming community is extremely polarized about the existence or not of such a beast If we go meta and generalize the disagreement, the skepticism about "10X" is the same as the rejection of other labels such as "ninja" and "rockstar".[1] For some, the idea of categorizing a subset of programmers with a grandiose label is psychologically distasteful. It doesn't matter what the label is; any label that attempt…

Not many people would take issue with the statement that Shakespeare was 10x better / more effective than the average playwright. If you consider that both are creative processes there seems no reason to reject the idea that a programmer could be 10x more effective than his peers.

The comparison between writing a play or a program starts to break down if the problem space is narrow, as the article also mentions, so a lot of what people end up arguing about is what programming actually is.

Re: Qualities that I believe make the most difference in programmers’ productivity

#72

This bit articulates what I consider to be the main advantage of experience in programmers: > Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one. It…

Absolutely. This is why it's so important to have input from engineering during the product design stage of any new product or feature: good engineers can help spot when a minor change to the requirements could have a major positive effect on the overall system complexity and time to delivery.

Re: Qualities that I believe make the most difference in programmers’ productivity

#73
post #13

Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it: * For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else). * Software is a team effort. Im…

I used to be a tech lead/PM on teams where we came in as an outsider and delivered code where the organization itself couldn't.

Part of that was having great programmers with great habits, sure. But a big part of that was something like "Not letting your broken organization and practices break our delivery speed"

Bad org structures and practices pull developers and teams into poorer and poorer practices, like an accretion stream getting sucked into a black hole. The org itself can take a .1 dev and turn them into a .01 dev.

Re: Qualities that I believe make the most difference in programmers’ productivity

#74
post #63

I don't understand how anyone can say 10x programmers don't exist. There are programmers who DRAIN value from projects and companies. The most insidious I've dealt with are people who assure everyone their part is going to be done on time, but come the deadline, they have nothing. I am today, a 10x better programmer than I was where I started. In terms of quality, complexity, efficiency, readability, maintainability,…

just not making anything isn't the most insidious - the most insidious find ways to slow down whatever you're making as well as not doing anything themselves.

Re: Qualities that I believe make the most difference in programmers’ productivity

#76

This bit articulates what I consider to be the main advantage of experience in programmers: > Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one. It…

Exactly... working as a consultant in the past I saw there was this communication/personality problem. It gets both the experience to recognize there is a problem with one of the spec and the authority to say it and get a different proposal accepted. If the environment is hostile about proposals coming from programmers, a lot of bad things happen.

Re: Qualities that I believe make the most difference in programmers’ productivity

#77
post #13

Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it: * For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else). * Software is a team effort. Im…

Come on, Antirez is a x10 programmer, he coded one of the most brillant software of the last decade. It's so well done I use it as an example in my trainings, making people compile it to stop being afraid of building from source because I know it never fails and it's so damn simple. And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you…

While I agree with almost everything you wrote - I found that original post awesome and there are many great lessons in it - I don't see what this has to do with my comment.

Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...

Re: Qualities that I believe make the most difference in programmers’ productivity

#78
post #40

Earlier quoted context omitted.

A -0.01x programmer would flip the working state of the codebase everytime he commits ;)

Here it's meant as a ratio of personal productivity, not a multiplier on the state of the codebase.

Yes. If you add two -2x programmers to the project, you decrease its productivity by 4 programmers. You don't multiply it by 4.

I started my professional career in a project where the previous developer had been given incentives per lines of code produced. Her approach was to do

  display_buffer[0] = 'H';
  display_buffer[1] = 'e';
  display_buffer[2] = 'l';
  display_buffer[3] = 'l';
  display_buffer[4] = 'o';
instead of having a print function and saying

  print('Hello');
This was on a 8-bit microcontroller with 64k program memory. And, surprise surprise, I, a humble CS student, was given a task to "implement software to control our new HW with memory paging mechanism, so that the software, which is larger than 64k, can be put on a 128k EEPROM, and then add a network management interface".

Well, having taken a look at the code we didn't have to do any paging; soon after deploying a print function we could put everything on one 64k page and the other 64k of program memory was just sitting empty.

Re: Qualities that I believe make the most difference in programmers’ productivity

#79
post #48

In this thread: mostly people responding to the headline, not the actual content of the article. There's some fantastic stuff in here about how great design is the key to increased productivity. For example: "It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages. A project that is executed in order…

Exactly. All the arguments that have the word "productivity" are probably off. It's not about "productivity" as in "which programmer produces more code" or even "more programs" or whatever. It's about the person being able to recognize what matters, on one side, versus those that can even make such decisions to finally cause the doom of the project. I have such experiences, and some huge failures can really be caused by the disconnection on the lower levels (programmers) and the managers who can't recognize what's going on (accepting the wrong arguments of these doom-causing programmers). Some of stories like that are also in the book "In Search Of Stupidity"

http://www.insearchofstupidity.com/

The author calls them "marketing disasters" but I recognized several purely technical disastrous decisions there, like "let's rewrite the product from scratch, but ignore the way the users use the product (to print) and ignore the printer drivers existing in the earlier version." Then wonder why nobody wants to use the new version, and the competition takes over. These things are eternal in tech.

On another side, if we claim that as soon somebody is making any design decisions is not "just a programmer" then sure, all the programmers are "good enough."

The way I understand it, antirez probably considers himself a programmer and for what he produced he really made most of the design decisions himself?

But if you factor in the design decisions: they can make the product great or kill it. What's the difference then between the best and the worst? Much more than 10 times, if we compare the survival vs. the death, it's even infinite.

Re: Qualities that I believe make the most difference in programmers’ productivity

#80
post #66
post #15

Earlier quoted context omitted.

Haha :-) Please point me to the worst ones and I'll fix. Re-reading again btw.

Nah, just remind them you made a design decision to focus on the meaning, and not the grammar, which let you write the post 10x faster ;)

That's a valid point! A quality of my poor english is that I write it at the same speed I write Italian. This blog post took me 10-20 minutes at max to write, even if the concepts I elaborated for much longer time when thinking/talking about these issues with people.
Post reply on HN