1 Followers
22 Following
ybrikman

ybrikman

The Startup Owner's Manual Strategy Guide

The Startup Owner's Manual Strategy Guide - Steven Gary Blank, Bob Dorf Despite the title, this is not a general purpose strategy guide for startups, but a guide focused on how to validate products in the market. Of course, this is still an important topic, and most startups should follow the iterative approach in this book. The ideas of seeing a startup as search process, seeing product development as a series of experiments, and the pivot or proceed examples at the end are great. That said, the writing style sounds like an infomercial (the book regularly describes itself with superlatives like "revolutionary") and is *extremely* repetitive. You get 90% of the value from reading the introduction. Skim the rest.

Some good quotes:

Today, after half a century of practice, we know unequivocally that the traditional MBA curriculum for running large companies like IBM, GM and Boeing does not work in startups. In fact, it’s toxic. With the benefit of hindsight, entrepreneurs now understand the problem, namely that startups are not simply smaller versions of large companies. Companies execute business models where customers, their problems, and necessary product features are all “knowns.” In sharp contrast, startups operate in “search” mode, seeking a repeatable and profitable business model. The search for a business model requires dramatically different rules, roadmaps, skill sets, and tools in order to minimize risk and optimize chances for success.

But what exactly is a startup? A startup is not a smaller version of a large company. A startup is a temporary organization in search of a scalable, repeatable, profitable business model.

Winners also recognize their startup “vision” as a series of untested hypotheses in need of “customer proof.” They relentlessly test for insights, and they course-correct in days or weeks, not months or years, to preserve cash and eliminate time wasted on building features and products that customers don’t want.

Startups begin with a set of initial hypotheses (guesses), most of which will end up being wrong. Therefore, focusing on execution and delivering a product or service based on those initial, untested hypotheses is a going-out-of-business strategy.

A startup is a temporary organization designed to search for a repeatable and scalable business model. Within this definition, a startup can be a new venture or it can be a new division or business unit in an existing company.

Search embraces failure as a natural part of the startup process.

If you’re afraid to fail in a startup, you’re destined to do so.

The customer discovery process searches for problem/solution fit: “have we found a problem lots of people want us to solve (or a need they want us to fill)” and “does our solution (a product, a website, or an app) solve the problem in a compelling way?”

Drive: The Surprising Truth About What Motivates Us

Drive: The Surprising Truth About What Motivates Us - Daniel H. Pink A well written, short, occasionally funny, and always inspiring and motivating (imagine that) book that talks about the science behind human motivation. Most businesses are still run the way they were in the 19th century, with carrots and sticks, oblivious to the fact that the nature of work has changed dramatically. This book talks about how to upgrade to a new model based on autonomy, mastery, and purpose. If you've ever felt frustrated at your job or your manager, this book likely explains why. If you want to do better, read it.

Some fun quotes:

Rewards can deliver a short-term boost—just as a jolt of caffeine can keep you cranking for a few more hours. But the effect wears off—and, worse, can reduce a person’s longer-term motivation to continue the project.

Walk into the IT department of a large company anywhere in the world and ask for a tour. That company’s corporate computer servers could well run on Linux, software devised by an army of unpaid programmers and available for free. Linux now powers one in four corporate servers. Then ask an employee to explain how the company’s website works. Humming beneath the site is probably Apache, free open-source Web server software created and maintained by a far-flung global group of volunteers. Apache’s share of the corporate Web server market: 52 percent. In other words, companies that typically rely on external rewards to manage their employees run some of their most important systems with products created by nonemployees who don’t seem to need such rewards.

The consulting firm McKinsey & Co. estimates that in the United States, only 30 percent of job growth now comes from algorithmic work, while 70 percent comes from heuristic work. A key reason: Routine work can be outsourced or automated; artistic, empathic, nonroutine work generally cannot.

Routine, not-so-interesting jobs require direction; nonroutine, more interesting work depends on self-direction.

In other words, rewards can perform a weird sort of behavioral alchemy: They can transform an interesting task into a drudge. They can turn play into work. And by diminishing intrinsic motivation, they can send performance, creativity, and even upstanding behavior toppling like dominoes.

Only contingent rewards—if you do this, then you’ll get that—had the negative effect. Why? “If-then” rewards require people to forfeit some of their autonomy.

“Those artists who pursued their painting and sculpture more for the pleasure of the activity itself than for extrinsic rewards have produced art that has been socially recognized as superior,” the study said. “It is those who are least motivated to pursue extrinsic rewards who eventually receive them.”

Goals may cause systematic problems for organizations due to narrowed focus, unethical behavior, increased risk taking, decreased cooperation, and decreased intrinsic motivation. Use care when applying goals in your organization.

By offering a reward, a principal signals to the agent that the task is undesirable. (If the task were desirable, the agent wouldn’t need a prod.)

