Nice article. I think a better topic would be, "How Woz Got Things Done." For a quick read, try Chapter 3 of "Founders at Work", which is well worth the price of the whole book.
This is Jessica Livingston's (of YC) interview of Woz. Specifically I love the way he talked about designing the Apple II. Even though it was hardware, it totally applied to the design and development of software. Perfectly suited to natural optimizers (aren't we all) who want to keep their finger on the pulse of every detail of their project.
This changed the way I treated my own work. No detail is too small and there's always plenty of room in my personal memory for whatever I need to remember. It's made a big difference.
Jessica Livingston posted her interview of Woz on the Founders at Work website. It's one of my favorite in the book because you really get a sense of the pure hacker/engineering genius Woz is. If you do not already own it, consider buying the book through edw519's link - it's an amazing trove. I bought my copy at Powell's Bookstore in Portland.
Thanks for the link, wallflower. I forgot about that. (Buy the book anyway. You just don't know which chapter might change your life.)
This pretty much sums it up for me:
"When you design with very few parts, everything is so clean and orderly you can understand it more deeply in your head, and that causes you to have fewer bugs. You live and sleep with every little detail of the product."
I was going to object to your "finger on the pulse of every detail of their project", because as complexity increases, it eventually becomes overwhelming and too difficult to understand, and you have to construct intermediate representations to handle the complexity - that is, a form of modularity, not for coding it, but just for understanding it.
But then I saw your quote here, about the need to understand it, and the having very few parts makes that possible, by limiting the complexity.
It's because I could never build anything, I just competed with myself to come up with ideas that nobody else would come up with.
Avoided local maxima of the at-that-time-doable, while still making -- completing designs on paper = iterating faster. Iterate more times than competition on paper, never build anything, then when time comes to build, you can supersede competition.
This approach may only work for perfectly logical, deterministic systems, like computers.
This comment is a positive example of what I want to see here on HN. It's not just commenting or adding an association one had. It's developing the material further. He really said something. That's good.
Agreed, that is a great chapter. JL's lead-in also sums it up perfectly - Woz is a hardware guy and it shows through in his thinking. But the notion of always thinking about and refining our models is what still sticks with me.
http://www.amazon.com/Founders-Work-Stories-Startups-Problem...
This is Jessica Livingston's (of YC) interview of Woz. Specifically I love the way he talked about designing the Apple II. Even though it was hardware, it totally applied to the design and development of software. Perfectly suited to natural optimizers (aren't we all) who want to keep their finger on the pulse of every detail of their project.
This changed the way I treated my own work. No detail is too small and there's always plenty of room in my personal memory for whatever I need to remember. It's made a big difference.