Editor’s Note: Brenden Mulligan is an entrepreneur who created Onesheet, ArtistData, MorningPics, and PhotoPile. He’s an mentor for 500 Startups, Advise.me and several startups. You can find him on Twitter at @bmull and blogging at Starting Up.

There has been a reoccurring theme on my mind recently as I’ve advised startups on areas of focus. It revolves around the goal of reducing friction.

Reduced friction in a product leads to less user frustration, high conversion, and overall user happiness. I’d like to use a few examples to illustrate what I mean.

Taxis / Uber

Let’s start with Uber, the startup that lets you order a black car from your mobile phone in San Francisco, New York, Seattle, Chicago, and a growing list of cities. Because I know the team, I’ve been following this startup since they launched. I actually took an Uber car to celebrate selling my first startup during one of their first weeks in beta.

When I first heard about the service, I focused on the luxury aspect of traveling in a black town car with a private driver. Who wouldn’t? It’s in their tagline (“Everyone’s Private Driver”) and it sounds awesome. But after my first Uber experience, I found out that while nice, the luxury component is strangely unimportant compared to their much bigger function of reducing the friction of getting a ride somewhere.

Let me elaborate. Friction points are italicized.

Here is generally what you need to do to get a cab:

• Find a Car: Stand on the street waving at taxis as they drive by, hoping one stops (this can take a long time in SF), or call for one, which usually takes 15-30 minutes to arrive.
• Set Destination: Tell the driver where you are going.
• Ride: Many taxis aren’t the most peaceful drivers.
• Pay: Take out your wallet and pay with cash (or credit card if they accept it – many don’t).
• Tip: Calculate a tip to add to the fare.

Here is the Uber experience:

• Find a Car: Open app and hit Pick Me Up. The car usually arrives within 10 minutes, sometimes within 5.
• Set Destination: Tell the driver where you are going (although you can set this ahead of time)
• Ride: Almost always a quiet, peaceful experience.
• Pay: Your credit card is charged automatically.
• Tip: Tip is calculated for you and included in fare.

Uber has reduced all the friction. What was a tedious process before is a seamless, pleasurable interaction. The most important thing Uber provides its users is that frictionless experience. The fact that it’s a black car means it’s generally an aesthetically nicer experience (and with SF Taxis, that can make a big difference), but that’s a small detail compared to the other benefits of using the service.

Zipcar / GetAround

A lot of people are familiar with Zipcar. It’s pretty simple. There are a bunch of Zipcar-owned cars around the city that members can rent on an hourly basis. All reservations are done through their website.

GetAround is a new startup taking on Zipcar by altering the model. Instead of GetAround purchasing a lot of inventory (cars), they built a marketplace for car-owners to list their own vehicles for other people to rent. I love the idea, and so do thousands of car owners looking to make money from their unused cars. The company won best startup at TechCrunch Disrupt in NYC and since then has been well funded. I have used the service frequently. I love what they’re doing and think they’re going to build a great company.

However, they face a serious challenge. Zipcar owns its inventory, so they have more control of the friction in the experience:

• Search: Search Zipcar.com
• Reserve: Click on an available car and it’s instantly reserved.
• Get Keys: Unlock with your Zipcar Card
• Find Car: Go to the dedicated Zipcar parking spot
• Drive
• Add Gas: If less than 1/4 tank is left, use provided gas card to fill up tank. Otherwise, just return the car.
• Return Car: Park car in reserved parking space
• Lock and Return Key: Lock with card and walk away

There isn’t really a lot of friction there. Now let’s look at that experience with GetAround:

• Search: Search GetAround.com
• Reserve: Since the cars are personal property, car availability isn’t guaranteed, so this turns to two steps.
• Request several potential rentals.
• Wait to hear from an owner.
• If an owner replies, your booking is reserved. If not, repeat search.
• Get Keys: You can unlock some cars with the mobile app. Most, however, you need to set up a time to exchange the key in person with the owner.
• Find Car: Since GetAround owners don’t necessarily have dedicated parking spots, the car’s location varies, so you need to ask the owner where it is. Sometimes the answer resembles “On 27th between Guerrero and Dolores”.
• Drive
• Add Gas: Before returning every rental, the gas needs to be filled up to where it was at the beginning of the rental, which you pay for. So you need to remember the initial level and try to add just enough gas to return it to that level.
• Return Car: If there’s not a reserved spot, you need to find a place to park it. If this takes longer than expected, you might be late returning it.
• Lock and Return Key: Coordinate with the owner how to return the key and tell them where their car is parked.

