Creative Selection Quotes

“a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything but a specific and well-chosen thing, to take words and turn them into a vision, and then use the vision to spur the actions that create the results.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“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. And though coming up with such a vision is difficult, it’s unquestionably more difficult to complete the entire circuit, to come up with an idea, a plan to realize the idea, and then actualize the plan at a high standard, all without getting bogged down, changing direction entirely, or failing outright.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“When Lombardi joined the Green Bay Packers in 1959, the team had gone eleven straight seasons without a winning record, and after winning only one of twelve games the previous year, the team fired Lombardi’s predecessor. Upon arriving at training camp as their new head coach, Lombardi made an immediate and indelible first impression on Bart Starr, a struggling third-string, fourth-year quarterback. After leading the players to a meeting room, Lombardi waited in front of a portable blackboard as the players sat down. He picked up a piece of chalk and began to speak. “Gentlemen,” he said, “we have a great deal of ground to cover. We’re going to do things a lot differently than they’ve been done here before . . . [We’re] going to relentlessly chase perfection, knowing full well we will not catch it, because perfection is not attainable. But we are going to relentlessly chase it because, in the process, we will catch excellence.”6 He paused and stared, his eyes moving from player to player. The room was silent. “I’m not remotely interested in being just good,” he said with an intensity that startled them all.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Sometimes, in the development of the browser, even our best investigations and “thinking outside the box” ideas weren’t sufficient. There were plenty of instances when we were about to integrate a new feature, only to find that there truly was no way to add the code without a negative impact on speed. As we introduced features like clicking the back button to return you to your previously viewed web page, we found we couldn’t perform the bookkeeping to maintain the previous page at quick readiness without impeding the load of all pages. The PLT showed the slowdown. When we deemed such features too important to skip but couldn’t figure out how to add them without causing such slowdowns, we instituted a trading scheme, where we found speedups in unrelated parts of our existing source code to “pay for” the performance cost of the new features. When we looked around for code to perform this kind of payoff optimization, we typically targeted code we knew well and that was stable, preferably both. Once found, we tuned this proxy code to function the same, only faster, and sufficiently faster that we wound up with either a nil or a positive net impact on performance when we added both the feature-laden code and the speed-payoff code to our project.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“He had us carefully choose our optimization opportunities based on clear and provable knowledge about what was slow and hash things out right at the moment we found the slowness. The PLT helped us to correctly distribute optimization work throughout the entire project. We optimized when we knew what we were doing, in direct response to measuring code with the PLT.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“The PLT helped us to understand what our programming instructions were doing along the essential axis of speed and showed us precisely when and where we were introducing slowness to our source code. The PLT told us when to pay attention to the “small efficiencies” Knuth mentioned. It was our 3 percent escape hatch, a way to know for sure that optimization wasn’t “premature.” We were sure each optimization we did was helping to keep performance heading in the right direction.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“For software developers who take their work seriously, Knuth is the consummate craftsman. Here’s what he has to say about optimization: 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.2 (Emphasis added.)”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“There could be no exceptions to the PLT speed rule—Don wouldn’t allow it. When an essential bit of new code caused a slowdown, things could get tricky. Finding remedies for speed setbacks typically involved the prickly issue of software optimization”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Before the PLT, our editorial process was primarily concerned with feature implementation, bug fixes, and web standards compliance—how well the browser did what it was supposed to do. These were all qualitative measures. The PLT checked for speed, a quantitative test, and it introduced an independent evaluation to every code change we made. Correctness and speed now went hand in hand. Don held that if we heeded the PLT without fail and rejected any code changes that made our code slower, only two things could happen. Either the browser would stay the same speed . . . or it would get faster. He would tap his index finger to his temple to punctuate his explanation of this sneaky logic. From the day the PLT was finished, Don declared, our browser would become faster by never getting slower. It was his Zen koan.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Don was the one who figured out how we would make our code quick. One day, a month or two after the Black Slab Encounter, he called me into his office and asked me to create a test program to measure browser speed. He envisioned an automated tool that would launch our browser app and command it to load a suite of web pages, one after the other, in rapid succession. Over the next couple days, I wrote the code to do just that. I named it the Page Load Test, but we soon took to calling the PLT.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“In deceptively brief terms, Edison tells us: “I make trial after trial until it comes.” He and his team were willing to perspire, but he also knew what he would be doing with all those hours: trial and error. For the lightbulb, filaments were the key, and bamboo was the most promising material, so Edison tested every kind of bamboo to find the best. If Burns is to be believed, there were twelve hundred varieties of bamboo, and Edison tried each one. It sounds simple, and it was, but the way Edison defined the project also gave it a shape. He crossed off items from a to-do list. When we made our porting strategy for the web browser, we turned to something like Edison’s model. We knew the compiler would tell us about broken cross-references, and we examined all of them one at a time. We knew our FIXMEs would tell us where our code was weakest, and we studied the reports closely. Moving toward the Black Slab Encounter was a stepwise process, much like Edison’s search for the best bamboo. Edison did trial after trial with filaments; we went file after file in our build process and FIXME after FIXME trying to load a web page. Both projects were built on unglamorous grunt work, but the specifics matter. Edison wasn’t just trudging toward the horizon in a desert, hoping that the crest of the next sand dune would reveal an oasis—that sounds more like the way that Don and I wandered through our browser investigations in the weeks before Richard joined us. Instead, Edison searched specifically for the best kind of bamboo, and he was undaunted by the need to check a vast number of varieties. Each one he tested was an item crossed off and brought him closer to finding which one was the best. In the lead up to the Black Slab Encounter, we did the same. Even though Don, Richard, and I struggled with the tedium, we kept plowing through each file and FIXME.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“For Edison, it was more important to build on promising ideas and keep working and working until an invention was made real.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Edison didn’t dream up the idea of electric lighting on his own, and carbon had been used in lightbulb filament investigations long before Edison started looking into its suitability—Joseph Swan experimented with carbon extensively. Yet such predecessors failed to create a practical lightbulb. Edison succeeded. Why? An adequate explanation must include Edison’s conception of electric lighting as a complex electric generation and distribution system, his already-established track record as an inventor, his ability to parlay his reputation into the necessary corporate funding for his investigations, and his vision to establish and lead one of the first product-oriented research and development labs, an organization that efficiently coordinated the efforts of many.5”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“There was no exit from the tedium. We just had to keep going. Yet, every hour of monotony was a contribution to our porting strategy, and every file we went through was an opportunity to read and learn about our adopted source code. Slowly, day after day, week after week, we whittled down the list of files we still needed to build.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“computer programs are much like cookbook recipes. Both offer specific directions to accomplish a task. Yet, while chefs write their cookbooks to be read by people, programmers can’t write for computers in the same way, because computers don’t natively comprehend programming languages. Computers speak a binary language of 0s and 1s, so to get a computer to perform my job, I have to convert my C++ code into a computer-consumable binary form using a program called a compiler. This conversion process of human-readable to machine-runnable is called compilation or building. This translation procedure also explains why lines of code written in a programming language are called source code. They’re the source material a compiler builds into (i.e., translates into) binary code the computer can execute.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“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 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.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“When I make a demo, I think about the intended audience, and I make a specific decision about what features to include. I draw a conceptual ring around those key details, and I use a thick imaginary marker to do it. The demo points inside the ring are the focus, and like the lamppost in the movie scene, I depict them with the highest fidelity. I leave outside the ring other less important details that will eventually have to be addressed, but not immediately. I pay them as little attention as possible.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“The font rendering was not to Apple standards—some characters were jaggy rather than smooth—but text was legible enough, so Richard expended no more effort on typography. He spent no time at all on irrelevant details, like keyboard shortcuts or a beautifully designed app icon. He chose this combination of important/passable/ignorable features carefully to maximize impact, minimize distractions, and fit the work schedule he’d set for himself.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“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.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“If Don and I had continued working in the Eazel way at Apple, who knows when we would have had a demo to show? At that point in our careers, we simply didn’t know how to bootstrap a big project and set it on a course for success. Richard did. His demo was the lynchpin. He showed us that the Konqueror web browser could work on the Mac. He cut corners to highlight the potential of this code. Of course, Richard’s brilliant software shim made his breakthrough possible, but consider the conceptual framework he’d built around his plan and how he’d cornered all the difficulties of making a browser demo so that one piece of custom programming, his shim, was all that was left to close the circle. The cumulative effect created the illusion of a real browser even when only showing an incomplete portion of one.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“What can explain this difference? On the surface, much appears to hinge on Richard’s programming feat, his software shim. Otherwise, his effort with Konqueror seems much like my struggles with Mozilla. Perhaps he was just a better programmer than me, and without his coding cleverness, there would be no story. That explanation is too simple. Richard made his shim only after determining he needed one last link in a chain of inspiration, intuition, reasoning, and estimation. His shim was a consequence of his overall plan. To show what I mean, here’s an accounting of what Richard did in his first couple of days at Apple. He began by quizzing us on the browser analysis we had done before his arrival, and after hearing it, he quickly discarded our effort with Mozilla as unlikely to bear fruit. By doing so, he demonstrated the self-confidence to skip any ingratiating display of deference to his new manager, a person who had years of experience in the technical field he was newly entering. Next, Richard resolved to produce a result on the shortest possible schedule. He downloaded an open source project that held genuine promise, the Konqueror code from KDE, a browser that might well serve as the basis for our long-term effort. In getting this code running on a Mac, he decided to make the closest possible approximation of a real browser that was feasible on his short schedule. He identified three features—loading web pages, clicking links, and going back to previous pages. He reasoned these alone would be sufficiently compelling proofs of concept. He then made his shortcuts, and these simplifying choices defined a set of nongoals: Perfect font rendering would be cast aside, as would full integration with the Mac’s native graphics system, same for using only the minimum source code from KDE. He reasoned that these shortcuts, while significant, would not substantially detract from the impact of seeing a browser surf web pages. He resolved to draw together these strands into a single demo that would show the potential of Konqueror. Then, finally, he worked through the technical details, which led him to develop his software shim, since that was the only thing standing between him and the realization of his plan. His thought process amplified his technical acumen. In contrast, Don and I were hoping Mozilla would pan out somehow. I was trying to get the open source behemoth to build on the Mac, with little thought beyond that. I had no comparable plan, goals, nongoals, tight schedule, or technical shortcuts.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“However, in the early phase of software development, it’s possible to shake free of these restrictions, especially when teams are small and the hunt for ideas is still on. This was the scenario when Richard joined us at Apple. We were still looking for an organizing concept to kick-start our web browser effort, and Richard showed us how. Not only that, he proved that a 10x productivity gap is a conservative upper limit on the possible in early stage software. Indeed, Richard did more to move our project ahead in two person-days of work than Don and I had done in the preceding twelve person-weeks. That’s more like a 30x gap.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Richard Williamson began by telling me that he knew how to get results fast.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Sitting to Henri’s left on the couch was his boss, Scott Forstall, then the senior vice president of iOS software engineering. Scott reported directly to Steve, and he was the one giving me this chance to demo in Diplomacy. Scott expected me to keep it concise and on point when it was my turn to go. He didn’t tell me to do that—proper conduct was implicitly communicated through the success and failure of the earlier-stage demo sessions Scott ran himself, where he was the top executive in the room.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“If indeed we had that chance, we fumbled it. We never lived up to any of our lofty goals. 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. Nothing worked smoothly. Our software update feature was riddled with bugs that often broke programs while trying to update them. Our code to connect Nautilus to our cloud services didn’t work at all. The Nautilus team had persistent problems coordinating with GNOME—the loose structure and lack of profit motive of the free software community meant that they did not share our money-making goals or care to coordinate with us so we could meet our delivery schedules. All these setbacks caused delay after delay.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Demo reviews were also part of Steve’s effort to model the product development behaviors he wanted us to use when he couldn’t be present. As in Diplomacy, the whole software organization kept meetings and teams small to maintain efficiency and to reinforce the principle of doing the most with the least. Steve’s constant demand to see a succession of demos spawned numerous other demos, each with their own presenters and deciders. All these demos helped the entire software team stay focused on making great products.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Bas never expressed any disappointment over his zoom animation getting deleted either. Seeing good work wind up on the cutting room floor was part of the job.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them. Steve’s brand of decisiveness”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“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 lives.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

“Such hierarchically restricted access to the CEO can’t be too different from what happens with other large companies, but the way to get admission to these high-level meetings at Apple had much less to do with your place on the org chart and much more to do with your ability to make the products better.”
― Ken Kocienda, Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs