Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

by Ken Kocienda

From 2001 to 2017 Ken Kocienda was a software engineer and designer at Apple. In Creative Selection he gives his personal account of what it was like to work at Apple during the last few years of the Steve Jobs era—from demo-ing products for Steve Jobs, to helping create software for products like the iPhone, the iPad, and WebKit, the most popular software in the world for browsing the web. Throughout, Kocienda shares the principles he and his colleagues used at Apple to do their best, most innovative work and to make great products, including the demo-driven iterative creative selection method used for turning ideas into finished work. The book is an inside look at how a group of software engineers and designers made world-changing products the Apple way.

Creative Selection is about making great products and Ken’s experiences trying to make them. During his fifteen years at Apple, the effort to make great products was all he thought about and cared about. Software was his piece in the product puzzle. He developed user interface concepts and prototypes which made the most of new hardware features, he wrote heaps of computer code to make it all go, and he worked with other programmers and designers to create bug-free software which shipped on schedule, as they all tried to make products which would surprise and delight the people who were eagerly waiting the unveiling of the next great thing. Apple was the perfect company for Ken, and his timing was great. He got in on the ground floor of some cool projects, including: the iPhone, the iPad, the Safari web browser, and more.

The book is a collection of Ken’s stories and thoughts about how they made these products—the light bulbs clicking on over people’s heads, the long struggles to solve seemingly insoluble problems, the pleas for help, the brilliant people, the moments of confusion, the demo reviews, the methodical work, the never-ending demands to do better, and finally, the success of making products which people everywhere use every day to express themselves through words and pictures, communicate with their loved ones, and interact with the world.

Genres: Design, Business, Nonfiction, Technology, Apple, Leadership, Management

248 pages, Kindle Edition

First published September 4, 2018

Reviews

[John · Rating 4 out of 5]

This is the real deal, written by an insider (I was also there during that time). This book accurately describes Apple's software engineering during the second Steve Jobs era. (For hardware engineering, read Adam Lashinsky's Inside Apple.)

The vivid descriptions in the book are better than the analyses. I would stress that the principles and practices described by the author were completely unwritten and unnamed, as the author says. So if you're trying to be like Apple by reading a book, you're doing it wrong. If you want to be like Apple, ditch the business books and startup blogs (do you think Steve Jobs read those things?), and really focus on the product. There's nothing in the book about MVP, Agile, Scrum, A/B testing, TDD, etc. Apple really didn't work like that. The key is what the author calls "creative selection" (demoing/dogfooding/iterating/converging the product), with tight loops of communication (with minimal teams, enforced by secrecy).