Wow. That’s a lot more friction.

Again, I love GetAround, and their team is more aware of these issues than anyone. I’m 100% confident that as they go, they’ll iron this stuff out, just as Zipcar ironed out all the challenges they faced at the beginning. The friction issues GetAround faces are a result of the fact that Zipcar bought cars, while GetAround buys bandwidth. This initial disadvantage will make the company much more nimble and scalable long term.

I think the key to reducing friction quickly is to incentivizing the car owners to reduce the friction points. Give owners the option to guarantee their schedule, so cars can be booked immediately. Push them to install the CarKit, (the device that lets the renter locate and unlock the car from their smartphone). Then, when owners do these things, GetAround should give them a bigger percentage of the rental fee or prioritize those cars in search results. These owner will get more rentals and make more money. Over time, as users choose these cars, other owners will need to add these options to compete in the marketplace, and friction starts to disappear.

Airbnb / Kayak

Even successful startups still work every day on reducing friction. Let’s quickly compare Kayak and Airbnb.

Kayak:

• Search: Search Kayak.com and only available hotels appear.
• Confirmation: You can make a reservation instantly on the hotel website
• Arrival: You go to the front desk, get your key, and go to your room.
• Checkout: You leave your room.

Airbnb:

• Search: Search Airbnb.com and get a list of properties, some available, some booked (since the owners don’t keep their schedules up to date).
• Confirmation: Many times, owner writes back saying the calendar wasn’t updated and you need to search again.
• Arrival: You need to arrange a time to meet to get the key, sign a small contract, etc.
• Checkout: Most of my experiences, you can just leave the key and go.

A lot of times, finding an Airbnb accommodation is a bigger hassle than a booking hotel. But they’ve managed to build a $1 billion company, and continually works to make the process seamless and frictionless. And it’s getting better and better.

So what does all this mean?

Friction is important to consider when creating a product. If your users feel friction using or signing up for your service, you have a problem. Sometimes it’s unavoidable, but you should do everything in your power to remove as much friction as possible. And you should pay attention to this constantly as your product and service grow.

When you examine your product, where are the friction points? Are you letting users sign up with Twitter/Facebook, or do they need to register separately? Are you opening popups to get their attention instead of letting them continue on the site? Are you requiring information you don’t need?

Reduce friction, increase happiness.

Excerpt image courtesy of Ian Hampton

Editor's note: This guest post was written by Len Jordan, who is a venture partner at Madrona Venture Group and currently holds board seats at companies like Cedexis, MaxPoint Interactive, Zapd, Control4, DSIQ, Medio and Wetpaint.

Whenever I invest in a new company, I send the CEO my customary email with advice on how to work with his or her new board. I’ve spent 24 years in the software industry—including holding operating roles at three early-stage software companies and board seats at 12 startups—so I thought my “Top 10″ list on the care and feeding of board members might be helpful to other CEOs and executive as well.

So, without further ado, here it is:

1. Have a plan, and get your entire company and board to understand and support it.

A company’s business plan and strategy is the map of where we are going. The plan almost certainly will change, but the best CEOs keep everyone informed about where we said we are going, where we are currently going, and why we changed plans if we did.

The plan should not be that complicated. Too many business plans use multisyllabic adjectives and adverbs—the plan should be simple even if the products are complicated. The essence of the business plan should be simple enough for a six year-old to read and understand.

We should agree on a plan that describes our target customer; the company's product; and competition. This plan informs the product roadmap (including timeline and hiring requirements, such as how many people you need to build, market and sell the product) and P&L (revenue, expense and net income) broken out by month and quarter and by R&D, sales and marketing and general-and-administrative expenses. The sales and marketing plan goes with this, including a product and pricing model.

