You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy .

Empty stomach, poor decisions

David wrote this on 10 comments

Entrepreneurial lore is rife with odes to hunger as a foundational necessity of success. Hungry founders are commended as the ones desperate enough to do whatever it takes. Hustle the gullible, bend the law, persevere through endless death marches. Whatever it takes.

But is desperation really the best foundation to build the kind of sustainable and long-term businesses the world benefits from the most? Or, is it rather a cheap trick to juice the odds of a short-term pop to the primary benefit of those who are only ever along for a quick ride?

I believe the latter. That it’s key to a narrative that serves those who extract their riches from the startup mining shafts — venture capitalists.

That’s what really gets to me. Champions of hunger-as-a-badge-of-honor are usually the fattest cats in the land. Extolling the virtue of an empty stomach is unsurprisingly easy when it’s something for others to endure.

And what a rotten virtue in any case. Poor decisions are the natural consequence of an empty stomach. Hunger has a Maslowian way of placing itself on the top of your hierarchy of needs. Whatever focus is gained through the tunnel vision of hunger is quickly overshadowed by the accompanying disregard for all else.

It’s the incarnation of short-term priorities. Primal neural pathways taking over. Fight or flight at every encounter. And not just for the time it takes to get to the first taste of success. Habits formed from hunger, like any other habits, gleefully outlive their founding context, and continue to govern behavior long after it is gone and forgotten.

It need not be this way. It’s not only entirely possible, but vastly preferable, to set off a new venture on a full stomach. Building the new not because of a perceived existential threat if you don’t succeed, but simply because building the new is intrinsically rewarding.

It’s also that much easier to keep your moral compass calibrated and pointed in a sustainable, healthy direction when you can focus on your own thoughts and not a growling stomach. It’s how you build businesses and organizations that aren’t just about fulfilling your own personal and immediate needs, but instead bring about respect – possibly even admiration – from customers, employees, founders, and perhaps even competitors.

Hunger is a stick for nobility to beat peasants into submission. Mistaking its abuse for inspiration is an entirely avoidable travesty. It’s time to pick another source of motivation for starting new businesses.

Finding the voice of The Distance

Wailin Wong
Wailin Wong wrote this on 6 comments

We introduced The Distance podcast in February as a companion to our longform written stories about businesses that have stood the test of time. In just a few months, we’ve learned an incredible amount about creating audio narratives and had a great time doing it—so much so, in fact, that we’ve decided to make the podcast the sole format for The Distance.

By focusing on just one medium, we’ll be able to bring you new stories every other week. Our last written story will run in early July. In the meantime, check out our bonus episode featuring Jason Fried talking to Shaun Hildner about his fascination with all things old and why he started The Distance. We’ll have another new episode next week, and it’s a good one—there are sandwiches involved! So please subscribe via iTunes or the podcast app of your choice. And if you like what you hear, we’d love it if you could rate and review us on iTunes.

The Distance podcast features compact, powerful stories about old-line businesses that you don’t often hear about, like an auto salvage yard with a famously dated TV ad or a floral shop that sells 25,000 roses every Valentine’s Day. The response from readers of The Distance over the last year has been really encouraging, and we’re looking forward to bringing you even more under-the-radar business stories in audio form. Please tune in and let us know what you think!

Hitting our stride with Android

Dan Kim
Dan Kim wrote this on 6 comments

Over the past few months, our newly minted Android team (Jamie, Jay, and myself) has been hard at work on some shiny new Android stuff. And while we can’t share it yet (soon, I promise!), we’ve learned a lot about how to rapidly prototype, explore, and most importantly ship these new ideas within Basecamp.

Like any new team, it took us a bit to find our groove. But in the past eight weeks, we’ve really hit our stride. Now we’re moving quickly and making great progress, without causing ourselves a lot of anxiety or creating undue risk.

So I wanted to share a bit about the strategies that have been working for us. I hope these can help other Android (and even non-Android) product teams out there.