One thing that occurred to me is that the examples given (and generally in Apple's history) are ones where the product definitions were relatively well-formed and concrete up-front, leaving plenty of room for technical innovation (but little room for exploration and business validation). Before getting to that concrete vision, the Apple way isn't applicable.

[Hots Hartley · Rating 3 out of 5]

Overall, not bad. I loved the Intersections chapter, in which Ken Kocienda discusses design principles in detail. The keyboard constellation-matching algorithm, iteration from prototype to prototype, and SpringBoard touch size all provided detailed insight into Apple's design thinking and what made Purple an exciting adventure in problem-solving.

I didn't appreciate the dumbing down of programming principles. Too often, Ken Kocienda oversimplifies otherwise technically exciting concepts. For example, the "black slab encounter" reduced graphical artifacts from loading Yahoo to a single, irrelevant moniker; I wanted to know, more specifically, why the rectangle was black, and what parts of Yahoo led to the browser window showing that specific artifact. The "giggly demo" -- all demos could be called "giggly" because programmers enjoy seeing their code work for the first time -- the "candy bar" conversation, the metaphor for code as recipe books, ... There are too many situations through the book where I felt I was being talked down to, like the author didn't believe in the reader's (my) ability or curiosity to parse programming problems in my head, that I didn't have the intellectual capacity or interest in solving the problem along with Ken. The attitude abstracted away a lot of the most interesting parts of problem-solving into real-life metaphors I had no interest in buying. It's perfectly okay to name particular situations for easier reference later, but don't use terms that have little to nothing to do with the technical problem underlying the situation: after a while, I completely forgot what "giggly demo" referred to, and it would have been more appropriately titled "first successful autocompletion demo" and the black slab encounter could have been "Yahoo page load artifact." Sometimes, by dumbing down a term too much, you lose the reader along with the details.

Having said that, Ken does a good job picking out memorable personalities and idiosyncracies in the characters that appear in the book. Richard Williamson's hand drill motion, Scott Forstall's long spidery fingers "genetically" predisposed to touch screen precision tapping, Imran Chaudhri's smooth demeanor, and Kim Vorrath's hairstyles all painted a vivid picture in my mind of these people and made their scenes enjoyable to read. If there was one storytelling success in this book, it would be this: painting every participant in the journey as a human being, with strengths, weaknesses, and strong motivations. Each individual -- except maybe the candy bar guy whose significance I still don't understand -- stood out as someone meaningful to Ken and Purple's journey. Good job!

[Satyajeet]

This is an excerpt from the book, that I found on the interwebs.
The full title will be released on September '18.

"Within a week of picking my keyboard, Scott scheduled a private demo with Phil Schiller, Apple’s top marketing executive, the man who, after Steve, was most responsible for communicating to prospective customers exactly why we thought our products were great and why they should go out and buy one.

Scott didn’t clue me in on the politics in play between him and Phil or why he had scheduled the demo. I imagined that Scott was eager to show off the results of the keyboard derby, which must have been a topic for discussion up at the executive level. In any case, my job was to prepare my demo so it worked as it did for the demo derby, so that’s what I did.

When Scott brought Phil to the conference room, I was waiting. This was the first time I ever met Phil, and I was nervous. I set everything up as I had a few days earlier, but I had already made a couple of changes to the keyboard user interface. Scott introduced me. Phil greeted me with a quick courtesy that showed he wanted to get right down to business.

He picked up the Wallaby and tapped a few times. I didn’t see what he typed. Phil asked me why I’d put more than one letter on every key. He was pleasant but direct. He seemed to think that my keyboard looked odd, that it required an explanation.

I tried to give him one. I told him about our decisions to make big keys that were easy to target and couple them with suggestions from a dictionary.

Phil wasn’t satisfied, and he said so. Then that was it. I was surprised we were done so fast. The demo was over in about two minutes.

It was sobering to hear Phil’s point of view. Obviously, he had none of the emotional connection I had to my keyboard. While I had been working hard on it, for Phil it was brand new, and he was indifferent to it. He expected the software to win him over, and apparently, it didn’t. This mattered for two reasons. First, as I said, Phil would be playing a pivotal role in pitching the Purple phone to people in the outside world once we were done developing it. Second, and perhaps more important, his reaction was just like a prospective customer evaluating a product from scratch. My keyboard would be a part of the overall impression, and Phil was confused rather than convinced.

A couple days later, Scott and I repeated the private demo performance for Tony Fadell, the executive in charge of the iPod division. I had never met Tony before either, but I didn’t have to know him to see how preoccupied he was. When he walked over to the conference room table with my demo on it, he barely glanced at my keyboard. He didn’t ask any questions. Then he tried my software, but he couldn’t have typed more than a word or two. The demo with him was even shorter than the one for Phil, and within a minute, he and Scott went off together for a private meeting, leaving me alone in the conference room to clean up the Mac, the Wallaby, and the wires connecting them.

Two demos with less-than-positive responses. Add that to my fellow derby entrants’ lack of excitement, and I could tell we didn’t yet have exactly the right solution. I didn’t get to demo the software for Steve. Maybe Scott concluded that we weren’t ready for the big time, but he never said anything specific to me about these executive demos, good or bad.

I didn’t feel like I had let Scott down. My code was the same as it was on derby day. There were no bad bugs during these executive demos. As I tried to interpret the feedback and decide what to do next, I thought back to the Black Slab Encounter with Safari. That breakthrough didn’t represent an end; it signaled a beginning. As exciting as it was to see our web browser render the first sliver of a web page, we realized what the milestone meant. I began to look at my derby-winning design in a similar way, as if it were a successful audition rather than a sold-out performance.



I started to think about improvements, and to help me keep my keyboard goal literally in sight as I sat in my office, I measured and cut out a small piece of paper, about 2 inches wide by 1.3 inches tall, a little smaller than half the size of a credit card turned on end. I pinned up this little slip of paper on the bulletin board next to my desk. I looked at it often. This was all the screen real estate I had available for my keyboard.

This was my touchscreen typing canvas. People would have to tap-tap-tap in that tiny rectangle to type, and I had to figure out how to make that happen. As I pondered that small shape and took stock of my software, I got accustomed to the idea that I might need to rethink some of the decisions that led to the derby-winning design, perhaps all of them."

[Chris Ryan · Rating 4 out of 5]

I'd been hoping for a book like this about Apple. I've been working in product design for almost thirty years, and this just confirms that writing about the "user experience" field has unfortunately been dominated by agency types: Kocienda's experience reflects what it's actually like to design a product. No "empathy maps" or "user journeys," just a lot of hard work trying to define and solve problems. Recommended.

[Bjoern Rochel · Rating 4 out of 5]

Ken was part of the team that created Safari and WebKit, as well as the creator of the iOS keyboard on iPhone and later the iPad. Funny enough, I use his creation to write his review.

This book is a an inside account of a software engineer during the golden age at Apple. It follows Ken though his day to day work at apple during his various projects and manages to give a pretty deep view into how Apple operated under Jobs.

From an engineering perspective a lot of what he describe sounds “just” like a very, very mature software organization to me.

- highly demo driven iterative development
- cross team dog fooding
- highly adaptive engineers
- swarming around hard problems
- feedback culture
- direct accountability for the outcome
- small teams, no open floor offices
- engineering deeply integrated with top level management
-hierarchy but with an emphasis on fast decision making

But you have to take into account that the book starts around 2000, so almost 20 years ago. That’s by todays internet standards the Stone Age. Most companies were thinking completely different about software at that time e.g. waterfall, incremental development, separated people for requirements engineering, software development, quality assurance and so on.

It also fuels a sentiment of mine: the really good companies don’t waste time debating Agile, Lean, TDD, DevOps and friends. They simply do it, because it’s part of their DNA.

The little sad note was in the epilogue, when he talked about how this culture ultimately depended on Jobs and fell apart when he died. Again fuels a sentiment of mine: The higher in the hierarchy a person is, the bigger the potential influence on culture (positive and negative).

I removed one star because some of the interludes felt a bit out of tune with the rest. I found them more distracting than emphasizing.

[Manas Saloi · Rating 5 out of 5]

A bit counterintuitive to how most companies work. At Apple the focus is on to build great demos and keep polishing them till you get to the end result. Instead of multiple A/B testing, take the best call for the user and run with it. I loved the inside stories and this is a book I will keep going back to in the future if I need inspiration. :)