Pay your son to take out the trash—and you’ve pretty much guaranteed the kid will never do it again for free. What’s more, once the initial money buzz tapers off, you’ll likely have to increase the payment to continue compliance.

Rewards do not undermine people’s intrinsic motivation for dull tasks because there is little or no intrinsic motivation to be undermined.

Any extrinsic reward should be unexpected and offered only after the task is complete.

Most leaders believed that the people in their organizations fundamentally disliked work and would avoid it if it they could. These faceless minions feared taking responsibility, craved security, and badly needed direction. As a result, “most people must be coerced, controlled, directed, and threatened with punishment to get them to put forth adequate effort toward the achievement of organizational objectives.” But McGregor said there was an alternative view of employees—one that offered a more accurate assessment of the human condition and a more effective starting point for running companies. This perspective held that taking an interest in work is “as natural as play or rest,” that creativity and ingenuity were widely distributed in the population, and that under the proper conditions, people will accept, and even seek, responsibility.

As the strategy guru Gary Hamel has observed, management is a technology. And like Motivation 2.0, it’s a technology that has grown creaky. While some companies have oiled the gears a bit, and plenty more have paid lip service to the same, at its core management hasn’t changed much in a hundred years. Its central ethic remains control; its chief tools remain extrinsic motivators. That leaves it largely out of sync with the nonroutine, right-brain abilities on which many of the world’s economies now depend.

Indeed, just consider the very notion of “empowerment.” It presumes that the organization has the power and benevolently ladles some of it into the waiting bowls of grateful employees. But that’s not autonomy. That’s just a slightly more civilized form of control. Or take management’s embrace of “flex time.” Ressler and Thompson call it a “con game,” and they’re right. Flexibility simply widens the fences and occasionally opens the gates. It, too, is little more than control in sheep’s clothing. The words themselves reflect presumptions that run against both the texture of the times and the nature of the human condition. In short, management isn’t the solution; it’s the problem.

A study of 11,000 industrial scientists and engineers working at companies in the United States found that the desire for intellectual challenge—that is, the urge to master something new and engaging—was the best predictor of productivity. Scientists motivated by this intrinsic desire filed significantly more patents than those whose main motivation was money, even controlling for the amount of effort each group expended.

According to Dweck, people can hold two different views of their own intelligence. Those who have an “entity theory” believe that intelligence is just that—an entity. It exists within us, in a finite supply that we cannot increase. Those who subscribe to an “incremental theory” take a different view. They believe that while intelligence may vary slightly from person to person, it is ultimately something that, with effort, we can increase. To analogize to physical qualities, incremental theorists consider intelligence as something like strength. (Want to get stronger and more muscular? Start pumping iron.) Entity theorists view it as something more like height. (Want to get taller? You’re out of luck.)f If you believe intelligence is a fixed quantity, then every educational and professional encounter becomes a measure of how much you have. If you believe intelligence is something you can increase, then the same encounters become opportunities for growth. In one view, intelligence is something you demonstrate; in the other, it’s something you develop.

There is no reason to believe any longer that only irrelevant ‘play’ can be enjoyed, while the serious business of life must be borne as a burdensome cross. Once we realize that the boundaries between work and play are artificial, we can take matters in hand and begin the difficult task of making life more livable.

In other words, in America alone, one hundred boomers turn sixty every thirteen minutes.
Every thirteen minutes another hundred people—members of the wealthiest and best-educated generation the world has ever known—begin reckoning with their mortality and asking deep questions about meaning, significance, and what they truly want.

We know that human beings are not merely smaller, slower, better-smelling horses galloping after that day’s carrot. We know—if we’ve spent time with young children or remember ourselves at our best—that we’re not destined to be passive and compliant. We’re designed to be active and engaged. And we know that the richest experiences in our lives aren’t when we’re clamoring for validation from others, but when we’re listening to our own voice—doing something that matters, doing it well, and doing it in the service of a cause larger than ourselves.

“Do rewards motivate people? Absolutely. They motivate people to get rewards.”

Delivering Happiness: A Path to Profits, Passion, and Purpose

Delivering Happiness: A Path to Profits, Passion, and Purpose - Tony Hsieh Fun, quick read. Tells the tale of Zappos' difficult journey, from the very shaky and painful early years to the successful acquisition in the later years. After a slightly slow start looking at Tony Hsieh's earlier life, it gets going with good discussions of the importance of relationships, company culture, values, beliefs, and happiness. The book is a good reminder that a company is more than a product. To its customers, employees, investors, and fans, Zappos is much more than just a company that sells shoes.

Some fun quotes:


