The Well-Bred Grapefruit

Musings on Software Development

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

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.”

On Higher Education

I’m writing this post in reference to a tweet from Chris Strom:

This is a pretty common mindset these days. As someone who works at Treehouse, I obviously either agree that college is a horribly inefficient way to prepare yourself to enter the workforce, or… well… I need to find a new job. :) Treehouse bases its value on the idea that you can gain all the skills you need to get a job in the tech sector – not by paying thousands of dollars a year and spending four years taking classes, but by paying tens of dollars a month and learning what you want, when you want.

It seems like a no-brainer, right? The “higher education” system is a dying leviathan that refuses to acknowledge its own mortality; much like newspapers, phone books, and the once-burgeoning pager industry.