The Culture of the Codebase

One of the earliest bits of code in Laddertruck, the Ruby on Rails app that powers FireHydrant, consistently gets a mention in our Slack. Here it is:

fun_creator = FunctionalityCreator.new(organization, actor: actor, account: account)
fun_creator.create(fun).tap do |funfunfun_looking_forward_to_the_weekend|
  if funfunfun_looking_forward_to_the_weekend.successful?
    service.functionalities << funfunfun_looking_forward_to_the_weekend.object
  end
end

If you’re unfamiliar, this is an homage to the oh so catchy, Rebecca Black’s “Friday.”

This tiny chunk of code adds functionality to a service in a user’s FireHydrant organization. As far as the user knows, this code could be anything, with any variables, and any class names. They only care that it works. But to us, this piece of code is much more, it’s a reflection of who we are as a team.

The codebase should be a fun place to work

We’re remote first, especially now, at FireHydrant. With no office, watercooler, or team outings, it can be challenging to talk to your peers. The place that we do “talk” to each other is our code. Our codebase is our metaphorical office, it’s where we collaborate and solve problems together. So why do so many companies have a codebase that’s sterile and devoid of any fun?

At FireHydrant, there’s a consistent laugh when you work in our codebases. You’ll find all sorts of things ranging from YouTube links that you have no idea where they go (it’s not a Rickroll, I promise), funny test arguments, and witty mentions to a phrase a teammate uses.

Take this piece that needs to clear a cache on the record in Laddertruck

# THE FRESH MAKER
# <https://www.youtube.com/watch?v=JqgqgcE8Zck>
incident.reload

Another example is one of our engineers saying "dig" when he likes something. I believe it means "I dig it." It caught on a little bit in the team, so when voting on runbooks was introduced, this line of code came with it.

case params[:direction]
when ‘up’, ‘dig’
  # … voting up logic
when ‘down’
  # …
end

Beyond having fun in code, we also write comments as if we were talking to each other in person. You can almost tell who wrote the comment without needing to git blame. They are entertaining to read, and I sometimes wonder if I would skip it entirely if it had no personality.

Said another way, our codebase has a personality: our company’s personality. Yours does, too.

Your codebase is a result of your culture.

You can see codebase culture in programming language communities. If you’re a Rubyist like I am, you probably know about the fun rubygem names like capybara, faraday, and puma. It’s not a surprise that the Ruby community has this commonality with personalities like Aaron “Tenderlove” Patterson and Bryan “test all the f***ng time” Liles, to name only two. Both of whom were exceptionally early in the Ruby community itself.

It’s incredibly likely that your company’s codebase mimics the personality of the engineers contributing to it. If you want a no-frills codebase, you should hire people that exhibit that behavior in their day to day work. If you wish to have a codebase that is fun and will make you laugh from time to time as I do, you need to hire people with that personality. It truly is your decision on what type of codebase culture you want, and it starts with hiring.

Culture is set early.

Probably everyone at FireHydrant has heard me say this: The trajectory of anything is set the second time you do something.

If you want to have a test-driven development culture, do it early and often. If you want a good code review culture, do it on as many pull requests as possible. If you want to see fun variables, Easter egg links, and descriptive comments… you get the idea.

What type of codebase do you want?

If your codebase doesn’t have your team’s personality, or worse, has a toxic one, what does that say about it? What constraints are teams operating within that they think exist, but don’t? Are people not writing comments because there is another group that thinks comments are useless? Are there no tests because it feels pointless to write one now?

A codebase with no personality makes me think of an office with bright fluorescent lights, plain walls, and no windows. I’d also assume product and project managers write a Jira issue, wad it up, and throw it to engineers saying it needs to be done by the end of the week.

We’re designing a company at FireHydrant. The early decisions we’ve made like the name of the application itself (Laddertruck), object names and even Slack channels like #wtf_is_happening_with_my_code are going to end up in our customer’s hands either directly, or indirectly. We want FireHydrant to be a fun and uplifting place to work, and looking at our codebase is one of the many ways to verify we’re doing that successfully.

Your codebase(s) are where you work, and having one that lacks any personality will make engineers feel like they don’t have agency in their contributions to it. I’m not advocating that you should name every single variable something funny, or that you should always write comments in first-person. Doing so would lead to a funhouse codebase where you have no idea what is up, down, left, or right. But every once in awhile, it’s a great idea to add some pizzazz to the codebase.

So why name a variable functionality_creator when you can call it fun_creator ?