As our group grew, I realized that forming new friendships and deepening the connections within our burgeoning tribe was bringing both a sense of stability and a sense of excitement about the future for all of us. The connectedness we felt was making all of us happier, and we realized that it was something that we had all missed from our college days. It was something that, like many people, we had unwittingly lost upon graduating from college, and we didn’t realize how much we missed it until we accidentally recreated it for ourselves.

My advice is to stop trying to “network” in the traditional business sense, and instead just try to build up the number and depth of your friendships, where the friendship itself is its own reward. The more diverse your set of friendships are, the more likely you’ll derive both personal and business benefits from your friendships later down the road. You won’t know exactly what those benefits will be, but if your friendships are genuine, those benefits will magically appear 2–3 years later down the road.

We didn’t know it at the time, but all the hard work and investments we made into customer service and company culture would pave the way for us to hit our goal of $1 billion in gross merchandise sales in 2008—two years ahead of our original goal of 2010. Looking back, a big reason we hit our goal early was that we decided to invest our time, money, and resources into three key areas: customer service (which would build our brand and drive word of mouth), culture (which would lead to the formation of our core values), and employee training and development (which would eventually lead to the creation of our Pipeline Team). Even today, our belief is that our Brand, our Culture, and our Pipeline (which we internally refer to as “BCP”) are the only competitive advantages that we will have in the long run. Everything else can and will eventually be copied.

Over the years, the number one driver of our growth at Zappos has been repeat customers and word of mouth. Our philosophy has been to take most of the money we would have spent on paid advertising and invest it into customer service and the customer experience instead, letting our customers do the marketing for us through word of mouth.

At Zappos, our belief is that if you get the culture right, most of the other stuff—like great customer service, or building a great long-term brand, or passionate employees and customers—will happen naturally on its own. We believe that your company’s culture and your company’s brand are really just two sides of the same coin. The brand may lag the culture at first, but eventually it will catch up. Your culture is your brand.

I think when people say they dread going into work on Monday morning, it’s because they know they are leaving a piece of themselves at home. Why not see what happens when you challenge your employees to bring all of their talents to their job and reward them not for doing it just like everyone else, but for pushing the envelope, being adventurous, creative, and open-minded, and trying new things?

Built to Last: Successful Habits of Visionary Companies

Built to Last: Successful Habits of Visionary Companies - Jim Collins, Jerry I. Porras A well written, thoroughly researched, and actionable book on how to build great companies. A must read for any founder, CEO, or manager.

Some fun quotes:

Visionary companies distinguish their timeless core values and enduring purpose (which should never change) from their operating practices and business strategies (which should be changing constantly in response to a changing world).

Gone forever—at least in our eyes—is the debilitating perspective that the trajectory of a company depends on whether it is led by people ordained with rare and mysterious qualities that cannot be learned by others.

Having a great idea or being a charismatic visionary leader is “time telling”; building a company that can prosper far beyond the presence of any single leader and through multiple product life cycles is “clock building.

The builders of visionary companies tend to be clock builders, not time tellers. They concentrate primarily on building an organization—building a ticking clock—rather than on hitting a market just right with a visionary product idea and riding the growth curve of an attractive product life cycle. And instead of concentrating on acquiring the individual personality traits of visionary leadership, they take an architectural approach and concentrate on building the organizational traits of visionary companies. The primary output of their efforts is not the tangible implementation of a great idea, the expression of a charismatic personality, the gratification of their ego, or the accumulation of personal wealth. Their greatest creation is the company itself and what it stands for.

Thus, early in our project, we had to reject the great idea or brilliant strategy explanation of corporate success and consider a new view. We had to put on a different lens and look at the world backward. We had to shift from seeing the company as a vehicle for the products to seeing the products as a vehicle for the company.

If you equate the success of your company with success of a specific idea—as many businesspeople do—then you’re more likely to give up on the company if that idea fails; and if that idea happens to succeed, you’re more likely to have an emotional love affair with that idea and stick with it too long, when the company should be moving vigorously on to other things. But if you see the ultimate creation as the company, not the execution of a specific idea or capitalizing on a timely market opportunity, then you can persist beyond any specific idea—good or bad—and move toward becoming an enduring great institution.

We suggest that the continual stream of great products and services from highly visionary companies stems from them being outstanding or organizations, not the other way around.

Profitability is a necessary condition for existence and a means to more important ends, but it is not the end in itself for many of the visionary companies. Profit is like oxygen, food, water, and blood for the body; they are not the point of life, but without them, there is no life.

In examining the history of the visionary companies, we were struck by how often they made some of their best moves not by detailed strategic planning, but rather by experimentation, trial and error, opportunism, and—quite literally—accident. What looks in hindsight like a brilliant strategy was often the residual result of opportunistic experimentation and "purposeful accidents."

It might be far more satisfactory to look at well-adapted visionary companies not primarily as the result of brilliant foresight and strategic planning, but largely as consequences of a basic process—namely, try a lot of experiments, seize opportunities, keep those that work well (consistent with the core ideology), and fix or discard those that don’t.

Maximize shareholder wealth” is the standard “off-the-shelf” purpose for those organizations that have not yet identified their true core purpose. It is a substitute ideology, and a weak substitute at that.

When a Boeing engineer talks about launching an exciting and revolutionary 777 aircraft she doesn’t say, “I put my heart and soul into this project because it would add 37 cents to our earnings per share.”

If you woke up tomorrow morning with enough money in the bank that you would never need to work again, how could we frame the purpose of this organization such that you would want to continue working anyway? What deeper sense of purpose would motivate you to continue to dedicate your precious creative energies to this company’s efforts?

It’s not what you believe that sets you apart so much as that you believe in something, that you believe in it deeply, that you preserve it over time, and that you bring it to life with consistent alignment.

You cannot “install” new core values or purpose into people. Core values and purpose are not something people “buy in” to. People must already have a predisposition to holding them.

The Hard Thing about Hard Things: Building a Business When There Are No Easy Answers

The Hard Thing about Hard Things: Building a Business When There Are No Easy Answers - Ben Horowitz A must read for any manager, CEO, or founder. This book is a guide to the hard, messy problems in business, such as layoffs, losing deals, and failing companies, instead of the "happy path" in other books. It really makes you appreciate how hard it is to run a company, both strategically and emotionally.


Fun quotes:

Marc: “Do you know the best thing about startups?”
Ben: “What?”
Marc: “You only ever experience two emotions: euphoria and terror. And I find that lack of sleep enhances them both.”

If you're going to eat shit, don't nibble.

One of the most important management lessons for a founder/CEO is totally unintuitive. My single biggest personal improvement as CEO occurred on the day when I stopped being too positive.

Parcells: “Al, I am just not sure how we can win without so many of our best players. What should I do?”
Davis: “Bill, nobody cares, just coach your team.”
That might be the best CEO advice ever. Because, you see, nobody cares. When things go wrong in your company, nobody cares. The media don’t care, your investors don’t care, your board doesn’t care, your employees don’t care, and even your mama doesn’t care.
Nobody cares.
And they are right not to care. A great reason for failing won’t preserve one dollar for your investors, won’t save one employee’s job, or get you one new customer. It especially won’t make you feel one bit better when you shut down your company and declare bankruptcy.

Some things that you want to encourage will be quantifiable, and some will not. If you report on the quantitative goals and ignore the qualitative ones, you won’t get the qualitative goals, which may be the most important ones. Management purely by numbers is sort of like painting by numbers—it’s strictly for amateurs.

As a technology startup, from the day you start until your last breath, you will be in a furious race against time. No technology startup has a long shelf life. Even the best ideas become terrible ideas after a certain age. How would Facebook go if Zuckerberg started it last week?

The first rule of organizational design is that all organizational designs are bad. With any design, you will optimize communication among some parts of the organization at the expense of other parts.

The purpose of process is communication. If there are five people in your company, you don’t need process, because you can just talk to each other. You can hand off tasks with a perfect understanding of what’s expected, you pass important information from one person to another, and you can maintain high-quality transactions with no bureaucratic overhead. With four thousand people, communication becomes more difficult. Ad hoc, point-to-point communication no longer works. You need something more robust—a communication bus or, to use the conventional term for human communication buses, a process.

Tip to aspiring entrepreneurs: If you don’t like choosing between horrible and cataclysmic, don’t become CEO.

Zero to One: Notes on Startups, or How to Build the Future

Zero to One: Notes on Startups, or How to Build the Future - Peter Thiel, Blake Masters This book fluctuates between brilliance and madness. When it focuses on the mechanics of start ups, it's great. When it focuses on Thiel's philosophies, it's a bit whacky. Thiel enjoys being a contrarian too much. Doing something new and valuable may require being a contrarian, but just being contrarian doesn't mean your ideas are new and valuable. Worth reading if you're interested in startups, but be prepared to skim and shake your head.

Pros:

* Great chapters on how to build a monopoly, approach markets, luck, hiring, culture, and sales.

* lots of contrarian views that will force you to reconsider your own ideas

* Interesting outlook on the future of technology and humanity

* Clear writing

Cons:

* The ideas of vertical vs horizontal progress is nonsense. All ideas are horizontal, built incrementally on top of all the ideas that came before by people who came along at the right time and place. This includes the ideas behind paypal and palantir.

* Limited perspective on competition. It exists. It leads to better products for consumers. It hurts some businesses, but drives others to greatness.

* I disagree with Thiel's negative view of education. Yes, higher ed is too expensive and can be done better, but that's not the same as eliminating it. And if you want to change it, then have your companies stop filtering candidates by college degree.

