
Legendary Productivity and the Fear of Modern Programming - wyclif
http://techcrunch.com/2015/09/11/legendary-productivity-and-the-fear-of-modern-programming/
======
xiaoma
> _While no one programming legend can possibly accomplish any big feat solo,
> there are programmers worthy of fame for their supreme productivity._

Actually at least one programming legend did according to many:

\------

Woz designed all the hardware _and_ all the circuit boards _and_ all the
software that went into the Apple II, while the other Steve spewed marketing
talk at potential investors and customers on the phone. Every piece and bit
and byte of that computer was done by Woz, and not one bug has ever been
found, “not one bug in the hardware, not one bug in the software.”[15] The
circuit design of the Apple II is widely considered to be astonishingly
beautiful, as close to perfection as one can get in engineering. Woz did both
hardware and software. Woz created a programming language in machine code. Woz
is _hardcore_.

- _Geek Sublime: The Beauty of Code, the Code of Beauty_

~~~
akavel
Also, how about:

\- Donald Knuth (TeX, METAFONT); even more surprising here given that he's
mentioned in the article a few times on other accounts;
[https://en.wikipedia.org/wiki/Donald_Knuth](https://en.wikipedia.org/wiki/Donald_Knuth)

\- Fabrice Bellard (QEMU, FFmpeg, & other)
[https://en.wikipedia.org/wiki/Fabrice_Bellard](https://en.wikipedia.org/wiki/Fabrice_Bellard)

~~~
kragen
Knuth had help from his graduate students. Some of them did their
dissertations on work they did in TeX and I think METAFONT too.

~~~
akavel
hmm; "[citation needed]", although I've already found something via Wikipedia:

[https://gcc.gnu.org/ml/java/1999-q2/msg00419.html](https://gcc.gnu.org/ml/java/1999-q2/msg00419.html)

 _" [...] Knuth definitely wrote most of the code himself, at least for the
Metafont re-write, for which I have pesonal knowledge. However, some of his
students (such as Michael Plass and John Hobby) did work on the algorithms
used in TeX and Metafont. He also did have a programmer (David something)
working for him at one point, but not as I recall at the time of the Metafont
re-write."_

That said, some solid source on the earliest phases, as well as on particulars
of the specific "algorithms", would be nice to learn.

------
gaius
_Peter Norvig may be immediately associated with JSchema_

Umm, what? One of many weird things in this article. Generally non-programmers
do not write well about programming.

~~~
abecedarius
Means JScheme, which, yes, isn't one of his better-known works. The whole
article is like that.

------
nickpsecurity
Seems mostly right on. I don't think you need to know one language, though.
You just need to understand whatever tools you use to model the problem and
solution. One can get pretty far by ignoring as much of what's out there as
possible, using subsets, and using a consistent style across tools. Let's you
get more in your head without mastery of every detail. I still use a
Cleanroom-like approach and FSM's with my programs looking similar across
toolchains.

re nobody accomplishing any big feat solo

Seems to be a few, potential counterexamples on this list:

[https://en.wikipedia.org/wiki/List_of_programmers](https://en.wikipedia.org/wiki/List_of_programmers)

Bram Cohen's Bittorrent jumps out as having traits of one programmer, a solid
technical contribution, and impact. Probably more but must assess if they had
help. List is misleading on that part.

~~~
dunkelheit
Bram has written a post (link:
[http://bramcohen.livejournal.com/4563.html](http://bramcohen.livejournal.com/4563.html))
about what in his view separates great programmers from others (spoiler: it is
the ability to come up with good architectural decisions). But then, his
codeville project went nowhere so take it with the grain of salt ;)

~~~
nickpsecurity
That was an interesting write-up. I disagree with how he thinks people will
come up with good architectural decisions. That blind trial-and-error is how
most programming happens and most of it is anything but good architecture.
It's a nice learning and exploratory process, though.

For learning architecture, I'd recommend people do what I did: look up all
kinds of present and past solutions to problems that worked well to see how
they did it. See what they worked with, constraints, goals, specifics, and
what resulted. Most discoveries are re-hashes of old ones and there's plenty
of good stuff to draw on in many subfields. Some are truly novel but studying
old stuff for new applications will get you pretty far. Out of the box
thinking for the rest.

------
marktangotango
This article is bizarre: "The greatest programming minds are capable of using
software to multiply massive integers that are bigger than the universe." What
does this even mean?

~~~
hugh4
We could generously assume some words are missing and it means "numbers larger
than the number of particles in the universe".

But there's only 10^80 particles in the universe, so that's not very
impressive. You could do it, rather tediously, with a pen and paper.

------
jacques_chester
Whether software is the most complex systems humans have built very much
depends on what you consider to be a system.

And whether you agree that software is the most complex thing humans have
built also seems to correlate, to a remarkable degree, with whether you build
software for a living.

~~~
Turing_Machine
"Whether software is the most complex systems humans have built very much
depends on what you consider to be a system."

Indeed. To take just one example, the world economy is a system created
entirely by human beings, yet seems to me to be much more complex than any
piece of software. People try to model pieces of the economy with software,
with varying degrees of success, but I don't think it's feasible (it may be
impossible) to model the economy as a whole.

~~~
danmaz74
I don't know if software systems are the most complex systems we built, but
you can't compare it to the world economy, which is an emergent property that
nobody has "built".

~~~
Turing_Machine
It's composed of the individual actions of human beings, so yes, it was built.

It certainly isn't a natural phenomenon.

"Emergence" doesn't have any bearing on it. The properties of music and art
are emergent, too. Doesn't make them not constructed by humans.

~~~
danmaz74
> It certainly isn't a natural phenomenon.

Now, this is interesting. You mean that we humans aren't a natural phenomenon?
:D

~~~
Turing_Machine
nat·u·ral ˈnaCH(ə)rəl/ adjective 1\. existing in or caused by nature; not made
or caused by humankind.

Humans are natural. Human artifacts are not.

~~~
techbio
Mom's tomato garden?

~~~
boomlinde
Not that I necessarily agree with the distinction made in the definition
above, but assuming it's true, wouldn't the garden be an artifact? The soil
and the tomatoes surely not, but the garden in layout and concept would be a
human built thing.

------
taeric
The point about internalizing what you are doing is sadly overshadowed here. I
know folks love Bret Victor's talks about externalizing this visualization to
teach people and make things easier to show to others. What that misses, is
there is a great benefit to internalizing this such that you don't _have_ to
find a way to visualize it.

The killer section for me is Thompson's quote regarding how hard it is to
follow programs that are built with layer upon layer. Just a single paragraph
really sums this up.

------
wslh
One thing is to start SOLO when the field or subfield is new and a very
different thing when it is mature. Game programming? individuals or small
teams developing great games for the Atari 2600, Sinclair X, and Commodore Y
but now that's almost impossible. You can follow the indy programming route
but requires to ignore some dimension of the finished product.

------
15155
> It’s simple: If code is too dependent on one person, your business is
> susceptible to dire wounds.

Ah, reduce your product to what the lowest common denominator is capable of
producing, to avoid too much "dependence" on them.

AKA: Make sure your engineering team is entirely swappable, like batteries.
Plug them in, burn them out, no problem.

------
graycat
We can't forget:

"adding programmers to a late project makes it later"

Right, Brooks.

And his solution was the _chief programmer team_.

------
randomsearch
two books I would recommend anyone wanting to become a great programmer to
read:

\- the pragmatic programmer

\- clean code

I'm not sure I believe articles like this, but myself and colleagues have
found these books to greatly improve our coding.