The preference is to approve the above and then stay out of the CEO's way—the opportunity
cost of your time is incredibly high.

2. Tell us if the plan changes for "small reasons".

Most plans change for tactical reasons — e.g., the product is earlier/later than expected. Or customers are adopting/buying earlier/later than planned. I like a process in which, if the plan shifts, the CEO pre-emptively throttles the investment/spending without being asked. For example: tell us what level of business progress/metrics (e.g. downloads, installs, usage, trials, bookings, contracts closed, etc.) you want to see to feel good about spending to the plan (or below it if necessary), even if we are not yet certain about exceeding revenue during the current period.

Conversely, what level of progress above plan would make you want to invest more aggressively and what key investments (products, sales and marketing hires) would you make? Having the entire plan and contingencies agreed to ahead of time makes it a lot easier for you to do your job and for us to stay out of the way. Plans don't have to be perfect, and they change, especially at startups.

3. Tell us if the plan is changing a lot for "big reasons".

Sometimes plans need to change for strategic reasons. The best CEOs are continually testing and retesting their basic hypothesis. Is there still a fundamental problem we are solving, or market opportunity we are addressing? Are we still pursuing the right product? Are we selling to the right customers? Are the ways we are selling and marketing right for the market and product? Are we as competitive as we thought? Is our team as good as we had hoped?

Being a CEO is hard because you need to have conviction and commitment to a specific strategy, but you need to continuously challenge the assumptions underpinning it without whipsawing your team, customers and board. The best CEOs stay on-strategy, but are very deliberate when making strategic changes.

4. Strategy mistakes are harder to admit than execution mistakes.

It's hard to admit when a strategy is flawed. It's very easy, on the other hand, to decide that the market, customer and product thesis is correct but sales-and-marketing execution is weak. I've seen too many companies delay making a tough strategy choice by first trying to fix the flaw through a change in execution. If execution is flawed, fix it, but look beneath the veneer to make sure the substance underneath is sound.

5. The average of two strategies is usually not a strategy.