* Dismissing a broad curriculum and saying everyone should study just one thing is absurd coming from a lawyer turned businessman who likes to quote a very wide array of human knowledge, including philosophy, history, physics, mathematics, medicine, economics, and mythology. It's also absurd since the fusion of ideas from different disciplines is what leads to much of innovation.

* Comparing hipsters to the uni bomber? Really?

Fun quotes:

As a good rule of thumb, proprietary technology must be at least 10 times better than its closest substitute in some important dimension to lead to a real monopolistic advantage. Anything less than an order of magnitude better will probably be perceived as a marginal improvement and will be hard to sell, especially in an already crowded market.

By the time a student gets to college, he’s spent a decade curating a bewilderingly diverse résumé to prepare for a completely unknowable future. Come what may, he’s ready—for nothing in particular.

But leanness is a methodology, not a goal. Making small changes to things that already exist might lead you to a local maximum, but it won’t help you find the global maximum. You could build the best version of an app that lets people order toilet paper from their iPhone. But iteration without a bold plan won’t take you from 0 to 1. A company is the strangest place of all for an indefinite optimist: why should you expect your own business to succeed without a plan to make it happen? Darwinism may be a fine theory in other contexts, but in startups, intelligent design works best.

As globalization advances, people perceive the world as one homogeneous, highly competitive marketplace: the world is “flat.” Given that assumption, anyone who might have had the ambition to look for a secret will first ask himself: if it were possible to discover something new, wouldn’t someone from the faceless global talent pool of smarter and more creative people have found it already? This voice of doubt can dissuade people from even starting to look for secrets in a world that seems too big a place for any individual to contribute something unique.

The best entrepreneurs know this: every great business is built around a secret that’s hidden from the outside. A great company is a conspiracy to change the world; when you share your secret, the recipient becomes a fellow conspirator.

Every great company is unique, but there are a few things that every business must get right at the beginning. I stress this so often that friends have teasingly nicknamed it “Thiel’s law”: a startup messed up at its foundation cannot be fixed.

You can’t accomplish anything meaningful by hiring an interior decorator to beautify your office, a “human resources” consultant to fix your policies, or a branding specialist to hone your buzzwords. “Company culture” doesn’t exist apart from the company itself: no company has a culture; every company is a culture. A startup is a team of people on a mission, and a good culture is just what that looks like on the inside.

All salesmen are actors: their priority is persuasion, not sincerity.

The most fundamental reason that even businesspeople underestimate the importance of sales is the systematic effort to hide it at every level of every field in a world secretly driven by it.

It’s better to think of distribution as something essential to the design of your product. If you’ve invented something new but you haven’t invented an effective way to sell it, you have a bad business—no matter how good the product.

Tthe seven questions that every business must answer:

1. The Engineering Question
Can you create breakthrough technology instead of incremental improvements?

2. The Timing Question
Is now the right time to start your particular business?

3. The Monopoly Question
Are you starting with a big share of a small market?

4. The People Question
Do you have the right team?

5. The Distribution Question
Do you have a way to not just create but deliver your product?

6. The Durability Question
Will your market position be defensible 10 and 20 years into the future?

7. The Secret Question
Have you identified a unique opportunity that others don't see?

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence - Pramod J. Sadalage, Martin Fowler This book is a concise and approachable look at relational and NoSql data stores. It does a great job of presenting the the underlying concepts and discussing the trade offs without overwhelming you with too much academic jargon or internet buzz words. I wish I had this intro years ago to save me countless hours of searching the web and trial and error.

Growing Object-Oriented Software, Guided by Tests

Growing Object-Oriented Software, Guided by Tests - Steve Freeman, Nat Pryce A great read for anyone interested in automated testing and TDD.

Pros:

* Makes a strong case for testing: better design, faster feedback, user experience first, regression, and most importantly, the confidence to make changes quickly.
* Includes a nice walk through of an iterative, test driven development process of a small app.
* Lots of great examples of how "listening" to tests leads to better design (ie, what the "driven" really means in TDD).
* I learned a lot from the discussion of how to make tests readable and maintainable.

Cons:

* The book is 100% Java. How do these lessons apply to other OO languages?
* The authors spend too much time selling the jMock framework
* The app they develop iteratively is a Java swing app full of distracting details like the way Swing manages threads. It was a bit boring at times and the code was verbose, so it was easy to lose focus.

Fun quotes:

What if software wasn’t “made,” like we make a paper airplane—finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?

As John Gall wrote in [Gall03], “A complex system that works is invariably found to have evolved from a simple system that works.”

In our work, we apply feedback cycles at every level of development, organizing projects as a system of nested loops ranging from seconds to months, such as: pair programming, unit tests, acceptance tests, daily meetings, iterations, releases, and so on. Each loop exposes the team’s output to empirical feedback so that the team can discover and correct any errors or misconceptions.

