Live data from Hacker News

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

antirez.com

201–210 of 321 posts

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

#201
Since this article relies on the premise that a "10 X" programmer makes any sense, I'm going to spend time refuting that central point.

If programmer productivity, or software developer/software engineer productivity, is measured as a linear function, then it really does no service to the field. Beyond looking at network effects from the impact developers have on each other, there is no universal measure of productivity. It would be more believable to say that certain developers have twice as many or five times the number of lines of code produced that are defect free, than to say that they achieve a certain level of productivity.

The two reasons that this should be immediately seen as nonsense to anyone in the field is that first of all, computer problems deal with asymptotic complexity. In the asymptotic world, linear functions are outshined by constant, logarithmic, polynomial, and exponential functions. Furthermore, the prevailing wisdom among programmers is that 'less is more'. That's why we talk about minimizing lines of code and trying to avoid the most bugs by leaving the least surface area for them to exist to begin with. Introducing a measure where 'more is better' is sort of at odds with this philosophy and should be viewed skeptically.

Finally, if you look at the great successful innovative products in software, and technology in general, you'll see that they often make use of new inventions. There's no way to compare an inventor in terms of productivity by saying one has 10 times as many patents as the other, or to compare a mathematician by the number of papers or pages published. The important difference is the quality of the invention or discovery. The engineers at AltaVista and Yahoo could have been extremely productive, but without a revelation like Page Rank, they never could have competed with Google back in the early days of search engines. Here, two college students writing a small amount of code outperformed larger companies. This has nothing to do with productivity and everything to do with talent.

This leads me to believe that the "10 X" slogan is a product of marketers, head hunters, and pop psychologists. It has no bearing on the field of computer science and it is a harmful concept because it perpetuates the idea that software developers are replaceable parts rather than unique contributors.

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

#202
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…

> In this thread: mostly people responding to the headline, not the actual content of the article

Agreed - the actual content reads more like "The mythical 10x programmer ... is me". ("many people told me that they believe I’m a very fast programmer... I’ll also use myself as a reference of coding things fast").

I don't mean to disparage Redis or the author, but the point needs to be made that seniority makes it a lot easier to be a "10x" programmer. First off, you have excellent knowledge of business requirements and PMs will listen to you; so it's relatively easy to redefine engineering tasks as you work on them ("killing 5% to get 90%"). Second, you're much less likely to be interrupted by someone who's decided you're working on a low-priority project ("focus"). Third, you probably get to decide what "programmer productivity" even means.

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

#203
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…

