Page 165, bullet point 11. Explaining would ruin Kawasaki's story.
Rereading just now, I'm amused that was the only Gassée lesson I remembered.
I like Kawasaki just fine. The followups I'd read didn't really land like Macintosh Way did. But I see now that he kept writing, all of which are rated highly. So I retract my judgement. YMMV.
I didn't notice anything one wouldn't expect, given how different first-hand accounts tend to be. Kawasaki is a marketing guy so his knowledge is weaker than an engineer's in many areas; stronger in a few others.
> Q. How many Macintosh Division employees do you need to change a light bulb?
> A. One. He holds the light bulb up and lets the universe revolve around him.
How well does that scale to modern Apple? Do they retain 140,000+ employees, each one expecting the world to revolve around them?
My favourite thing in this book is Guy’s injunction to build for passengers AND sailors. Make things that are familiar and offer good affordances for people who just pick it up and need to get something done. But also make room for those who want to “go belowdecks” and fool around with the engine.
>>> But also make room for those who want to “go belowdecks” and fool around with the engine.
I admired Kawasaki, but I don't think he had that much clout at Apple. This was the part that Apple never got. Indeed, not too many years later, Apple announced to the business press that they were going to de-emphasize engineering applications and focus on their core strengths in the arts and education.
I remember an article by Kawasaki proclaiming that the Mac was going to be the go-to platform for an emerging field called Embedded Systems. Virtually no embedded systems tooling was ever developed for the Mac. I created Mac hardware by programming it on an MS-DOS machine. I'm grateful that MacOS and MS-DOS let me bypass the Windows 3.1 era.
I am not sure that Windows was any better, but Windows allowed dropping back to MS-DOS mode and creating ugly-but-works tooling. Then Visual Basic came along and made it easy. And today, anything I'm like to do with "the engine" will preferably involve Linux.
Visual Basic doesn't get enough credit for revolutionising development. It isn't sexy, it isn't sitting on a cool language, it had serious limitations.
But wow did a lot of systems get developed in it. Microsoft still haven't got a decent replacement for it and nobody else does either.
That seems like a really awkward fit. HyperCard wasn't a systems programming environment. As far as I can recall, it barely had two data types (strings and numbers), and the interpreter was pretty slow; I can't imagine how you would have used it to write drivers for hardware.
That was indeed my experience. I used HC extensively, and loved it, but put up with its slowness. The speed advantage of the 68040 Mac over my 8088 PC somewhat compensated, but not completely.
HC allowed "code resources" to be added, like plug-ins, which I wrote in Pascal or C. That's how I created drivers. It gave me the performance benefit of course, while allowing me to deal with just the tiny bits of the OS needed to deal with my hardware.
The hardware was either homemade (microcontroller programmed on a MS-DOS machine), or plug-in boards made by National Instruments that luckily came with a C API.
While the term "jailbreaking" was introduced for the iPhpne, the concept was already familiar to me.
An odd irony is that the stuff I've worked on over the years has always involved relatively slow processes, so I've been able to live with the performance tradeoffs of "easy" programming tools.
https://en.wikipedia.org/wiki/Jean-Louis_Gassée
Trying to emulate Gassée, my team and peers, knowing my true nature, thought I had gone insane.
I continued to read his opinions. http://www.mondaynote.com Agree or disagree, I appreciate his heterodoxy, challenging my own assumptions and views.
Guy Kawasaki, not so much.