One lesson that we’ve learned repeatedly is that nothing forces us to understand a process better than trying to automate it.

Our experience is that, when code is difficult to test, the most likely cause is that our design needs improving. The same structure that makes the code difficult to test now will make it difficult to change in the future.

When composing objects into a new type, we want the new type to exhibit simpler behavior than all of its component parts considered together. The composite object’s API must hide the existence of its component parts and the interactions between them, and expose a simpler abstraction to its peers.

In most systems we build, we end up writing a runtime exception called something like Defect (or perhaps StupidProgrammerMistakeException). We throw this when the code reaches a condition that could only be caused by a programming error, rather than a failure in the runtime environment.

By repeatedly fixing local problems in the code, we find we can explore the design safely, never straying more than a few minutes from working code. Usually this is enough to lead us towards a better design, and we can always backtrack and take another path if it doesn’t work out. One way to think of this is the rock climbing rule of “three-point contact.” Trained climbers only move one limb at a time (a hand or a foot), to minimize the risk of falling off. Each move is minimal and safe, but combining enough of them will get you to the top of the route.

Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter)

Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter) - Steve Krug A nice overview of basic usability principles for building user interfaces. The call for do-it-yourself user testing is extremely important, though ignored or unknown to many companies. The sense of humor is great and the advice is fairly actionable and easy to follow.

The only downside (and hence a 4 star rating) is that the book could use more real world examples. Seeing many more screenshots of websites that do something well, side by side with those that do it poorly--or better yet, examples of incrementally improving a single design based on user testing--would make the lessons much more sticky.


Fun quotes from the book:

It's not rocket surgery.

The actual Average User is kept in a hermetically sealed vault at the International Bureau of Standards in Geneva.

What they actually do most of the time (if we’re lucky) is glance at each new page, scan some of the text, and click on the first link that catches their interest or vaguely resembles the thing they’re looking for. There are almost always large parts of the page that they don’t even look at. We’re thinking “great literature” (or at least “product brochure”), while the user’s reality is much closer to “billboard going by at 60 miles an hour.”

FACT OF LIFE #1: We don’t read pages. We scan them.

If your audience is going to act like you’re designing billboards, then design great billboards.

It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice. —KRUG’S SECOND LAW OF USABILITY

The main thing you need to know about instructions is that no one is going to read them.

I think every Web development team should spend one morning a month doing usability testing. In a morning, you can test three users, then debrief over lunch. That’s it. When you leave the debriefing, the team will have decided what you’re going to fix before the next round of testing, and you’ll be done with testing for the month.

Experts are rarely insulted by something that is clear enough for beginners.

People are just as likely to be using their mobile devices while sitting on the couch at home, and they want (and expect) to be able to do everything. Or at least, everybody wants to do some things, and if you add them all up it amounts to everything.

The Practice of Programming (Addison-Wesley Professional Computing Series)

The Practice of Programming (Addison-Wesley Professional Computing Series) - 'Brian W. Kernighan',  'Rob Pike' The book describes itself as a practical guide to general programming in the real world, but for the most part, doesn't deliver on that promise for a number of reasons.

First, the book should have been called The Practice of Programming in C and C++. The intro chapters say Java, Perl, and others would be discussed, but I'd estimate the C languages make up 90% of the examples and advice. The long discussions of memory management, pointers, and portability do not apply to any of the other languages, or most modern languages in general.

Second, the preface says the book will teach things not covered in school, but the second chapter is a quick, incomplete, and not very rigorous intro to data structures and algorithms straight out of cs 101.

Third, the discussion on coding style is handled much better in other books, such as Code Complete and Clean Code. In fact, I'm not a fan of some of the recommended coding conventions. For example, the book advocates the use of short, abbreviated, and/or single letter variable names in many cases, which made even their short example code hard to read. Also, many of the functions in the code examples were quite long and in need of refactoring.

Fourth, as is often the case with tech content, the book has not aged well. The interface, performance, and portability chapters feel out of date. The fact that functional programming principles (and languages) are missing means this is, at best, a practical guide to purely imperative programming.

Overall: only worth a read for C coders, though a more up to date book would be better.

Peopleware: Productive Projects and Teams

Peopleware: Productive Projects and Teams - Timothy Lister, Tom DeMarco A good read on how to build strong teams and how to be a good manager. Lots of interesting topics, including the role of product quality, methodologies, schedules, productivity, trust, freedom, and office planning.

Some good quotes from the book:

The major problems of our work are not so much technological as sociological in nature.

We Haven't Got Time to Think About This Job, Only to Do It

Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people's backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).

Writing in 1954, the British author C. Northcote Parkinson introduced the notion that work expands to fill the time allocated for it, now known as Parkinson's Law.

