Month: September 2019

I recommend this book to learn about product development from a software engineer and designer who had worked on various important products in Apple such as Safari browser and iPhone. Below are my key takeaways from the books:

• Demo served as the primary means to turn ideas into software.
• 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. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday life.
• Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.
• 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. I started to understand how demos could play all these roles in creative and technical work when I was surprised by a single brilliant demo during my first few weeks at Apple, a moment that gave me my first real view into how the company made its software.
• Chief among our missteps was failing to conceive of our software as a single product instead of as a set of separate projects. We never figured out how to integrate the pieces.
• Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate the 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 your demos.
• Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
• It represented an important technical insights: When software behavior is mysterious, get more organized.
• People matter more than programming.
• 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.”
• Every major feature on the iPhone started as a demo, and for a demo to be useful for us, it had to be concrete and specific. We need concrete and specific demos to guide our work, since even an unsophisticated idea is hard to discuss constructively without an artifact to illustrate it.
• 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 a brainstorming session.
• 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. Whiteboard discussions feel like work, but often they’re not. It’s difficult to talk productively about ideas in the abstract.
• Literally, we couldn’t get away with telling. We were required to show. We combined some inspiration, craft, taste, and decisiveness, and we shared our results. We had to work like this, because the team didn’t accept anything unless it is concrete and specific, and a demo showing what we meant. Then we tried out each other’s demos, said what we liked and what we didn’t, and offered suggestions for improvements, which led to more demos and more feedbacks.
• Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positives ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all.
• Empathy is a crucial part of making great products.
• As a creative and technical practitioner, I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. That doesn’t give product designers the license to ignore philosophy. Rather, in my case, I recognized that I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.
• A lack of specific thoughts isn’t a big deal when picking fruits to put on top of breakfast cereal, but such gaps are an issue in creative work. Persist too long in making choices without justifying the, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions.
• Building trust in a personal refined-like response takes time and practice. It also requires a measuring stick. Studying great work from the past provides the means of comparison and contrast and lets us tap into the collective creativity of previous generations.
• The past is a source of the timeless and enduring. This is where Kant returns to the discussion, and this notion suggests how his philosophy might figure into creative work. I can use Kant , but only if I know about him, and only to the extent that I’ve internalized what he said and what it means to me.
• The same goes for the whole scope of creative achievement, from the paintings of Frida Kahlo, the blues music of the Reverend Gary Davis, the theories of Charles Darwin, the philosophy of Lao Tzu, the software optimization ideas of Donald Knuth, or the beliefs and practices of the ancient Greek visitors to the Delphic Oracle. When I study the past, I make a point of deciding what I like, and sometimes this build-up catalog of refined-like response about past works finds a suitable outlet and a natural expression in my present-day work.
• We used the word ‘heuristics’ to describe aspects of software development that tip toward the liberal arts. Its counterpart, “algorithm”, was its alter ego on the technical side. Heuristics and algorithms are like two sides of the same coin. Both are specific procedures for making software do what it does, taking input, applying an operation, and producing output. Yet each had a different purpose.
• Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction, as in the case of the nearly yearlong effort to improve the performance of Safari.
• Heuristics also have a measurement or value associated with them – the duration for an animation or the red-green-blue values for an onscreen colour, but there isn’t a similar “arrow of improvement” that always points the same way. Unlike evaluating algorithms, heuristics are harder to nail down.
• Algorithms and heuristics must coordinate to make a great high-tech product.
• When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources – code, graphics, animations, sounds, icons and more – to produce a demo. After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement. Many times this came down to tuning some heuristics, or modifying how an algorithm and heuristic combined. Whatever it was, the concrete and specific modifications we chose to make led to the actions items that justified making the next demo. Repeat, then repeat again. Doing this over and over again set out projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product.
• I’d like to end with a note to readers at the beginning of their careers. You might be telling yourself that you want a career in product development. You may have plans to do great things in some other fields. Either way, I have some advice: Get busy. Decide what it means to do great work, and then try to make it happen. Success is never assured, and the effort might not be easy, but if you love what you’re doing, it won’t seem so hard.
• There weren’t any company handbooks describing these elements. Nobody outlined this list in a new-employee orientation. This list was distilled from the everyday work at Apple.
  • Inspiration: Thinking big ideas and imaging what might be possible
  • Collaboration: Working together well with other people and seeking to combine your complementary strengths
  • Craft: Applying skill to achieve high-quality results and always striving to do better.
  • Diligence: Doing the necessary grunt work and never resorting to shortcuts and half measures.
  • Decisiveness: Making tough choices and refusing to delay or procrastinate.
  • Taste: Developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
  • Empathy: Trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs.