The Well-Bred Grapefruit

Musings on Software Development

Enough About Columbus, Let’s Talk About Eggs

In the US, at least, today is Columbus Day. A minor federal holiday, to be sure, and one that sees a lot of justifiable opposition these days. But that’s not what I want to talk about. I’d like to talk about something that never happened to Columbus, but which is often attributed to him anyway (as most noble stories you hear about Columbus are).

The apocryphal story, excised here from Wikipedia, is often referred to as “The Egg of Columbus:”

Columbus was dining with many Spanish nobles when one of them said: ‘Sir Christopher, even if your lordship had not discovered the Indies, there would have been, here in Spain, which is a country abundant with great men knowledgeable in cosmography and literature, one who would have started a similar adventure with the same result.’ Columbus did not respond to these words but asked for a whole egg to be brought to him. He placed it on the table and said: ‘My lords, I will lay a wager with any of you that you are unable to make this egg stand on its end like I will do without any kind of help or aid.’ They all tried without success and when the egg returned to Columbus, he tapped it gently on the table breaking it slightly and, with this, the egg stood on its end. All those present were confounded and understood what he meant: that once the feat has been done, anyone knows how to do it.

Columbus Breaking the Egg, by William
Hogarth

I imagine anyone with experience working in software, engineering, architecture, mathematics, or any other industry rooted at heart in solving problems understands the moral of this story. Obvious solutions are often only obvious after the fact, so we need to be careful about dismissing problems as trivial without understanding what went into solving them first.

That said, there’s another lesson to this story that I think is even more important – elegant solutions seem obvious after the fact; before the fact, they seem inconceivable.

Often when discussing a hard problem with folks, I picture what those fabled Spanish nobles might have said as they fussed over Columbus’s egg.

“It can’t be done,” one might have said, “unless you first build a device for stabilizing it.”

“It can be done,” says the noble who just returned from his trip to China, “but only when the moon is right.”

“You have to find the right spot on the table,” says another, “so that the natural patterns in the wood will support the egg.”

“I think you’re right, but this table doesn’t seem to have the right grain.”

“Maybe if we went to the Italian’s shop next door? His counter is made of the most interesting olivewood…”

…and so on. Again, this is a conversation that I imagine most of us find familar, in structure if not content. Given a difficult problem to solve, the nobles assumed that there couldn’t be a simple solution and resorted instead to trying shortcuts (building a device), changing the characteristics of the problem to suit their biases (waiting for the moon to be in phase), or going off down the rabbit trail of an overly complicated solution (like finding the right table on which to balance the egg).

This is the more important lesson to learn from our fictional version of Columbus – that a hard problem doesn’t have an obvious solution doesn’t mean that there isn’t a simple solution. When you’re confronted with such a problem, try to resist the temptation to cheat, change the rules, or over-complicate the problem; if you do, you’ll be better able to recognize how to balance the egg.

Church Signs and Context

I’ve lived my entire life in the “Bible Belt” of the United States. This swath of the deep south gets its name from the fact that we have more churches than we do grocery stores. These churches often have a reader board out front, and the church staff attempt to generate interest in the church by posting witty or humorous statements:

Two church signs with humorous sayings

Which is fine, right? I don’t want to disparage these churches for attempting to market themselves, and if nothing else they might entertain some folks on their daily commute.

To make them readable from the road, these signs only have so much space for a message, which means that those responsible for the signs have to be as concise as possible with their message. This leads to clever quips like “Son screen prevents sin burn,” “You catch ‘em, He cleans ‘em,” and “God wants you to be an organ donor, give Him your heart.” These messages are short and catchy, and are designed to stick with you and color your thinking. The problem shows up when you realize that these messages, as clever and catchy as they are, gloss over some nuanced theological topics like salvation and justification. These satisfactory chunks of prose often prevent people from digging deeper and thinking about the context surrounding these complicated ideas.

But this isn’t a theology blog, it’s a software development blog. So where am I going with this?

The business world (and, to a somewhat lesser extent, the software development world) is rife with these church sign sayings. Just like the pastors at those churches, business and process pundits understand that catchy sayings and short lists sell… and people eat it up. We’re surrounded by the platitudes and bromides of our industry that ignore the nuance and complexity of what it is we’re trying to do.

One great example is the following quote, attributed to Henry Ford:

If I’d asked my customers what they wanted, they’d have said a faster horse.

The central message here is that customers don’t know what they want. You hear this a lot in technical industries because it defends the idea that I, as a technologically savvy engineer, know the needs of my illiterate customer base better than they do. Why should I pay attention to what my customers are saying when they’re so woefully behind the times?

Setting aside whether Ford even said it in the first place, this quote sidesteps a lot of the complexity involved in attempting to understand your market, even in Ford’s case (he may not have given his customers literally what they would’ve wanted – a faster horse – but he did understand his market well enough to know that they wanted a faster, affordable mode of transportation).

Sometimes these church sign sayings appear as factoids rather than quotes. How many of us have heard the following idea:

It takes the average person 40 minutes to get back to work when they’re interrupted.

The exact time seems to change based on who you ask, but this is a favorite saying among the “meetings are evil” crowd. If we’ve accepted that interruptions have a huge negative impact on productivity, then shouldn’t we cut interruptions as much as possible? Doesn’t that mean that any meeting is a bad meeting, since it interrupts everyone involved?

Well, maybe. What if this meeting could save you days of effort? What if the interruptions/inefficiencies of dealing with this conversation in an email thread instead of face-to-face are more disruptive than the meeting would have been? There’s a lot of context around any given meeting, and using the catchy factoid as a method of dismissing all that context means that you often don’t make an informed decision.

These church sign sayings oversimplify your message and encourage people to ignore the deeper context of the problems they’re wrestling with. Next time you have the urge to throw aphorisms around in a business discussion – regardless of how clever they make you feel or how much you agree with them – step back and think about whether you’d be helping your team deal with an issue, or if you’d just be oversimplifying a hard problem.

Do You Write Code, or Are You a Developer?

Depending on who you ask, I’m decent in the kitchen. I know a lot of the basic techniques – I can mince herbs, caramelize onions, toast nuts, and dice vegetables to various sizes. I have (and understand how to use) tools from a garlic press to a food processor to copper-clad pans. I have Pink Himalayan Sea Salt in my pantry. I have at my disposal recipes for foods ranging from ice creams and pies to chilis and stews to beef wellington and black pudding.

Does that make me a chef?

Software development is a very lucrative field right now, so it’s no surprise that people are trying to figure out what they need to do in order to succeed. As a result, “How to be a Great Programmer” is a pretty popular topic for blog posts and online advice columns. And to be fair, there tend to be a lot of good ideas in these posts. Name your variables well. Write tests. Learn architecture patterns. While these are good ideas, though, they all boil down to one thing: “write good code.”

Does that make you a software developer?

I may have some technical proficiency with cooking; I have tools and ingredients and I know some nice recipes. But being a chef is a lot more than that. Chefs have to be able to create, to be inventive with their medium – nobody wants to eat at your restaurant if the food you’re cooking isn’t different. They have to be able to adjust – the soup came out too salty, or the stew’s too bitter, or the seasoning on the meat just doesn’t seem right – a good chef can figure out how to salvage these mistakes, where someone like me without that experience might just shrug and attribute it to the quality of the recipe. Chefs can step outside of any one dish and think about the meal as a whole – after all, it doesn’t matter how well-prepared the fish is if it’s overpowered by the sides.

Someone who has the tools and the techniques; someone who can follow a recipe competently and adhere to the basic rules of the kitchen, they can most certainly cook. But in order to become a chef, they have to do more – they have to master the tools and the techniques, for sure, and along the way they learn hundreds of recipes, but they also develop a capacity to go off-course. They learn to break the rules when it makes sense, and how to tweak recipes to suit their needs, and invent new tools and techniques when the old ones aren’t sufficient. At heart, chefs aren’t people who prepare food – they’re people who solve problems with food (although admittedly the primary problem is satisfying the demands of their restaurant). That extra layer is what separates people who can cook from people who lead successful lives as professional chefs.

The same applies to being a software developer. You can have the tools necessary to write code; you can learn some of the rules and guidelines; you can practice with the frameworks and follow tutorials. But to really be a software developer, you have to go beyond writing code. You have to be able to be inventive and willing to break the rules when they don’t make sense. You have to be able to deviate from what you’ve done before in order to deal with an issue. You have to understand that software developers aren’t people who write code – they’re people that use code to solve problems. Much like the layer that separates chefs from “people who can cook,” this extra dimension differentiates people who can code from people who are successful as software developers.

So if you want to learn to write good code, practice with your tools. Learn the latest frameworks and languages. Follow the tutorials and learn some programming recipes.

But if you want to be a good developer, learn to solve problems. If you encounter something you think is impossible, try to prove yourself wrong. When you don’t know how to solve a problem, don’t give up; dig deeper. Try to write code that solves other people’s problems, and practice turning their ill-defined requirements (and, trust me, they will be ill-defined) into well-defined code. Of course you’ll want to learn all the techniques and tools as well, because good software developers write good code – just don’t think it ends there.

The Stoichiometry of Software Projects

The Project Management Triangle

The Project Management Triangle in Venn Diagram Form

There’s a popular concept in the world of software development: “good, fast, cheap: pick any two.” Often visualized as a triangle, this model conveys the inherent tradeoffs in working on complex projects:

  • You can be fast and cheap, but it won’t be high quality.
  • You can be cheap and high quality, but it won’t be fast.
  • You can be fast and high quality, but it won’t be cheap.

How We Hire Developers at Treehouse

I’m pretty happy with the hiring process at Treehouse. Over the course of my career, I’ve been through (and conducted) interviews that ranged from borderline inane (“Why are manhole covers round?”) to pretty intense (“Here are some coding problems. You have 10 hours. Begin.”). I’ve filtered through resumes and listened to coworkers explain why they thought this particular candidate would be a bad fit “because he doesn’t seem to understand enough about how diesel engines work.”

Hiring developers at Treehouse is pretty painless, though – in part because we we’ve been careful to build a solid team, but also because we take a lot of care to cut to the BS out of the interview process.

Daily Meetings Are Great but You Should Never Have Them

A staple of the “startup industry” is the daily standup meeting. The idea is simple and the theory is effective: let’s take time to make sure everyone is up to speed on what everyone else is doing, and that management is in the know about any potential problems. Typically these meetings follow a certain format:

  • What got accomplished yesterday?
  • What are you expecting to accomplish today?
  • What problems are you (or your team) experiencing?

This is great information to share, because it keeps everyone well-informed and provides a regular opportunity to share issues that management can fix or that someone else on the team can provide a solution. Making this information share part of the normal daily routine helps keep things moving.

Sounds great, right? Everybody should be doing this. Why do I say that you should never have them, then?

Because it’s the information that’s great: the meetings are time-sinks.

Manage Up and Down, but Not Sideways

I’ve officially been managing the development team at Treehouse since last December or so, which puts me near my six-month mark here in May. During that time, I’ve been trying to come up with a good management style: I’ve been exposed to a lot of different management techniques and attitudes, ranging from deplorable, to annoying-but-useful, to fantastic over the course of my career thus far. Now that management is a key component of my day-to-day responsibilities, it’s important for me to have a good management philosophy in much the same way as it’s important to have a good coding philosophy: thinking through a lot of this stuff up front will help me to be more consistent and decisive when I’m faced with an issue.

Take Time to Be Awesome

Don't forget to be
awesome

At Treehouse, we have 6 developers in a team of 50+ people. I’m told that’s unusual for a web-based startup, and that typically the company’s staff (and hence direction) is dominated by a team of developers.

There’s good reason for this difference – at heart we’re a content production company, so that has to be our focus. The development team at Treehouse is really there to support that goal. We don’t get to set the priorities for what gets worked on and what doesn’t, but we’re all ok with that.

Pow, ZSH, and Rbenv

I just spent the better part of an hour trying to figure this out, so I thought I’d share.

Pow, ZSH, and rbenv are all great tools in their own right, but they really don’t want to play well together. Despite all my attempts to the contrary, pow refused to recognize my rbenv setup and tried to load up my Rails application using the system (1.8) version of ruby.

I’m Doing It Wrong.

Far too often in our industry, people climb to the top of their blogs and shout to the rest of the world: “You’re doing it wrong! I’m doing it right! Maybe if you were more like me, you’d be more successful. Maybe if you were more like me, I’d consider you to be a real programmer. Maybe if you were more like me, I’d want to work with you, and I wouldn’t shudder in the very depths of my soul every time I looked at your code.”