[Michael Scott · Rating 2 out of 5]

To-do full review:

i The technical story of and by one of the many coders working at Apple in the glory days of the early 2000s, the days of iPhone changing the computer industry and, likely, the way we perceive technology. A book missing the bigger picture, and thus of interest to those directly involved and to the occasional geek passionate about Apple trivia. 

i Let's not forget Apple developed the iPhone in the kind of a atmosphere that led to the late 1990s book The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. A crisis of usability was looming, and Apple bet and won on choosing the right side in this crisis. 

+/- Ken Kocienda is a former member of the Apple teams involved in developing the Safari web browser (bad), the iPhone keyboard (standard setting at its time), and various small tasks in the iPad and related line of hardware. His is a self-taught designer and software engineer. This places him in a position to tell the technical story of these products, but, as it turns out, exposes his technical limitations. 

+/--- Ken reveals a culture of hacking and hard work, indeed as the author observes a type of organization derived from Tracy Kidder's Pulitzer-prize account of computer startups in the Valley in the 1980s (except the action in this book happens 15+ years later). In this story, Apple is a place where art and engineering do meet, where intuition is valued and working demos glorified, but ultimately the "engineers" merely hack things towards demos and then hope for a glorious hunch from micromanaging boss Steve Jobs. Their only excuse, turned in this book into pride? It worked, didn't it? (It did. iPhone was a great success. It also didn't. Safari?! Etc.) This part is valuable for preserving an oral history of an important company in Silicon Valley. 

+ There are various introductory pieces, such as that explaining the role of open-source advocate and software engineer Richard Stallman in the IT industry, and anecdotes, such as that explaining how Bill Atkinson had to wait like everyone else in line for an iPhone and thus made his own woodrn mockup. These add savor, and create lore. 

+ The design practices as understood by the author, so of software being developed largely by software developers with minimal input from professional designers, may seem misguided by a designer working in industrial design or architecture, but are still be common practice in (startup) cultures. Does the feature work? is still asked first, and much more frequently afterward, than How (well) does it work? 

--- The software engineering practices described in this book would make many recent graduates of technical universities shudder. Luckily, it's also old news for much of the industry at large. 

--- Unfortunately, the book fails in its main promise: despite the title, the author fails to produce an explanation of the design processes he witnessed (or, perhaps, even actively joined). The process of creative selection is not one used by the Apple's core design team, and as explained does not capture a credible design process. The authors throws in seven aspects of the process of which most seem common sense (and seemed the same in the 2000s), then proceeds to retrofit his experiences to these aspects, ignoring when things don't fit (was it collaboration when Steve Jobs decided on everything? Was it craft when emerged from inspiration? Or when the code was left largely untested and undocumented? Was it 'never resorting to half measures' when choosing colors based on intuition because it's too minor to bother? Etc.) This approach does not pass a minimal standard of skill, and the result is not shown to even match history as perceived by the author, so the theory of this book seems like a waste of time. 

[Artjoms Haleckis · Rating 2 out of 5]

Today I learned that I can write a book easily. Here is what I can include there:

* How I worked on a feature in one of my previous companies and then I made a DEMO of that feature to someone important
* How I had to participate in a huge project and then we had to make a quick prototype, then spend a lot of time actually developing a thing
* How I debug my code
* How I fix compiler errors on a daily basis
* How I decided to quit a company, then current company offered me to stay to participate in a cool project

What else is missing? OH! Dumb parallels with cooking! Because noone is interested in reading about actual software development, so let me wrap this into dumbest comparison I can think of and spend your precious time trying to connect the dots.

Yes, this guy worked at Apple. Yes, there is Steve Jobs mentioned multiple times. But this doesn't help. There are people that are good at writing code, and there are people that are good at writing books. I feel that Ken is good only at first. Such a time waster.

[Greg Williams · Rating 3 out of 5]

In "Creative Selection", Ken Kocienda lets us peek into the software development process for the original iPhone. With a conversational style, he describes what it was like to develop the Safari web browser and the iPhone keyboard. In the process, he ends up talking about what the software development process was like at Apple under Steve Jobs.

In a nutshell, the software process was very demo-driven (at least during the time he worked at Apple). The design of a product was honed by developing focused demos of software features and then iterating over and over again based on feedback. He coins this style of development "creative selection". Management used the demos to track the progress of the product development. Along with this demo-driven process, Apple used small teams that dreamed big and collaborated together to produce high quality products. The author emphasized that Apple strives to build products "at the intersection" of technology and the liberal arts, which requires a sense of empathy for the future users of a product.

I found this book to be pretty interesting and it made me consider how I might foster a "creative selection" process at my own job. I would definitely recommend this book to any software developer who is interested in Apple's process under Steve Jobs. At the same time, however, I wasn't really wowed by this book. I can't quite put my finger on it but I felt like there was something missing as I read it. Which is why my rating of this book is middle of the road.

[Peter Merholz · Rating 3 out of 5]

This framing of this book is a little misleading. Waaaaaay too much time is spent talking about coding web browsers that have nothing to do with the heart of the subject. When the discussion gets to building the iPhone, and specifically the author's work on the keyboard, it gets much more interesting.

[Shrey · Rating 4 out of 5]

I enjoyed the anecdotes and minutiae about product development at Apple (which were notably largely absent from the Steve Jobs biography). I was not expecting a digression into the struggles of implementing text editing, having endured it first hand. It was comforting throughout that there wasn’t some magic secret to the successes of these products, just the usual mix of hard work, technical skill, ingenuity and good taste. I was less convinced by the philosophizing in the latter half of each chapter. The desire to distill down a process into a listicle or an algorithm is understandable but as the anecdotes show, the details really matter.

[Sashko Valyus · Rating 5 out of 5]

Interesting book with nostalgia on Golden ages of the Apple, and its renaissance in digital world. From the insider eyes we see the way the the software was developed, refined and demoed. The last activity actually give the name for the book.
The first part of the book is a bit watery but even so it was a great adventure and you feel a bit sad in the end of the book.
Recommended not only for Apple fans

[H.Sharma · Rating 4 out of 5]

This book will take you to the past, as if you were there with the team, while the big launch was about to happen. It was fun to read, to know how a team of hard working people collaborated to build one of the best user experience providing device. When I first saw this book, I thought this would be more from a design perspective, but the book is fully about Ken's experience in apple.

[Alessandro Perilli · Rating 1 out of 5]

This is a terrible book. First of all, it has very little to do with Apple's overall design process as the title suggests. It's a book built around a few anecdotes related to the development of the iPhone keyboard, and nothing else.

Second, the book is full of unnecessary and boring repetitions (which inflate a 4 sentences story into a 40 pages chapter) and digressing chapters that have nothing to do with Apple or Steve Jobs or creative selection.

Third, the book is full of technicalities that the mainstream public (again, the one attracted by the title of the book) would find useless. The whole book narrative is the exact opposite of how Apple design is: unnecessary, redundant, unattractive.

It might be a book that appeals to some software engineers, but I think the general public will be very disappointed.

[Matt Goddard · Rating 5 out of 5]

I really enjoyed this book. It's a great insiders view of the development process during Apples most creative modern period.



It also reminded me of all the good time that can be had inside a development team. The fusion of creativity and technology to create new and interesting things.

Would recommend.

[Nikhil Vishnu · Rating 4 out of 5]

The iPad Keyboard I am using to type this review is a central character of the book Creative Selection. That is an interesting coincidence isn’t it?

Creative Selection is about Ken Kocienda’s look at Apple’s creative process. He spent 15 years at Apple working on various products like Safari, iPhone and iPad Keyboards. He explains the creative process behind all these products in detail. I liked the detailed explanation of things and his narration style but at times it tends to be a bit dramatic.

Apple’s focus on demo’s and how it plays a big role internally and externally is interesting. His take on development vs seeing the larger picture is right. Programmers usually pay attention to the parts that didn’t work quite right yet like fixing bugs and pushing for the next improvement. It is quite difficult to maintain a wider perspective in the midst of making.

Story of the iPhone and iPad keyboard is the best part of this book. Once you finish reading it you can’t look at this keyboard same way again. You will definitely see why Apple say that they always try to be at the intersection of technology and liberal arts.

Overall this is a really good read if you are curious about understanding how products are made in apple. My only complaint is about the over dramatisation of events.

[Christian · Rating 2 out of 5]

Disappointing to finally get around to this book and it doesn’t deliver on anything it promises. The author’s had a stellar career but man there’s just no book here. Example: chapter 1 is 32 pages long and only covers him giving a software demo of an iPad keyboard to Steve Jobs. Oof.

But the kicker is not only that he never really discusses what this design process (which is curiously pretty devoid of designers). Rather, the problem is there’s no focus and at worst he contradicts himself on Apple’s process:
“3. Doing the necessary grunt work and never resorting to shortcuts or half measures.” (Pg. 4)
Then:
“He cut corners to highlight the potential of this code…And it worked.” (pg. 61).
Then follows that stunning contradiction with a highly relevant comparison to “Singing in the Rain.”
Oof.

[Kirk Gartside · Rating 4 out of 5]

Mr. Kocienda offers some interesting insights and anecdotes on product development at Apple. I especially enjoyed the opening chapter on his iPad demo. That emphasis on demos and feedback hit home because of some of the software development work my teams have been doing. I've thought about recommending it to a few developers, but give them the caveat that the technology portions are written for people without a software engineering background.

[Anastasiia · Rating 3 out of 5]

the book isn’t super special and can be a bit dull, especially for those who has some programming experience.

however, i really liked how it made me feel.
it reminded me how great it is to create products.
that failures are absolutely okay and mainly unavoidable.
and that it’s okay to feel lost on your path.
just keep looking for your thing.

so it's definitely a good and easy read for inspiration.

plus it shares interesting insights on how some Apple software was developed.

[David Siu · Rating 5 out of 5]

He described Apple's creative process well. But I am sure his description of how Jobs led would give permission to more Jobs-wannabes to be mean and rude to their teams. Oh well.

[Sumit Gouthaman · Rating 5 out of 5]

The stories themselves are quite fun and definitely worth reading/listening, even if you ignore the discussion about the underlying software development principles.

Would recommend!

[Antonio Rodriguez · Rating 5 out of 5]

One of the best in the trenches software building memoirs

This book does an amazing job describing what a regular day-to-day stuff an engineer/designer needs to do to bring new products into the world. The Apple part is bonus; anyone who wants to build software for a living should read this, especially anyone who wants to work in new emerging domains.

[Chris · Rating 5 out of 5]

Creative Selection is, hands down, the best book I have ever read about software dev at Apple. A must read for any iOS dev. Couldn’t put it down!

[Vivify M · Rating 3 out of 5]

The book seems to be a wonderfully honest account of the authors experience. In that way I think it is valuable for examination. I didn't agree with everything the author said, but I very much appreciated his emphasis on the importance of grit and polish. He repeatedly described how much more time was spent on polishing and implementing, than the profound moments of design. I think this is a super important message.
The book is also a really great reminder of the importance of prototyping, rapid lean development, and rewriting code. But, I found myself at odds with the authors examples. In particular, early chapters explain how a code base was chosen to develop Safari. Perhaps I misunderstood something about the problem they were trying to solve. But, in this case it seemed to me that the questions that needed answering were technical - which code base would provide the most flexibility, performance and seedy development. I'm not convinced that by getting something hacked together quickly they were answering those questions. In many cases this would be the correct course of actions, but those cases are justified by the need to test with users and develop interfaces rapidly. In this case it seems to me that they really needed to make longer term technology decisions instead.
A lot can be said about the oracle worship, that the author seems to endorse. There is much written about more scientific ways of discovering solutions. There are processes and organisational structures which are better at fostering staff development and autonomy. Then there are the articles which emerged in the wake of this book, which explained how the same kind of callous feedback was experienced very differently by others in the organisation.
I see the appeal in working for an oracle, But it’s the same as any autocrat, it only works when the autocrat is successful, and only for those who are lucky enough to be on their good side.
The book also made me appreciate how much of what apple were doing was creating fashion products. These were not investigations into what would improve people's lives, and what the best way of doing it was. It was about creating desire in people, and then exploiting that. The author likes to point out the impact the technology has had on society, but I found myself annoyed by the intentions.
It concerns me that books like this inspire organisations to develop solutions in isolation and arrogance.

[Mark Opalski · Rating 5 out of 5]

A glimpse inside the Steve Jobs era of design

Remember the popularity of the crackberry? You might remember being a bit fascinated and skeptical about typing on the new iPhone touchscreen keyboard.

We take it all for granted now. But there was a time when no one knew if it would work. This story is told by Ken, the software developer who was at the heart of the unknown outcome and the steps he went through with his team to make the software into the pervasive Interface control we all know and use everyday.

It’s easy to take for granted now, but success wasn’t assured. Apple had to overcome the risk of failing in the market like it did with the Newton. So the pressure was on and this team delivered, so how did they do it?

Ken walks us through how he made it, what it was like to demo it to Steve Jobs. What it was like to work at Apple during the company’s highest moments and how his smart and humble team helped him get it done.

This book is for...
It’s an interesting read if your at all interested in the mystery of Apple’s top secret product creation process. I’m in the tech business myself, I imagine many of my peers in usability and product design enjoying this book.

[Христо Блажев · Rating 4 out of 5]

Креативен отбор – мемоар от златните години на Стив Джобс и Apple: http://knigolandia.info/book-review/k...

За мен “Креативен отбор” е сред най-интересните мемоари, които съм имал възможност да прочета – защото не се съсредоточава върху един човек, самият Косиенда си има самочувствие, но то е силно обуздано. Това е по-скоро мемоар за част от исторята на топ технологична компания и начините, по които тя работи чрез облагородяване на идеите чрез еволюционен отбор – точно както в природата. Това е история на съсредоточаване на човешки гений в област, която съществува от едва броени години, и която тъкмо е поела на поход към промяна на света. Златните години на Apple са и златни години за начините, по които комуникираме, работим, слушаме музика, гледаме видео и какво ли още не. И мога да кажа, че неусетно тази книга пося в мене семената на желанието да бъда част от тази легенда. Да видим.

CIELA Books
http://knigolandia.info/book-review/k...

[Kuldeep Dhankar · Rating 4 out of 5]

This is a beautiful page-turner account of Ken Kocineda's career at Apple. Of course we all know him as the guy who programmed the virtual keyboard of the original iPhone.

Ken switches back and forth between gripping accounts of the going on behind the secretive doors of Apple, and the philosophies that guide the product engineering at the company. FWIW it is a good mix and you are never bored throughout the book. I finished the book in a single session of about 3 hours and was left with the warm fuzzy feeling you get after reading a well crafted book.

I highly recommend this book to anyone who has ever wondered how Apple builds product. This is by far the best account I have ever read.

[Bill Calkins · Rating 5 out of 5]

If you are interested in developing software, this is a book that will gives you insight into how Apple does it. Some great practical advice and some great stories about working with Scott Forstall and Steve Jobs. The name Darwin for the kernel software makes more sense after reading this book.

I wish there would be a version of this book for developers. He is very good at explaining complicated programming concepts but for those of us who understand B-trees and linked list and how to implement them in C++ it would have been fun to dig into the code with him.

He does a great job of making this book accessible for anyone.

[Kristina · Rating 5 out of 5]

Much prefer it to other era defining creativity and product development books like Creativity, Inc or Jony Ive's bio.
This one is very rational, detail oriented overview of the internal work on Safari browser and first iPhone keyboard. Has less buzzword sloganisms and more internal demo work and overcoming technical challenges. Design is making things work well, not making them look pretty and that comes from one of the key engineers at Apple.

[Barry Saunders · Rating 4 out of 5]

A great look at process

A great deep dive into the nuance of software design, focused on Safari and the iOS keyboard. Definitely worth reading if you work in design or software.