Here’s what we do…

We ship internal builds to the Basecamp team every two weeks.

We scope most of our work into two week cycles of design, programming, and testing (excluding QA). Some of the work might be carryover from a previous cycle (like a design exploration), but the programming is from scratch.

Having two week cycles puts us into a shipping mindset that encourages focus and discipline. Issues can’t linger — we have to make quick (smart) decisions. And we have to be ruthless about cutting scope down to what’s shippable.

Of course some ideas will take longer than two weeks to finish. If we decide to tackle those, there is one criteria: they can’t be exploratory, they need to be well-formed, solid ideas. If something is going to spread out over a few builds, then it has to be worth the investment.

We pick a theme for our build cycles.

Very early on we wrote up 5-6 big themes that we wanted to focus builds around. While these themes changed over time, the idea has stuck and has been an invaluable part of our process.

Every internal build now goes out with a theme that gives everyone a 1-2 sentence idea of what they’re going to get. For example, we might theme a build as “Get to things faster on every screen”. These themes achieve two important things:

  1. It broadly sets the Android team’s development goal — the goal we should measure our work against every few days.
  2. It gives everyone else at Basecamp a nice tl;dr of what to expect. When someone picks up our build, they should be nodding their head in agreement with the theme. If not, then we’ve missed the mark and need re-evaluate what we’ve done.

We kickoff right after our last build ships.

Two weeks isn’t much time to plan, design, program, test, and ship. So right after a build goes out, we spend an hour or so going over our open themes, bugs, and considering where we are in the big picture. Then we pick a theme, assign ourselves work, and get cracking.

The discussion itself is very fluid, and is driven by a variety of factors – technical considerations, overall progress, design ideas, and even logistics like vacation schedules. For example, Jamie is going on his month long sabbatical in July. That was a signal to Jay and I that we should spend as much time as we can now on design executions, and leave architecture and plumbing for July.

We balance low-level programming work (not as much fun) and UI work (more fun) as best we can.

We suffered from this imbalance a bit early on. We spent our first couple builds firming up our foundation and working on our testing tools and suite.

This was all good and necessary, but we started to feel a little stuck. Even though it wasn’t true, it felt like we weren’t making great progress because it was harder to see the fruits of our labor. Perception can be reality, sometimes.

So we started balancing our themes better. We started taking more shots at UI work that felt more rewarding, while never ignoring our foundation.

Over the last few builds, we’ve done a better job of balancing these, and it’s really showing in the quality of our work and the happiness of our team.

We involve our QA team early and often.

The QA team comes in right after we ship. The sooner we have quality eyes on major areas, the better off we are, period. Our QA team does a great job identifying not only bugs, but also big picture UI and product considerations that could impact one of our next cycles. These are often things we don’t notice because we’re too close to the work day to day.

We’re rigorous about shipping.

Even though our self-imposed two week deadlines are arbitrary, we respect them. We close our to-dos, write release notes, and bring in QA. If we’re going to ship, we’re going to ship like we mean it.

We keep our progress visible.

This sounds obvious, but we keep our to-do lists updated and we share heartbeats regularly with everyone at the company. This not only helps manage the day to day, but it helps to communicate a clear picture of what we’ve been up to. Everyone feels free to jump in and give us direction, offer new ideas and advice, and even simply say a few words of encouragement!

We recognize there will be cold streaks.

Sometimes we’ll absolutely fly through stuff, and other times it feels like we can barely type. It happens to everyone. We respect our shipping deadlines, but know that everyone hits a cold streak now and again. We encourage each other to keep at it and to ship as best we can.

We plan for the future a little bit at a time instead of all at once.

We don’t excessively plan, but we do spend 30 minutes here there considering our next few cycles. The idea is to not get distracted from shipping our current build, yet recognize the value of organic conversations and ideas to the bigger picture. It’s important not to lose sight of the end goal, and doing this a little bit at a time helps with that.

There is one important footnote to all of these strategies: the biggest factor for success is the makeup of our entire team. Jamie and Jay are great at what they do. And our designers, programmers, support team, writer, and video producer are all great teachers and listeners — we’re lucky to have them backing us all the time.

Put that all together, and we know we can create something great for our customers. Stay tuned!

The special recipe for DELIGHT

Jonas Downey
Jonas Downey wrote this on 5 comments

Delight is a word interaction designers have been throwing around for the past couple of years. Some people think it’s an overblown buzzword, while others believe it’s a subject worthy of an entire conference.

One part of “designing delight” is about turning otherwise mundane tasks into funny or interesting moments. On the UI side, this might include adding thoughtful animations, cutesy or clever copywriting, and perhaps tossing in a few surprises on top.

These surface-level treatments help make a product seem more human and less computery, which is surely a good thing to do whether you define it as delight or not. At Basecamp, we try to bake this sort of thinking right into our usual design process, rather than calling it out as a specific ideal.

But there’s another, deeper kind of delight. For this post I’ll call it DELIGHT. Here’s an example.

I recently moved my sizable photo library to Google Photos, for a variety of boring reasons: it syncs with Google Drive, storage space is generous, sharing albums is easy, it doesn’t mess with my existing file structure, and searching is miles ahead of competing services. Sure enough, it all works very well — currently besting Apple’s or Dropbox’s offerings.

I was already satisfied, and then Google Photos did something I didn’t expect. When I synced my tens of thousands of photos, the Google Photos “Assistant” bot worked behind the scenes to breathe new life into them, by automatically compiling them into animations, stories, and collages. The stories and collages were roughly what you’d expect a computer to achieve when laying out photos: a fine enough job, but not too mind-blowing.

It was the animation idea that knocked my socks off.

As any parent of a young child (who just WON’T SIT STILL) can tell you, you often need to take 30 photos in a row to get one good one. So we do that a lot. This means our photo libraries are cluttered with countless batches of photos, most of which are basically blurry garbage. Who has the time to go through all of them to find that one perfect gem? Definitely not parents of young children!

Google’s engineers realized this, so they transformed all that garbage into something great.

Now that, right there, is DELIGHT.

Not only did this feature make amazing use of all those junky photos I haven’t looked at in years, it did so automatically. Google Photos just made my entire library much better without my intervention.

This feature has been around for a couple of years, but it doesn’t show off its true power until you backload your 10 years’ worth of stuff. And before now, backloading all your stuff sounded rather unappealing since the Photos feature was deeply intertwined with a big social network.

It took Google a long time to find the special recipe — that perfect combination of features, capabilities, and surprises — to get DELIGHT. To make it happen, they needed to mix cheap storage, tons of processing power, robust file syncing, plus a healthy dose of smart thinking and a willingness to decouple Photos from its social networking parent.

Now, DELIGHT isn’t really about the software itself. Seeing photos of your kid from 3 years ago in a brand new way is sentimental and emotional. It just so happens that the software helped make those emotions happen. I love my kid, not the software, but now I’m certainly more endeared to the software and the people who created it.

This is what product design is about. Finding the special recipe for DELIGHT. Making people badasses by giving them new superpowers they couldn’t have achieved on their own. Everything else along the way — the animations, the copywriting, the tech, etc. — is just supporting material for the main act.

Please allow me to re-introduce myself

Nathan Kontny
Nathan Kontny wrote this on 19 comments

On March 20, 2007, Highrise, Basecamp's simple CRM tool, was launched to the public. Three years later, Highrise for the iPhone was released. Over the years, Highrise has received upgrades and improvements, but it needed a new home and dedicated team to give it the attention it deserved. So, on August 14, 2014, Highrise HQ LLC began – a new company dedicated to Highrise.

At the top of the list of things we wanted to update was the iPhone app. It had been over 4 years since it was released, and it hadn't kept up with changes to iOS. Bugs crept in. Some subtle; some significant. Our plan was to immediately go in and make fixes, but we realized the original iPhone app was built using an iOS framework that wasn't supported any longer, and hence, Apple was no longer approving apps built using that old technology.

We were in a bind. We decided to pull the Highrise iPhone app from the store because of the bugs people were facing (you could still get to the old app from your previous downloads in iTunes), but we couldn't fix anything or offer anything new. On top of that, we had to build a brand new team to support Highrise, get the lay of the land, make improvements to the web app that were sorely needed, and then one day we could get to the iPhone.

Well, I'm thrilled to announce that day is here. We started from scratch. We spent months making sure it satisfied the core needs of Highrise customers. It's been put through its paces with thousands of Beta testers to get it ready.

Highrise 2.0 for the iPhone is now available to everyone on the App Store

It has your Activity Feed, Contacts, Tasks, and Custom Fields. And all sorts of helpful extras. For example, adding a task from anywhere in the app assigns that context to the task (just like it does in the web app). On a contact, add a task, the task is now Re: your contact. On an email, add a task, the task is Re: that specific email.

Or the Current Location help when editing an address, making it a ton easier to add new Contacts when you are mobile.

Or the subtle navigation designs, like how tapping the Activity icon once will return you to where you left off in your Activity, but a second tap will scroll you back to the top:

Or the ability to switch amongst your multiple Highrise accounts:

We have plenty more coming for the app. We know folks want Cases, Deals, Tags, and offline support. And we know Android users want an app too ;) All things on our list. But this is a solid foundation for the future of Highrise on mobile, and so far, people have loved it:

If you enjoy it, we'd greatly appreciate a review on the App Store, and if you have any issues or feedback, there's a handy Help & Feedback button in the app to quickly get someone at Highrise to help.

From all of us at Highrise, thank you very much for your patience as we got this ready, and for the tons of help and feedback we've gotten along the way. We hope you find it as handy as we have. It's the first thing I check in the morning :) Thank you for being part of the new Highrise. We're just getting warmed up.

Download Highrise 2.0 for the iPhone

-Nathan Kontny, CEO Highrise
P.S. The Highrise team is growing. If you know anyone who is great at Software Engineering, and would love to be part of improving Highrise please send them our way!


David wrote this on 7 comments

I’ve been a vocal critic of Android for years. Compared to the glorious polish, consistency, and coherence of Apple’s iOS, Google’s sprawling, inconsistent, and incomplete operating system always felt less. Yes, occasional rays of brilliance, but a sum less of its parts. And to many – although now fewer – extents, I think that’s still true.

But. I’ve come to realize the appeal that lies in figuring out and taming all that sprawl. It invites spelunking in ways that remind me of an earlier age of computing. Hacking consoles, tailoring icon sets, and finding backdoors and alleyways.

It’s a tinkerer’s joy. It’s riddles and puzzles. It’s computing not for the sake of productivity, but as a hobby in its own purpose. It’s the pleasure of making something your own, something unique. A pleasure in part and exactly because it’s not for everyone.

What really got me lured down this path wasn’t just Android in general, though. It was the Moto X in particular. I love this phone. It doesn’t do any specific technical discipline particularly well: The screen is below par (white balance is way too warm), the camera is distinctly mediocre, the battery is so-so. Processor and speed is fine, but nothing wow.

Yet it just feels right in the hand. The last time I recall this feeling was another Motorola phone, the PEBL, back in 2005. It too was nothing special as a technical exercise, but it also just felt great, like the Moto X. Particularly with the wonderful wood back. The 5.2” is perfect. The screen-to-bezel ratio is excellent.

So I keep reaching for the Moto X. Phones have gotten so good that as long as you’re not dependent on things where big leaps are still being made (like the camera), yesteryear’s tech can play second-fiddle to the personal attachment and emotion of the device. That’s a wonderful sign of progress and invitation to diversity.

Anyway, the appeal of the Moto X has sucked me deeper into that sprawling Android land. No, I haven’t given up on iOS. I need to double-carry anyway to deal with two sim cards. But I really appreciate Android culture as distinctly different. Worse in so many obvious ways, and probably for most people, but also alluring and appealing in many other subtle ways.

Some times worse and flawed are just different angles of affection.

The stories we tell ourselves

David wrote this on 7 comments

The progress of technology needs a full spectrum of adoption to work well. From early adopters who jump in before kinks and warts have been banished, to a late majority who bring scale to the now-safe choice.

If we didn’t have any early adopters ironing out the kinks, there’d never be a now-safe choice for the late majority. And if everyone always jumped on the latest thing on day one, society would waste needless cycles churning through the broken glass of beta software.

But usually people see things a little narrower. They’ve picked a group to belong to, and along with it the story that serves it just. I find that a constant and fascinating example of how we’ll all tell ourselves what we need to hear to feel good about our choices.

In most cases, for example, I like to be an early adopter. Take getting the first version of the Macbook Air, while many fretted about and scorned it for too few ports or not enough speed. I accepted the shortcomings by telling myself that this is ultimately The Future, and I want to be among the pioneers that drags us there, even if it’s a bumpy ride across the frontier.

Further, that if everyone wanted to wait until all the bugs were squashed, the bugs would never be found in the first place, and thus never squashed. See, isn’t that a lovely altruistic cover story for what could just as well be labeled as technological ADD, and just wanting the latest thing BECAUSE?

Same deal works on the other end. There are all these great stories available about how you’re being prudent by waiting to take the plunge on a new product, such that you don’t waste money or resources before the inevitable version 2 or 3. A story filled with the virtue of restraint: An ability to resist the draw of SHINY NEW THINGS.

What’s great is that all these stories can be true at the same time, even if they’re individually in conflict. I can even feel good about a chosen story for my current choice, and then swap to the opposite story for my next choice. Self-deception is grand.

A Year of The Distance

Wailin Wong
Wailin Wong wrote this on 1 comment

A year ago, The Distance published its first story: a profile of 110-year-old Horween Leather Co., Chicago’s last remaining tannery. Since then, we’ve visited an 18,000-square-foot costume and wig store and a vintage tiki bar with its own gift shop. We’ve met a custom bra fitter who started her business as a single mom and the second-generation owner of an auto salvage yard that ran the same commercial on local television for 30 years. We launched The Distance because we believe the people behind long-running businesses have amassed a lot of wisdom from their decades of experience. At the heart of each story is the question: “How have you stayed in business for so long?” The answers we’ve collected so far are nuanced and varied, reflecting the complexities that each business owner has faced. Their lessons are difficult to reduce to a list of handy aphorisms. But one year seems as good a time as any to take stock in some way, so here are a few themes that have emerged from the last 12 months.
Take pride in your product: Van Dam Custom Boats makes just two to four of its handcrafted wooden boats each year. Each one takes eight months to two years to finish. As you might imagine, the market for a luxury item of this kind is relatively small, and business took a hit during the latest recession. But the Van Dams took the lull to recommit to their reputation as the maker of the world’s finest wooden boats, no hyperbole intended. They limited production to increase demand and raise their prices, and today they have a waiting list of about three years. Horween Leather has taken a similar approach, focusing on the high end of its market despite pressure in its industry to move toward lower-cost manufacturing. As Nick Horween says in our story, “It just has to be the best you can make it. You put all the best stuff into it so you can get the best of out of it, and get your price or don’t sell it.” Don’t become a commodity: Shrinking margins and slow growth are an ever-present threat in the corrugated box business. That’s why the Eisen brothers, who run Ideal Box Co., have shaped their family-owned manufacturer into a specialist in the corrugated retail displays you see at supermarkets and big-box stores. Scott Eisen says they never want to be a “me-too corrugated company.” Tom Benson of the World’s Largest Laundromat had the same thought about his business. Coin-operated, self-service laundromats can be found on virtually every block of his town, and they tend to look and run the same. The World’s Largest Laundromat does things differently, and the family-friendly amenities it provides has made its store into a destination and community center. Channel your artistic passion in practical ways: Jim Jozwiak of Band For Today was a professional trumpet player with a burgeoning freelance career who discovered a bigger, more lucrative opportunity: providing music education in schools that lacked their own programs. Bruce MacGilpin of The Icon Group was studying sculpture and helping his university manage on-campus art shows when he met a traveling puppeteer who didn’t have a proper storage system for his puppets. MacGilpin built some basic wooden crates lined with packing material for the man, a job that introduced him to the fine arts services industry. Today his business stores and transports priceless works of art for museums, galleries and private collectors. Find new markets and customers: The founder of Hollymatic invented a machine for molding hamburger patties that played a big role in the advent of the American fast food nation. McDonald’s, Burger King and Wendy’s used to be customers. When those chains became mega corporations, they outgrew Hollymatic. Now the maker of meat-processing equipment sells its products to grocery stores, butcher shops and smaller restaurants—ones that, unlike fast food places, make fresh patties. Elsewhere in the world of beloved American foods, Ingrid Kosar was the first to patent the thermal pizza delivery bag in 1983 and signed up companies like Domino’s in the early days of her business. But she didn’t have the market to herself for very long and later lost Domino’s as a customer. Kosar took what she learned about insulating food and started making products for companies outside of the pizza industry, like Meals on Wheels and Panera Bread. Thanks for reading The Distance and listening to our podcast during our first year. Please keep sending feedback and suggestions for businesses to profile to Here’s to another year of stories!

The homescreens of Basecamp (2015)

Jamie wrote this on 8 comments

Back in 2011 and 2013, we shared our phone homescreens with you. We get a kick out of how others personalize their mobile phones. A lot’s changed since then: we have a few more folks on Android, there are 3 varieties of iPhones (6 is the most popular), some of us like having monster phones, and there’s even a Watch among us.

Attention: there are a lot of homescreens in this post. The screens all start to blur together (apart from the Android ones), but they’re all interesting when you take the time to examine them. This is a great article for your lunchtime/afternoon break browsing…



Nathan Kontny
Nathan Kontny wrote this on 1 comment

How do we get better at making things people want?

We strive to better discern the needs of our customers, so we reach for a number of tools. Surveys. User testing. 'Jobs to be done' interviews (an interview process I highly recommend). But in our effort to understand our customers, we often miss sight of something much more basic and integral to those things working well.

The University of Edinburgh Medical School, one of the best medical schools in the United Kingdom, was created in 1726, also making it one of the oldest medical schools in the English speaking world. Given its age, it has quite an interesting group of alumni. Like Joseph Bell.

He was a graduate and professor at the school in the 1800s. Bell had an uncanny ability to determine things about his patients from what seemed to be unrelated and insignificant details. For example, without even talking to the man, Bell determined one patient was a soldier, a non-commissioned officer, and served in Bermuda. How'd achieve such a feat? Bell had observed the patient walking into the room without taking his hat off, as a soldier would. His authoritative posture and age gave him a clue that he was a non-commissioned officer. And the rash on his head? Could only have come from Bermuda.

Joseph Bell's name probably still doesn't sound familiar. But you know his alias – Sherlock Holmes.

Sherlock Holmes wasn't pure fiction. Sir Arthur Conan Doyle, the author of the Sherlock Holmes stories, was also an alumnus of The University of Edinburgh Medical School where he trained as a physician. Sherlock Holmes was an amalgamation of people he'd crossed paths with, especially his medical school professors Joseph Bell and Sir Robert Christison.

Christison was an early forefather of forensic medicine. In 1828, there was a string of murders in Edinburgh, Scotland. Christison helped prove that William Burke and William Hare had been suffocating their victims and then selling the corpses to medical schools.

