Episode 46: We don't have a monopoly on being unhealthy

Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more.

November 26, 2012

Episode 24: Not so DRY that it chafes

This is the last of the episodes we recorded at RubyConf 2012. Thank you to the conference organizers for providing us with space to record, to all our guests for taking their time away from the conference to talk to us, and to all our fans who stopped by and said “hi”. It all means the world and keeps us going.

Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology.

November 18, 2012

Episode 22: Your code looks nice today

Ben Orenstein is joined by Bryan Helmkamp, founder of Code Climate, hosted software metrics for Ruby apps. In this episode, recorded at RubyConf 2012, they discuss what code climate is, how Bryan considers it a small business not a startup, and what its like being a solo founder. They also discuss how code metrics can help you write and maintain better software, how it helps, and how it changes behavior. Finally they explore what the biggest surprise for him has been so far, some of his plans, and what success looks like for him.

November 9, 2012

codeulate

programming

Code that says why it does

A new developer joins a project, and asks in Campfire: “what is the purpose of the can_refer_other_users flag?”

The flag in question is a boolean column on User. Rails automatically created a query method for this column, which is used like so:

if can_refer_other_users?
  # allow user to refer
end

The new developer’s innocuous query reveals an important subtlety between code that describes its job, and code that makes its purpose clear.

At first glance, a name like can_refer_other_users seems quite good. You’re reading it now without any context, and can probably guess exactly what it does.

The problem is, there are no clues about why we wouldn’t let a user refer others. Since growth is good, it’s counter-intutive that we’d block it. Looking in the database, most users have it set to true, with a handful of falses. No help there.

It turns out that some users are disallowed from this process because they were caught referring their own duplicate accounts, earning illegitimate bonuses. Unfortunately, you’ll find this information nowhere in the code. It lives only as an oral myth passed between developers of this project, subject to our own faulty memories.

I think this is a great example of the weakness of code that tells you what it does, but not why. Code that is clear about its job, but opaque about its purpose.

What if can_refer_other_users weren’t a flag anymore, but a method that referred to a new flag?

def can_refer_other_users?
  !caught_referring_own_accounts
end

Suddenly, it’s clear why this alternate code path exists. New developers have one less question to ask, and someone that removed the bonus for referring others would know this flag is now unnecessary. The implicit purpose behind the code is made explicit. And rather than burdening our memories with this fact, we use git.

Good developers are careful to create code that clearly tells you what it does, but the why is far more important. It’s more important because all code already says what it does. Even if that flag had been named foo, you could examine the conditional and ascertain that it determined whether users could refer others.

However, there’s simply no way you could find out why the flag was created without asking someone. That knowledge cannot be deduced from any amount of code study.

It’s tough to write code that communicates what it does, but it turns out that bar isn’t quite high enough. Strive to write code that makes clear the meanings behind its machinations. Code that can survive the loss of those who originally wrote it; that doesn’t just redescribe its implicit function. Code that answers “why?”.

Next Steps & Related Reading

Detect emerging problems in your codebase with. We’ll deliver solutions for fixing them, and demonstrate techniques for building a Ruby on Rails application that will be fun to work on for years to come.

Grab a free sample of Ruby Science today!

August 10, 2012

cpytel

Something Else Was Smellier

In episode #7 of the Giant Robots Smashing into other Giant Robots podcast, Ben Orenstein is once again joined by Joe Ferris, CTO of thoughtbot.

Joe and Ben dive right in to a technical discussion about Objects versus Structures. They then discuss what Joe does as the new CTO of thoughtbot, and how his goal is to set up a system where everybody is teaching everybody. Finally, they discuss why Joe doesn’t like using rspec’s let and subject, and his strategy for writing tests without them.

To have us answer your questions on the air

Email your questions to info@thoughtbot.com or tweet to us @thoughtbot.

Upcoming Events

Follow @thoughtbot, @r00k, and @joeferris on twitter.

giant robots smashing into other giant robots

Written by thoughtbot