Another great thing here: "Design sacrifice: killing 5% to get 90%." I remember a very specific example of this from Perl 6 development circa 2009. perlgeek (I think) and I had been struggling with coding up the sequence operator for a couple of months. Every time we thought we had it, someone would come up with a case that broke the system again. pmichaud (not sure if it's the same pmichaud here on HN) comes up to u…

Perfect is the enemy of good enough. If you never ship a "perfect" product, it has 0 value.

In the end, you provide value or you don't. The hardest thing about any product development is to stop taking things out or worse yet, keep adding things in. The top performers are usually the ones who can weigh these pros and cons almost immediately and force the product in a better direction.

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

#204
post #147

Earlier quoted context omitted.

Notch is known to be quite a bad programmer. Or do you consider him to be 1000x better programmer just because he wrote something which earned billions? In that case he's probably 10x better programmer than Carmack

Minecraft was working and it was already quite big. Quite bad programmer would not achieve working Minecraft. Notch have his limits and made some decisions that did not scaled, but "quite bad programmer" is an overstatement.

You are right, "quite bad programmer" is definitely an overstatement. I should have said average, or maybe a bit above average, but definitely not 10x.

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

#205

Since this article relies on the premise that a "10 X" programmer makes any sense, I'm going to spend time refuting that central point. If programmer productivity, or software developer/software engineer productivity, is measured as a linear function, then it really does no service to the field. Beyond looking at network effects from the impact developers have on each other, there is no universal measure of productiv…

Simple reality check is that you can't hire a 10x programmer.

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

#206

Earlier quoted context omitted.

one million time this. as the resident tech lead I spend more time trying to get people focus on things that matters than actually designing and documenting can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display…

> can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself. If that is something that has to be done a couple of times in a projects whole life, fine. If that is how bugs are solved all the t…

I had the same reaction as you to this post, so thank you for nicely summarizing my thoughts.

I'll just add:

To me, the main distinction is this: you must at the very least figure out the reason for the unwanted behavior. If you don't, then you really have no idea whether your quick little fix covered up something important or not.

It's one thing to investigate, find out the cause, and then say "meh, that's way too expensive/time-consuming to fix, so we'll switch libraries/3rd party code or just remove the requirement for the special scrolling". It's quite another to just say "meh, display: none, look at how productive I am !".

I've had other developers do this in front of me, and it freaks me out to no end. One sat there and told me that if he changes a month calculation to subtract a month, then the total comes out correctly. I asked him why that was and he said "Why does it matter, I'm getting the right result ?"

We all need to remember that we're not being paid to type, we're being paid to think.

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

#207

I started the week as an 1x programmer. The lead on my current project micro manages every point of the code's architecture. I have no freedom to make any calls, even on legacy parts of the code that could be refactored to better fit new requirements. None of the other developers "own" anything so no one can make any calls. Anything takes a week or more to be discussed. Arbitrary non-obvious decisions have been made…

>> I have no freedom to make any calls It took me a long time to realize I don't have to say yes to everything that comes my way. What happens if you say some version of, "I'm not going to do that"? It may or may not be tenable option in your situation. It's like going to a party, the host keeps offering you food, you eat everything offered to you, and then blaming the host when you gain weight.

I actually agree with you. Over time, as I gained more experience as a developer, one of the best things I've learned was to take charge and fix things where I know they were not right, even if not officially requested. Or to identify that a request for one specific fix actually meant something else was broken and that's what should be addressed instead.

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

#208

I started the week as an 1x programmer. The lead on my current project micro manages every point of the code's architecture. I have no freedom to make any calls, even on legacy parts of the code that could be refactored to better fit new requirements. None of the other developers "own" anything so no one can make any calls. Anything takes a week or more to be discussed. Arbitrary non-obvious decisions have been made…

Good observation. In Peopleware: Productive Projects and Teams the authors specifically address this phenomenon. Programmer productivity varies widely between organizations and a lot of it comes down to environment.

Yup. I cannot recommend this book enough.

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

#209

Earlier quoted context omitted.

Alright, my turn for anecdata, since I am having this... "discussion" right now. About 3 years ago, I was hired to write a program to partially automate an incredibly complicated engineering workflow. It was a total rewrite of a crufty program that had been running for about 5 years (written by my boss), but which couldn't keep up any more. It took me MONTHS just to truly understand the process, and about a year and…

So basically your are saying the mythical 10x is not mythical. You are one of them. And you are on HN. And you did live in the real word where people are not 10x. :)

Or maybe saying that there are 0.001x managers out there?

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

#210
post #132

Earlier quoted context omitted.

Notch is known to be quite a bad programmer. Or do you consider him to be 1000x better programmer just because he wrote something which earned billions? In that case he's probably 10x better programmer than Carmack

To me, what's impressive about Notch is the speed at which he can put a decent prototype together. What's also impressive is the experience he's collected. If I work at it, sure, in X years, maybe I can be in the same ballpark as him. But today, if you wanted a game prototype or full game built, Notch would be worth more than 10x me. Just think of the experience he's collected. If we're talking in the abstract, sure,…

I do not think Notch have more programming experience than thousands of other programmers in the industry. He worked on games professionally only for 9 years. Minecraft is not that technologically great, it's just a fun game to play and very famous.
Post reply on HN