But Christison was also known for calabar beans. Calabar beans are poisonous, and were used as a justice system in African tribes. They would crush the beans into a milk-like drink for prisoners. Those who died from the drink were "guilty". Those who lived – innocent.

Researchers today find this form of justice might be more accurate than it at first sounds. People who believed in their innocence and the system would probably drink the poison instantly, causing their stomach to immediately vomit and regurgitate the poison, sparing their life. Guilty people, however, believing the drink would kill them, drank slowly trying to elongate their life, but instead dampened their stomach's ability to reject the poison.

Christison knew of the calabar beans' danger, and yet one day, he took a lethal dose and ingested them. Why? Was he trying to kill himself? Was he trying to prove his innocence of something?

If you were anywhere near Facebook or Twitter at the end of February 2015, you've seen this photo. The photo of #thedress was taken by Cecilia Bleasdale, the mother of a bride-to-be, who wanted to show her daughter and bridal party what she'd be wearing at her daughter's wedding.

But they couldn't tell. People split into two camps: you saw blue and black or you saw white and gold. The entire internet broke into debate. I watched friends, designers, photographers, neuroscientists, engineers, even magicians dissecting the photo, trying to explain what we were seeing.

In the end, a representative of the company that makes the dress put an end to the debate: it was blue and black. They don't make a white and gold one. (They probably will, now.) And here's another photo of Cecilia, with the newly married couple:

What I found most interesting about the original photo is the gap it shows between explicit and tacit knowledge.

Explicit knowledge is: "knowledge that can be readily articulated, codified, accessed and verbalized. It can be easily transmitted to others."

The photograph codified what Grace's mom saw that day of her dress, and it was easily sent across the globe to millions of people. But so many of us were wrong about what the information actually described. We saw one thing, and it described another.

Scientist and philosopher, Michael Polanyi, invented the term "tacit knowledge" in 1958. Tacit knowledge is: "knowledge that is difficult to transfer to another person by means of writing it down or verbalizing it." It's knowledge that we can only experience ourselves.

Polanyi would describe riding a bike as an example of tacit knowledge. I couldn't show you how to ride one by teaching you about gravity and centripetal force. I couldn't even give you step by step directions on the mechanics of how the body needs to pedal a bike for you to succeed. Only after you get on that bike and fall, try again, and fall, will you eventually gain the tacit knowledge you need to ride.

We experience this world, but we can't transmit all of it to others. Even the simple stuff, like a photograph of a dress, can be misinterpreted.

Professor Stephen Westland, is an expert in color science at the University of Leeds who the BBC consulted with when writing about #thedress. He explained: "It is possible that people could literally be seeing different colours but it's impossible to know what is in someone's head."

Exactly what Polanyi said about tacit knowledge:

We can know more than we can tell.

After Christison ingested the poisonous beans, he began feeling the symptoms. Paralysis. He started going blind. He began to die.

But Christison grabbed a bowl of water he used to clean his shaving razor and face, and drank it. He immediately began vomiting, which saved himself from the rest of the poison's effects. Christison lived.

Christison wasn't trying to kill himself. He was trying to bridge the gap between explicit and tacit knowledge. As a doctor, all he's given is what a patient tells him, or what he can see. Like the photograph of the dress. But he couldn't read a patient's mind. He couldn't tell if a patient was describing correctly how they feel or the history of what they've gone through.

Christison needed to experience what the actual symptoms were of being poisoned. He needed tacit knowledge to reach his full potential as a physician.

Mike Markkula gave two guys $250,000 to fund a business they were running out of their garage, Apple. But Markkula wasn't just a source of funds. In an interview, Steve Wozniak says Markkula was probably more responsible for the early success of Apple than Wozniak was himself. He chased down more capital. He found the first CEO and become the second CEO when the first left. He was even the one who approved the original plan for the Macintosh.

