Live data from Hacker News

The Myth of the Myth of the 10x Programmer

payne.org

141–150 of 227 posts

Re: The Myth of the Myth of the 10x Programmer

#141
post #137

Earlier quoted context omitted.

Ouch the Bitcoin example is terrible and really detracts from your argument. Currently Bitcoin is sucking value away from real economic output in the form of energy (electricity), financial speculation, money laundering, and cybercrime.

Terrible? I'm sure free software was also considered terrible 15 years ago at Microsoft! In fact, more than terrible- it was perceived as a cancer! Linux was sucking value away from real research in the form of copyleft (lost IP rights), financial speculation (VA Linux IPO, etc), hacking and other forms of cybercrime (don't they show nmap in the Matrix?) But perceptions change. The only thing that doesn't change much…

There is a market for drugs, child porn, assassination too. Or for email spam, hacked accounts, stolen credit cards, money laundering.

If your conception of value to society is as simple as "people pay money for it", maybe you should reconsider what value means outside of a purely monetary lens.

So far, bitcoin is a much costlier way to transact compared to standard methods - both to the end user, and in terms of energy/resource costs of miners vs. a VISA server.

It probably has some value in a scenario where the government is an adversary. But the government can regulate and track Bitcoin just as well as dollars if they wish to, like they already do in the US by requiring BTC exchanges to collect users identity proofs.

The arguments about how bitcoin is the next big thing and we'll all look silly for laughing at it now are basically empty. I'm sure i will feel silly if it takes off somehow, but that tells me nothing about if/why it will take off. I'll look silly for laughing at ghosts or leprechauns if they turn out to be real too, so what?

Re: The Myth of the Myth of the 10x Programmer

#142
post #60

Earlier quoted context omitted.

I'm sure Norvig is very good, but I think the sudoku webpage is presenting a finished program in an idealised way, not recording the process he used to write it, false starts and all. (It seems likely to me that there were some false starts, because eliminate() returns either `values` or False, when both of its callers would be just as happy if it returned True or False.)

He didn't give an implementation time for the sudoku solver, but he did say he completed the spell checker in a single transcontinental flight.

I don't remember how long it took me to do the spell checker challenge:

https://github.com/dlang/dmd/blob/master/src/dmd/root/spelle...

but I'm sure it was much longer than it took Peter. This checker is used by the D compiler to look for a misspelled identifier when a symbol lookup fails. The identifiers in scope form the dictionary.

It works surprisingly well. I added it to the Digital Mars C++ compiler as well.

https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...

Re: The Myth of the Myth of the 10x Programmer

#143

> highly productive developers (10x or otherwise) are problem-solving at a much higher level This is a very important point, but calling these highly productive developers "10x" doesn't really make sense. They are more like "infinity times" compared to the average when it comes to getting a difficult task done, since the average developer would just get stuck and never be able to invent good designs and solve the dif…

Oh no, these other programmers get the task done but they use 10x the amount of code to do it and nobody can figure it out. It mostly works too, except on Tuesday's when it's raining.

> these other programmers get the task done

And it only works on the test cases :-)

Re: The Myth of the Myth of the 10x Programmer

#144

Earlier quoted context omitted.

Environment and control (true ownership) can easily turn 1x into 10x, I'd say. Not saying I could churn out Rollercoaster Tycoon but I bet I'd look, by every metric both reasonable and unreasonable, a hell of a lot more productive working on a game solo with 100% control of all decisions and not having to fret about having something to report in standup every day versus... normal work.

There’s an easy way to find out if that’s true, and it’s to making a similarly successful solo project by yourself!

Productively building and finding the right thing to build to be successful are different things, and one can be good at either while being terrible at the other.

Re: The Myth of the Myth of the 10x Programmer

#145

Earlier quoted context omitted.

Are we talking about a case where a given developer has re-written 100 lines of code, and added 1 line net? Or do you mean that only 1 line was written or re-written? If so, what are people doing, having 7-hour meetings?

No. We had 31 million lines of code and it was so complex that even changing 1 line had massive implications. Definitely the worst code base I've ever worked on. I originally started working there as a contractor because they had single functions which had reached the file size limits for their build system and they didn't know what to do (you know... maybe split this function up into smaller functions... maybe...).…

Very curious to know what you were working on! 31 million lines of code?