Projects [in the Productivity by Estimation Approach study] on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all.

Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals: Count on the best people outperforming the worst by about 10:1. Count on the best performer being about 2.5 times better than the median performer. Count on the half that are better-than-median performers outdoing the other half by more than 2:1.

"Anything you need to quantify can be measured In some way that Is superior to not measuring it at all." Gilb's Law doesn't promise you that measurement will be free or even cheap, and it may not be perfect—just better than nothing.

Your people bring their brains with them every morning. They could put them to work for you at no additional cost if only there were a small measure of peace and quiet in the workplace.

The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window.

The best way we've discovered to do this is through the use of auditions for job candidates. The idea is simple enough. You ask a candidate to prepare a ten- or fifteen-minute presentation on some aspect of past work.

The best organizations are not of a kind; they are more notable for their dissimilarities than for their likenesses. But one thing that they all share is a preoccupation with being the best. It is a constant topic in the corridors, in working meetings, and in bull sessions. The converse of this effect is equally true: In organizations that are not "the best," the topic is rarely or never discussed.

The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology.

The Hawthorne Effect. Loosely stated, it says that people perform better when they're trying something new.

Believing that workers will automatically accept organizational goals is the sign of naive managerial optimism.

In no time at all, we came up with lots of sure-fire ways to inhibit the formation of teams and disrupt project sociology. These measures, taken together, constitute a strategy we dubbed teamicide. Our short list of teamicide techniques is presented below: defensive management; bureaucracy; physical separation; fragmentation of people' s time; quality reduction of the product; phony deadlines; clique control.

The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager's eyes or in your government's eyes) is irrelevant; it's only the right to be wrong that makes you free.

The heading used here is a facetious one; nobody really talks about quality-reduced products. What they talk about is cost-reduced products. But it usually boils down to the same thing. The typical steps we take to deliver a product in less time result in lower quality. Often the product's end user gives willing consent to this trade-off (less quality for earlier, cheaper delivery). But such concessions can be very painful for the developers. Their self-esteem and enjoyment are undermined by the necessity of building a product of clearly lower quality than what they are capable of.

The common thread is that good managers provide frequent easy opportunities for the team to succeed together. The opportunities may be tiny pilot sub-projects, or demonstrations, or simulations, anything that gets the team quickly into the habit of succeeding together.

The fundamental response to change is not logical, but emotional.

This is part of the reason why response to change is so emotional. It is frustrating and embarrassing to abandon approaches and methods you have long since mastered, only to become a novice again.

Most of us today live in places that aren't really communities at all. People don't know their neighbors very well, they commute out to work someplace else, and nobody expects the kids to settle down in the same town.

The Cathedral and the Bazaar

The Cathedral and the Bazaar - Lambert M. Surhone, Susan F. Marseken A terrific discussion of the psychology, mechanics, and economics of open source software. Also includes some nice chapters on hackers. Some bits are dated, but overall, the book largely holds up many years later.

The writing style is occasionally a little rigid or academic, but the content is great. Well worth a read for anyone interested in open source and the future of programming.

As usual, I've saved some of my favorite quotes from the book:


The idea of open source has been pursued, realized, and cherished over those thirty years by a vigorous tribe of partisans native to the Internet. These are the people who proudly call themselves "hackers"—not as the term is now abused by journalists to mean a computer criminal, but in its true and original sense of an enthusiast, an artist, a tinkerer, a problem solver, an expert.

The hacker culture and its successes pose by example some fundamental questions about human motivation, the organization of work, the future of professionalism, and the shape of the firm—and about how all of these things will change and evolve in the information-rich post-scarcity economies of the 21st century and beyond.

Every good work of software starts by scratching a developer's personal itch.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

"Given enough eyeballs, all bugs are shallow." I dub this: "Linus's Law".

Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Consider the way a puddle of water finds a drain, or better yet how ants find food: exploration essentially by diffusion, followed by exploitation mediated by a scalable communication mechanism.