One of the most interesting contributions Markkula made to Apple was a marketing philosophy that appears to still guide Apple today. Just 3 points he wrote up in 1977:

1) Focus. In order to do a good job of those things that we decide to do, we must eliminate all of the unimportant opportunities.

You especially see this play out in Apple's revival when Jobs returned in 1997. Jobs re-focused the company from dozens of different products and variations (Apple once made printers and game consoles) to just 4 product lines: consumer, pro, desktop and mobile.

2) Impute. People DO judge a book by its cover. We may have the best product, the highest quality, the most useful software etc.; if we present them in a slipshod manner, they will be perceived as slipshod; if we present them in a creative, professional manner, we will impute the desired qualities.

The time and attention Apple spends presenting its products is often unheard of, and the results speak for themselves.

But the point on Markkula's list that I think should draw more attention from people making products is:

3) Empathy. We will truly understand their needs better than any other company.

Markkula chose his words wisely. Just like Christison, he knew that to truly understand a customer's needs better than anyone else, we need to empathize with them – not sympathize. Listening with sympathetic ears to our customers isn't enough. Why? That photo shows us why. People can't communicate everything they experience. Even if they present us with a photo, we easily misinterpret it. And we can't read their minds.

It's of course not always easy. Some things are difficult to mirror. But if we want to be able to gain the deepest insights from the interviews we have with customers, if we want to reach our full potential as a designer, as a listener, as a human being, we need to improve our ability to empathize. This isn't just "dogfooding" our products. We need to share the actual life experiences of our customers and neighbors. It's up to us to poison ourselves.

P.S. You should follow me on Twitter: here for more articles.

Programming with toys and magic should be relished, not scorned

David wrote this on 9 comments

In the early days of Rails, a common dismissal of the framework and its Ruby roots were that these were just toys. Something for kids or amateurs to play with; to build a quick throw-away prototype or system of no consequence. It was most certainly not a tool for professionals building real systems for enterprise, king, or country.

Explicit in this charge against Rails and Ruby laid a grander, sweeping dismissal of toys of all kinds. And more specifically, a rejection of fun and enjoyment as valid reasons for adoption of technology that remains prevalent to this day.

The implication that real professionals do not bother with such childish indulgences. Making Serious Business Software is meant to be a chore. Something to be endured, not relished. An activity worthy of a stiff upper lip, not a smirk.

This charge against childish affection for unserious toys is often expanded to all sorts of wonder, and in particularly magic. In some circles, magic is now downright a dirty word. A label to be applied to anything appealing to greater aspirations than the khaki slacks efficiency of all that oh-so-serious Real Business Software.

But take a step back. Why on earth would we want to associate such joyful memories of learning about the world and its mysteries through toys and magic with that which is beneath us? Even though our goal may well be Serious, why must our approach? Since when is fun, novelty, and exploring the unknown at odds with productivity or value?

A phrase that’s been bothering me for a long time ties all this together: “Use the best tool for the job”. It implies that there is an objective, “best” tool for any programming job. And it leads the search towards those beige horizons of key-point comparisons and feature charts. This does X, Y, Z, thus it must be better than that which only does X and Y. It allows no room for simply preferring A to B on the account that it’s more fun!

Today Ruby and Rails are rarely accused outright of being toys. After more than a decade with roaring, overwhelming success creating an endless stream of “Yup, That’s Serious” business applications, the charge is now obviously preposterous.

But the same charges are still constantly brought against many things new, and as a favorite euphemism for toy goes, “unproven”. If there’s any sense of wonder or unexplained advantage, it readily gets that scornful label of “magic”.

It’s the lingua franca of the incumbents. The manifestations of a rigid minds trying so hard to appear above that childish sense of wonder.

The bottomline: Waging war on toys, magic, and wonder is simply a poor frame of reference. Many of us got into programming exactly because it seemed like magic, like playing with toys. Constructing intricate worlds out of nothing. Legos of logic and rabbit holes of learning.

Love thy toys; love thy magic.