Whether you have a board or not, you have to commit to a cohesive strategy. In tennis you can play at the net or the baseline, and both can be great strategies, depending on the circumstances. The average of the two — playing in the middle of the court (commonly referred to as 'no- man's-land') — is the worst place to play and is never a good strategy. Too many startups split the difference: They continue with the old strategy, add a new strategy (like a new product), under-resource both and fail at each.

Good strategy starts this way: Assess the company's essential attributes—market, team, product, customers, competition–and develop a simple one page SWOT (strengths, weaknesses, opportunities and threats) analysis. Frame alternatives, discuss tradeoffs with the board and make hard choices. The classic startup mistakes often consist of giving up on the right strategy too early, choosing the wrong new strategy, assuming the old strategy provides more benefit to the new strategy than it does or choosing, instead, to focus on both an old and new strategy out of fear of making the wrong choice. It is scary to have both feet and hands off the rock at the same time.

6. Email is good for delivering straightforward information; board meetings are good for explaining complicated information and discussing alternatives.

I love short (above the fold) weekly email updates from CEOs on key progress points (product development, hiring, revenue, key partnerships, etc.), but it's OK if they are less frequent (coming every other week, or once a month). But bad news should travel fast—this includes losing a key customer, a key engineer quitting, etc. The road has bumps; I'd rather know about it when it happens than after it leads to some other issue (like a product delay or a revenue miss). Also, I'd prefer that problems/opportunities not only get communicated, but that options be developed to address the problem or opportunity. Frame the situation and assess the pros and cons of a few choices—it makes it easier to help come up with a reasonable solution.

7. Board meetings are not pitches. You have our money, so let's figure out what to do with
it.

The best way to earn trust from your board is not to tell us what's going well; it's to tell us what's not going well. Better yet, make everything run well but tell us the things you want to focus on that could become problems if not addressed. If you do #6 , the board meetings can be less about updating the board and more about discussing key strategic choices/decisions and ways we can better tune our execution. A basic review of financials, customer progress, product development, partnerships, hiring, etc. would be great, but we'd also like you to expose key strategy elements (SWOT) and get us to discuss and react.

Receiving board decks two days ahead of time means we can add more value in the board meeting. Also: The best companies can get the board deck down to 10-15 slides, max, especially if #6 is happening. Allocate time for strategic topics at key board meetings and from time to time, invite an outside/expert that can challenge the group at key strategic inflection points. Finally, as with any meeting, don't unveil controversial topics at board meetings for the first time. Give people a heads up ahead of time so they discuss the topic at an average blood pressure.

8. Ask for help — we work for you. Really.

We like helping recruit employees and partners (customers). Put us to work, let us brag about you to potential employees and provide context and support. We can assist with strategy questions. You should know more about the business than we do, but our distance can provide perspective. And perhaps we have seen patterns that can be applied from other experiences. This can be incredibly valuable as long as we don't over or mis-apply the patterns in the wrong instances based on the wrong attributes.

We are OK if you seldom call and are also OK if you call every day when we are working on something that requires it. We do appreciate just getting a check-in call from time to time. A little like calling your mom in college, sort of. If you only call to ask for money she will know something is up.

9. Involve your exec team with the board.

It's good practice to have at least one board member interview all exec hires; different perspectives can be good. Having the exec team in the board meetings can be great, especially if they present the area of their responsibility (product development, sales, marketing, finance). That said, it's also important to have a closed session of the board that is just the board plus counsel, to discuss board-only matters.

10. Tell us how we are doing.

We hope to add value but will make mistakes and can often manage things better. Tell us about these areas and we will try to get better. We will do the same with you. And tell us when we should stay out of the way — you run the company, and sometimes the best thing we can do to help is let you do that.

The average early stage company takes nine to 10 years before it will exit. So we likely are going to work together a long time. Let's make it productive, rewarding and fun.

Facebook has filed for a trademark on the usage of “Facebook” on business cards and, more curiously, “non-magnetically encoded” ID cards among other things. If granted the trademark would protect using the word Facebook in the specified formats, not any actual invention.

So what if Facebook just wants to stop people from making fake Facebook business cards? Well, it seems like this trademark would cover that and a whole lot more including “business card and identity card design services,” “printing services” and the ominous, “facilitating social and business networking through the provision of data for use on its own business and identity cards.”

It also looks like the trademark would cover QR code and NFC/RFID uses — which work through magnetic induction, NOT the aforementioned magnetic encoding —  much like the Presence cards and photobooths that allowed you to upload and tag photos at F8 (see left).

It’s easy to envision some sort of master Facebook plan where Facebook would give users a cheap physical ID that could be read by smart readers and used for a variety of practical purposes. When asked, people familiar with the Facebook matter had no clue as to whether this was actually in the works. It’s also unclear how often companies like Facebook trademark something and then don't actually take advantage of the trademark.

If Facebook were to develop some sort of physical ID system, it would be great for marketing and extremely practical; Imagine going to concerts or movies, buying tickets through Facebook and swiping through a key fob ID card.

So will Facebook play a larger role in how we manage in our offline identity in the future? Well the idea is not so far-fetched — After all, Facebook is already most dominant identity system on the Internet.

Image via: Gsharma

If the iPhone 4S has one standout feature, it is the Siri personal assistant. You ask Siri to do things by speaking to it, and it can call anyone in your contact list, send them a text message or email, set up a meeting, play a song, set up a reminder for yourself, get directions, or just ask a question. It is a conversation starter in more ways than one. Siri is the kind of feature that makes you want to whip out your phone to show a friend or a total stranger.

John Biggs and I covered Siri in yesterday’s Fly or Die episode on the iPhone 4S, but I taped this extra video to go into more depth. It’s just better to see Siri in action that to read about it. Siri isn’t perfect. Sometimes it runs into network issues, picks up background noise, or gets the wrong question because your instinct is to start talking before it is ready. But it is the most impressive voice-computer interface out there right now.

In the demo above, I set up a reminder to pick up some flowers for my wife (a notification later popped up on my phone at the appointed time), dictate a note, find a park nearby on a map, and set up a meeting with Biggs. When you set up a meeting, Siri both sends an email to the other person and puts it on your calendar. I find that particularly impressive because this is a case where talking to Siri takes so much less time than doing those actions myself.

Seth Sternberg is the CEO and Co-founder of Meebo. He writes this guest column, In The Ring, from a CEO’s perspective.

When you decide you're going to start, or run, a startup, you're signing up for problems. Lots of problems. They're everywhere. New competitors. A key employee leaving. You didn't hit your numbers. A market shift rendering your service useless in a year or two.

When you first start, they're almost fun. "Oh, how am I gonna solve that one?" Or better yet, "All these VCs want to get into my deal!" Of course, they also have the tendency to seem existential. You don't have much at the beginning, so the good feels like it can make you—"We just landed an awesome partnership. We just became millionaires!"—and the bad feels like it can destroy you—"Holy shit, Facebook's launching what?? We're dead."

As you scale, more problems seem to crop up—hourly. A system that was working super well, like how your engineers choose projects, may all of the sudden break once you tip past 12 engineers. Who knew it'd happen then? It did, and it felt like it happened out of the blue. Before you know it, your engineers are feeling unmotivated, the system seems broken, and it's no longer fun

For the CEO, this can get overwhelming fast. If you have a great team, most problems get solved before you ever hear about them. But there are enough big problems that you will hear about, at least one a day. And it's not the easy problems that make it your way. Those already got solved. Rather, they're the hardest problems that people bring to your attention. Day after day. That, my friends, can be tiring.

Have you caught the setup yet? The huge, massive, you could lose your job kind of risk lurking in this story yet? It's all too easy to become the CEO who telegraphs "don't bring me every damn problem—you're smart—solve your own problems. That's why I hired you!" This, in fact, can seem particularly effective. Adopt this position and problems will apparently take care of themselves…until all those lurking problems that never made it to you, for fear of you not wanting to hear them, result in a declining company. Buh-bye.

So what to do? First, obviously, resist the temptation to become that CEO who no one wants to tell what's really going on. Just don't be that guy or gal. That means you need to listen to the problems that come your way and, as much as you can, play traffic director. Help them figure out who to work with to solve their problems. It's incredibly empowering if you can help others learn how to solve their problems, rather than solving the problems for them.

Second, it's all about education. You need to teach people how to identify and solve problems when they're nascent, rather than letting them fester and become a big deal. Catching problems early (eg: our system for deciding what engineers work on broke) often keeps larger problems from ever occurring (eg: our star engineer wants to leave). Teaching this, it turns out, is surprisingly complex

Once I began to realize that I needed to actively talk to the folks at Meebo about identifying and solving problems, I thought it would clearly be enough to say, "Guys, don't let problems fester. If you notice a problem, fix it or bring it to someone who can!" It wasn't—somehow problems still festered without being solved. So I began to telegraph the process of solving a problem.

1. Identify that a problem exists.

2. Identify the cause of the problem.

3. Hypothesize a solution.

4. Implement the solution.

Thinking about problems in a structured way, such as this, turned out to help my own thinking on problem solving. In fact, it led to two pretty interesting discoveries: a) people often don't realize they're facing a problem. Rather, they just feel frustration. b) problem solving, and particularly the ability to shepherd a problem through the four stages listed above, is highly correlated with seniority.