In his [Gerald Weinberg's classic The Psychology of Computer Programming] discussion of "egoless programming", Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere.

Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.

The success of the open-source community sharpens this question considerably, by providing hard evidence that it is often cheaper and more effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.

Once again the example of the open-source community sharpens this question considerably—because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work.

You do not become a hacker by calling yourself a hacker—you become a hacker when other hackers call you a hacker.

The verdict of history seems to be that free-market capitalism is the globally optimal way to cooperate for economic efficiency; perhaps, in a similar way, the reputation-game gift culture is the globally optimal way to cooperate for generating (and checking!) high-quality creative work.

There is a critical difference (Ryan observes) between saying, "I'm giving you this reward because I recognize the value of your work", and "You're getting this reward because you've lived up to my standards." The first does not demotivate; the second does.

Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines.

Open-source peer review is the only scalable method for achieving high reliability and quality.

Sometimes the smartest way to become a bigger frog is to make the pond grow faster. This, of course, is the economic reason technology firms have participated in public standards—and it's useful to think of open-source software as an executable standard.

The brutal truth is this: when your key business processes are executed by opaque blocks of bits that you can't even see inside (let alone modify) you have lost control of your business. You need your supplier more than your supplier needs you—and you will pay, and pay, and pay again for that power imbalance.

Specifically, hackerdom is what anthropologists call a gift culture. You gain status and reputation in it not by dominating other people, nor by being beautiful, nor by having things other people want, but rather by giving things away. Specifically, by giving away your time, your creativity, and the results of your skill.

Refactoring: Improving the Design of Existing Code

Refactoring: Improving the Design of Existing Code - Martin Fowler, Kent Beck, Don Roberts Pros: presenting refactoring as a regular part of the development process is an important step forward. The example at the start of the book is a great demonstration if why this stuff matters. Nice to systematically catalog code smells.

Cons: the code smells section is great, but has no actual code examples. The chapters that go through the refactoring moves are better, but having each one isolated makes it boring to read. The big refactoring chapters are only UML diagrams, which are not good teaching aids. I think walking through a few medium sized examples, as in the first chapter, would've been more effective.

Finally, the exclusive focus on java and OO makes sense, but misses much of the power of functional programming, which removes the need for some types of refactoring entirely. Also, it's a somewhat old version of Java, so the content can feel a little dated.

Overall: an important book to get a sense of refactoring, but the examples leave a lot to be desired.

Good quotes:

With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

It reminds me of a statement Kent Beck often makes about himself, "I'm not a great programmer; I'm just a good programmer with great habits."

A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.

Extreme Programming Explained: Embrace Change (The XP Series)

Extreme Programming Explained: Embrace Change (The XP Series) - Kent Beck, Cynthia Andres If you want to learn the principles of XP, this is THE book. If you want to learn the practice of XP, there are better alternatives.

The ideas and motivation of XP are explained clearly and concisely. It's a short read, but fairly convincing. However, if you learn better from examples, this book does not have enough real world stories to really see XP in action.

The book is full of great quotes:

XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change.

No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a garden

As Will Rogers said, “It ain't what you don't know that gets you in trouble. It's what you know that ain't so.”

If members of a team don't care about each other and what they are doing, XP won't work. If members of a team don't care about a project, nothing can save it.

In software development, “perfect” is a verb, not an adjective.

Quality isn't a purely economic factor. People need to do work they are proud of.

Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.

Put new software into production every night. Any gap between what is on a programmer's desk and what is in production is a risk. A programmer out of sync with the deployed software risks making decisions without getting accurate feedback about those decisions.

Silence is the sound of risk piling up.

He picked a powerful metaphor for his teaching, Scientific Management. When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management?

Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality.

Practices of an Agile Developer: Working in the Real World (Pragmatic Bookshelf)

Practices of an Agile Developer: Working in the Real World (Pragmatic Bookshelf) - Venkat Subramaniam, Andy Hunt The practices in this book are genuinely good and worth thinking about. The presentation format - essentially a long list of advice - could use some work.

Some good quotes:

Agile development uses feedback to make constant adjustments in a highly collaborative environment.

Software development doesn’t happen in a chart, an IDE, or a design tool; it happens in your head.

No plan survives contact with the enemy. - Helmuth von Moltke

As U.S. President Eisenhower said, “The plan is worthless. The planning is essential.”

You can’t freeze requirements any more than you can freeze markets, competition, learning, evolution, or growth.

Beautiful Code: Leading Programmers Explain How They Think

Beautiful Code: Leading Programmers Explain How They Think - Andy Oram, Greg Wilson, Jon Bentley, Brian W. Kernighan, Charles Petzold, Douglas Crockford, Henry S. Warren Jr., Ashish Gulhati, Lincoln Stein, Jim Kent, Jack Dongarra, Poitr Luszczek, Adam Kolawa, Greg Kroah-Hartman, Diomidis Spinellis, Andrew Kuchling, Travis E. Oliph A mixed bag, but overall, worth reading.

Pros: I think programmers do not spend enough time studying the code of others, so books like this are an important step in encouraging the study of this craft. Each chapter of the book is written by a different (often famous) programmer, uses a different language, and discusses a different domain, so you get to see a huge range of different types of code. Multidimensional Iterators in NumPy, Distributed Programming with MapReduce, Beautiful Concurrency, and Writing Programs for the "Book" were my favorite chapters.

Cons: given all the different authors, the quality of the chapters is uneven. A few are boring; a few are interesting, but very tough to follow; a few just discuss high level principles and don't show much code. Also, while I recognize that beauty is subjective, for a prompt of "what's the most beautiful code you've ever seen", a few of the code snippets were questionable.