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.
"...I really urge you not to think you can start a whole company and business with just ideas on paper, because you'll end up owning so few of those ideas. You have to create a working model, something that you can show people and demonstrate that it works, and then you can start building a future for it."
You should read his rationale for using Eudora. Here's a snippet:
Any feature in the menu list, any action there, can be added as a button. I changed it so I have a vertical menu bar, so I can have tons and tons of pre-made buttons saved right where I want them up top, and I learn where those place are. You can script actions to the buttons, too, so I can quickly copy messages to my assistants.
I'd like to see them do a "How RMS gets things done" article. What do you use for email? Emacs. What browser do you use? I don't use a browser. Etc. Etc. Etc.
What I'm most impressed with isn't Woz's obvious technical birlliance, it's how he's just a decent human being. He presented his ideas to HP before leaving, rather than letting lawyers sort it out if need be. He sold stock to employees, rather than to a single wealthy investor. How he just wanted to be known for designing something great rather than just grab money. Every public appearance I've seen with him has confirmed that.
It's all just a degree of abstraction. Someone could say you were "programming" if you were using Automator. Explain more specifically to what level you think people should be programming their computers, because I think it will never happen to the level of writing actual high-level language source code, ala Python. People like looking at and clicking on/touching/interacting with pretty pictures/icons. I guess you might mean something that allows people to piece together actions (functions) to describe some goal they'd like. For example, "Purchase with CREDIT CARD -> from GROCERY STORE -> LAST WEEK'S GROCERY LIST -> deliver to HOME ADDRESS -> after TUESDAY CLASS TIME". Isn't Ubiquity trying to act as something like natural language processing in Firefox?
I disagree in that when learning to program in BASIC on the Apple II, you are a mere PEEK and POKE away from the hardware; go any lower than that and you are no longer talking about abstraction (as we refer to it) but hard realities of electrical engineering. One floor down and you are the common denominator that defines everything we refer to as a "computer" (in the modern vernacular) and mastering this will provide you with insight which spans across all contemporary systems and many in the perceivable future.
Setting the "ground floor" of programming at anything above this level narrows your scope and greatly increases the potential of your knowledge becoming obsolete.
Someday this will change, and the basis of future systems will not be rooted in the hardware models of today, and it will be great because then we'll all have something new to learn.
It's all just a degree of abstraction. Someone could say you were "programming" if you were using Automator. Explain more specifically to what level you think people should be programming their computers, because I think it will never happen to the level of writing actual high-level language source code, ala Python. People like looking at and clicking on/touching/interacting with pretty pictures/icons.
I learned coding because I read a book. The book was a novel about a young hacker who wanted to own his own "pineaplle" computer but was to poor to afford one. I had nothing to do with computers at that time, literature-geek, writing not math. But than this bok showed me how computing works and that I could do my own VR. This was a strong motivation for me, strong enough for me to learn small-c on a cp/m machine.
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.