It turns out that many folks, particularly junior folks, don't realize when they've run into a solvable problem. Rather, they'll tend to just feel frustration. I've had this same thing happen to me. You know that feeling you get in your gut when something doesn't feel right? It bums you out, but you can't quite put your finger on it. That's it. There's a problem, but you haven't yet consciously realized it. Thus, junior folks are particularly susceptible to becoming frustrated, confiding in their peers about their frustration, and not beginning the process of solving the problem. You tend to see it manifest in the form of complaints, rants, and general lack of motivation. Things then snowball.

This is where education comes in. Teaching folks to realize they're frustrated and that that's a sign they need to think about why they're frustrated is the first step in ensuring that problems get caught and solved early. As long as the problem gets identified (step 1), if that person can't get to step 2 on their own, at least they can bring it to someone who can.

I'm not certain why seniority and problem solving capability are correlated. It's tempting to chalk it up to experience, but it's more likely information or influence asymmetry—more senior folks are more likely to know who can help them solve a problem, where the cause may be coming from within the organization, and certainly are more likely to have the influence to help implement a solution. That is, it's likely less tied to experience and more tied to information flow, which is often tied to place within a given hierarchy. This is why information transparency within an organization is so crucial (topic for a future post). But knowing this relationship exists can help you both empower your more junior folks, and ensure that your more senior folks understand how important it is to help the folks they manage identify and solve problems with them before they mushroom.

