Here is your 10x programmer:

"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? Would the implementation be correct? How long would their code take to execute?

    % python sudo.py
    All tests pass.
    Solved 50 of 50 easy puzzles (avg 0.01 secs (86 Hz), max 0.03 secs).
    Solved 95 of 95 hard puzzles (avg 0.04 secs (24 Hz), max 0.18 secs).
    Solved 11 of 11 hardest puzzles (avg 0.01 secs (71 Hz), max 0.02 secs).
    Solved 99 of 99 random puzzles (avg 0.01 secs (85 Hz), max 0.02 secs).

Does the average developer know what "constraint propagation" and "search" mean in the above sense, or remember enough about them from their CS class to recognize them as the right tools and how to implement them?

Also, can the average developer implement a spell checker from scratch on a single transcontinental flight?

https://norvig.com/spell-correct.html

So Norvig is always the paradigmatic example of the 10x developer, for me. Having a broad range of CS techniques at your disposal and knowing how and when to deploy them, is almost a super power.

mjw1007

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.)

Tcepsa

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