Re: The Myth of the Myth of the 10x Programmer

#146

Here is your 10x programmer: https://norvig.com/sudoku.html "In this essay I tackle the problem of solving every Sudoku puzzle. It turns out to be quite easy (about one page of code for the main idea and two pages for embellishments) using two ideas: constraint propagation and search." If you gave this task to an "average" developer, how long would it take for them to implement? How many lines of code would it be? Wo…

Norvig is so another level maybe because of being so literate. I came across a Kakuro (Soduku * crossword) puzzle in a newsprint puzzle booklet, and failing to solve it with a pencil, attempted it in JavaScript.

I am now >10x at solving Kakuro puzzles with access to a command line and the repo (~100ms/10x10).

Re: The Myth of the Myth of the 10x Programmer

#147
Y'know, productivity is kind of overrated. The programmers who I admire aren't the people who could implement a React CMS in record time, but the people who built React. Or Rust, or Haskell, or FFmpeg. I guess one could argue that the programmers are 10x, 100x or even (10^n)x simply because their work has helped other programmers become more effective, thus through the multiplier effect resulting in massive productivity. Or because you need someone who can work at 10x to build something of large impact. But first, that just means that Large Impact => 10x, not that 10x => Large Impact. Second, that's oversimplifying a massive, nuanced impact into a number for no real reason.

Honestly I suspect the idea of 10x developers was created as a way to explain to managers why you need to pay ol' Leslie over there the big bucks. If you claim Leslie works at 10x the speed and only needs 2x the salary, the math works out for a business major. So I guess that's the reason you need the number.

Re: The Myth of the Myth of the 10x Programmer

#148
post #60

Here is your 10x programmer: https://norvig.com/sudoku.html "In this essay I tackle the problem of solving every Sudoku puzzle. It turns out to be quite easy (about one page of code for the main idea and two pages for embellishments) using two ideas: constraint propagation and search." If you gave this task to an "average" developer, how long would it take for them to implement? How many lines of code would it be? Wo…

I'm sure Norvig is very good, but I think the sudoku webpage is presenting a finished program in an idealised way, not recording the process he used to write it, false starts and all. (It seems likely to me that there were some false starts, because eliminate() returns either `values` or False, when both of its callers would be just as happy if it returned True or False.)

Not saying there weren't false starts, but your example of eliminate() is actually a fairly common idiom[0] where, when a function is testing things for "truthiness" or "falsiness", it will return the truthy or falsey value rather than actual True or False. It lets code be more brief because you can do e.g. a check for null and perform assignment of either the value or a default in a single statement, so for example something like this:

  if( maybeNullValue ) {
    myValue = maybeNullValue;
  } else {
    myValue = defaultValue;
  }
can instead be expressed as this:

  myValue = maybeNullValue || defaultValue;
I'm personally a little bit torn about it. On the one hand, now that I'm familiar with it I love how much more concise code can be. On the other, it can have a fairly negative impact on code maintainability: if someone comes along who isn't familiar with that idiom, they might have a bad time trying to figure out what's going on (or worse, they might take offense that all these predicates aren't returning True or False values and rewrite the whole mess--or you could end up with a mix of the two, where some functions follow the idiomatic convention and others return actual boolean values which is arguably the worst)

Also I'm not trying to say that there's not some YAGNI going on here--just that I suspect he did it that way somewhat reflexively, and that in that particular case we probably cannot infer he had originally intended to do something else with those results and then changed his mind later.

[0] at least in the Lisp world, which Norvig has extensive experience with[1]

[1] https://github.com/norvig/paip-lisp

Re: The Myth of the Myth of the 10x Programmer

#149
> I think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist.

For this question to make sense, one should give a better definition of what constitutes the output of a programmer.

In a sense, there are Nx programmers for any arbitrary N because some developers can build things that other can't.

But we can't reduce the work of a software engineer to "programming". Most "programmers" today aren't developing some new hobby systems from scratch (it's the easy part IMHO). They work in the context of a team, they have to deal with legacy code (possibly boring, using technologies they don't like), they write doc, review code, discuss designs and solutions, they give talks to present their work, they train or supervise colleagues, they interact with difficult managers or colleagues and so on...

In that context, I wonder how "star programmers" operate. I wouldn't be surprised if some of them are even under-performers.

Post reply on HN