The other half of this is, once the problem is identified, being transparent about solving the problem. It's an equal partnership between you and your employees. It's too easy to disappear into the management black box, secure in the knowledge that you're working to solve the problem, but leaving everyone else hanging. To instill a sense of trust and empowerment, establishing a pattern of good, collaborative problem solving can be the difference between a motivated team working with you to solve problems and a dysfunctional organization.

Net: don't run from your problems, but do everything you can to empower your people to solve them early and often.

The Gillmor Gang — Robert Scoble, Gabe Rivera, John Taschek, Kevin Marks, and Steve Gillmor — marked a watershed moment in the history of realtime. When @gaberivera posted a summary Tweet rolling up the WSJ-induced VC semi-panic, he bookmarked a discussion that started and largely finished not in the blogosphere but on Twitter.

By the time the swarm slowed down, it was decorated by numerous blog posts including one from the Dean of the Fully Disclosed, Fred Wilson. We’ll look back on this thread as the moment when 140 characters provided the Vitamin B12 shot that jumpstarted the move toward prioritization of the Push Notification window.

@stevegillmor, @gaberivera, @scobleizer, @jtaschek, @kevinmarks

As we noted earlier this week, one of the founding fathers of UNIX and the creator of C, Dennis Ritchie, passed away last weekend. While I feel that many in computer science and related fields knew of Ritchie’s importance to the growth and development of, well, everything to do with computing, I think it’s valuable to look back at his accomplishments and place him high in the CS pantheon already populated by Lovelace, Turing, and (although this crowing will be controversial, at least until history has its say) the recently-departed Steve Jobs.

UNIX was one of the first multi-user operating systems, allowing scientists and researchers to share computer time on what were traditionally batch-based machines. The concept of multi-user and multitasking were of great interest to researchers simply because of the time required to write, run, and receive the output of batch programs. Computer time, in batch mode, was expensive, as this anecdote illustrates:

While mulling over the problems of operating systems in 1969, [Ken] Thompson [the co-creator of Unix] in his spare time developed a computer game called “Space Travel.” The game simulated the motion of the planets in the solar system. A player could cruise between the planets, enjoy the scenery, and even land the ship on the planets and moons.

The game, first written on Multics and then transliterated into Fortran for the GECOS operating system, ran on a GE 635 computer. The game’s display was jerky and hard to control because the player had to type commands to control the ship. Also, it cost about $75 in CPU time on the big GE 635, a cost that hardly endeared it to management.

At $75 a game, especially in 1960s dollars, it was hard for a hacker to have any fun. Dennis Ritchie and Thompson worked together to build UNIX as a hacker’s paradise, a place to test small programs and share the results. He was a physicist and mathematician by training but entered the nascent world of mainframe and micro-computing at just the right time. The 1960s and 1970s were a time of great change in the way computing interacted with the world. Whereas the the common view was that “These darn computers are going to mess up my phone bill,” in reality computers were messing up the status quo. In a few short years paper records were slowly eroded by computation, telephone switches were changing from wild, steampunk octopi into a quasi-mechanical system of routers and terminals. Bell Labs was at the forefront of it all, tasked with connecting the world through copper wire. Most important, what he was doing was difficult, something we forget in the days of drag-and-drop, autocompleting IDEs.

