Raw Kindle notes for Creative Selection: Inside Apple'S Design Process During The Golden Age Of Steve Jobs by Ken Kocienda

This book is about my fifteen years at Apple, my efforts to make great software while I was there, and the stories and observations I want to relate about those times.

we felt, on an instinctive level, that imposing a fixed methodology might snuff out the innovation we were seeking. Therefore, our approach flowed from the work. This happened from the top down, stemming from the unquestioned authority and uncompromising vision of Steve Jobs, and it happened from the ground up, through the daily efforts of designers and programmers you’ve never heard of,

This was part of Steve’s mission for Apple, the most significant strand of Apple’s product development DNA: to meld technology and the liberal arts, to take the latest software and hardware advances, mix them with elements of design and culture, and produce features and products that people found useful and meaningful in their everyday lives.

Steve wasn’t merely interested in paying lip service to this goal. He demanded action, and so the software team produced demos in a steady stream, and whenever there was interesting new work, Steve found the time to attend a demo review so he could see it. His involvement kept the progress and momentum going.

This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry.

Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products.

“When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.”

In the same way, software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself. Like the movie, demos should be specifically choreographed, so it’s clear what must be included and what can be left out. Those things that aren’t the main focus of a demo, but are required to create the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.

Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos.

There’s a conventional view in software engineering that the “prematurity” Knuth mentioned has something to do with a project’s schedule. It’s common for programming teams to make their code work correctly first and then turn to speeding it up only once most of the bugs are fixed. Front-loading feature work and back-loading performance optimizations are typical. Yet, when features take longer to complete than expected and the delivery schedule can’t be shifted, management might have no choice but to drop performance work entirely.

how Steve prepared for these big-splash product announcements. Three weeks or a month before the keynote itself, Steve would start rehearsing with portions of his slide deck in some venue at Apple, often in Town Hall, the auditorium on the Infinite Loop campus. Slowly, day by day, he would build the show by stepping through it as he wanted to present it at the keynote. This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the presentation honed, and he knew it cold.

When Steve spoke to a slide, he went fully into his keynote persona. His tone of voice, his stance, his gestures, everything was exactly as if he were presenting to a packed house. For as long as everything proceeded to his satisfaction, he kept going.

In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it.

I had succeeded in getting my colleagues invested in my insertion point behavior work, not just by asking for their help in a single meeting and saying thanks when it was finished but by demonstrating through my ongoing actions in code changes, demo reviews, and lunchtime chats that their advice had mattered to me. Getting the insertion point to behave correctly wasn’t just my project anymore. It was now our project.

As a programmer and self-professed geek, possessed of a typical geek programmer’s communication skills, it was a revelation to me that both the setting and the solution to my hardest technical problem turned as much on the social side of my job as it did on the software side.

Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”

Steve’s approach could work as well after a failure as he said it could after a success.

Exactly how we collaborated mattered, and for us on the Purple project, it reduced to a basic idea: We showed demos to each other. Every major feature on the iPhone started as a demo, and for a demo to be useful to us, it had to be concrete and specific.

The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.

We rarely had brainstorming sessions.

If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination.

it’s too difficult to talk productively about ideas in the abstract.

empathy as trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs. Empathy is a crucial part of making great products.

It’s difficult to maintain a wider perspective in the midst of making; you have to make sure each individual demo feedback and response cycle eventually adds up to something more.

be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users.

Liberal arts elements and state-of-the-art technology must combine, and the end result can be judged only holistically, by evaluating how the product fits the person.