The key to UNIX was the concept of sharing. The OS was begin in 1969 as a reaction to Bell Labs shutting down Thompson and Ritchie’s favorite operating system, Multics. With the cooperation of multiple organizations including MIT, a group of four New Jersey Bell Labs programmers began working on a neglected PDP-7 machine where they ported the Space Travel game and began to build out a file system in order to save games. Slowly, a command structure that anyone familiar with modern Linux would understand accreted around this file system. Slowly word of UNIX trickled out of the small cabal of original users and in 1971 the Bell Labs patent filing office began using it to format documents for printing using nroff.

It is also important to note that Linus Torvalds was born in 1969, making him a prime candidate to reap the benefits of what you could term the UNIX Age. To come of age in the tumult of a new industry is important and Gates, Torvalds, and Ritchie all were excellent examples of this.

Ritchie went on to create a number of other improvements and, in the development of the C operating system, gave the world its first multi-machine, cross-compatible coding standard that anyone, from a grizzled machine language veteran to a young student in Helsinki, could use and understand. The UNIX source code was passed from programmer to programmer like holy writ even after AT&T refused to make it available to education institutions. It was written in C with some of its core components written in machine language in order to shave off time, cycles, and most important, to retain an elegance that Ritchie and Thompson inculcated through cross-pollination of ideas. No one man, not even Ritchie, understood the complexity of the beast that became UNIX and that was by design. The goal was simplicity up front and complexity in the back, a model that everyone in computing would do well to emulate.

Also important was the desire to reach a golden ideal in clarity and elegance. "Peer pressure and simple pride in workmanship caused gobs of code to be rewritten or discarded as better or more basic ideas emerged,” wrote Doug McIlroy, a member of the UNIX team. “Professional rivalry and protection of turf were practically unknown: so many good things were happening that nobody needed to be proprietary about innovations".

The question is, then what can we learn about building our own products from this giant of computing? First, Ritchie and Thompson wanted to have fun. There was no initial push to make money and, in fact, their goal was to save money or at least hide their gaming by moving it to a less costly machine.

The second is the necessity to work outside your comfort zone. Ritchie was a physicist and a mathematician. However, he became a programmer. While it’s clear that his background helped him immensely in building UNIX and C, as Bjarne Stroustrup noted, Ritchie was not afraid to attempt to work in new and unfamiliar territory. "If Dennis had decided to spend that decade on esoteric math, Unix would have been stillborn," he writes.

Third is the importance of a hands-off approach to innovation. Ritchie was lucky in that Bell Labs had the money and staff to allow him to hide in the shadows with his friends, creating what they wanted on their own timeline. Google seems to have captured that same sense of internal experimentation obviously with their 20% projects as well as their Labs products that slowly metamorphose into mainstream tools. That the Google founders allowed these 20% projects almost immediately after inception of the company is a testament to Thompson and Ritchie’s methodology. People build mean tools when the foreman is watching and masterpieces when left to their own devices.

Finally, we have the importance of sharing. It amuses me to no end to see a small start-up cloak their product behind NDAs and secrecy or to watch entrepreneurs mistake glad-handing with networking. When this happens, it’s clear that their idea is not novel nor will it be particularly successful nor is their attitude particularly conducive to growth. I would argue that many current, successful entrepreneurs aren’t successful because they talk a good game but because they play one.

Arguably the most important software project in the world today, Linux, is important because it gloriously available and open. There are those who will crow that open is not synonymous with profitable, but those people are at best pessimists and at worst fools.

In the end Dennis Ritchie taught us that computing wasn’t a secret society, one that required long years of service and special incantations to join. His intellectual largesse is writ large over everything we do online and his still as an explainer – although notoriously shy – shone in his voluminous commentary and online notes. Although none of us can attain what he and the Bell/AT&T team attained, especially considering their milieu and the relative nascence of the information age, we’re reminded that this doesn’t matter. After all, as we learned from the UNIX source code all those years ago:

* You are not expected to understand this.

You simply have to build on it.

Img via Wikipedia