Anthony Panozzo's Blog

At Haven, one of the unwritten values we had was "work as if remote". In this post I'll explain what this means and why it is important.

What does it mean?

"Work as if remote" means we always pretend that there are people working remotely, and behave accordingly. Even if everyone on the team is in the same room, or at the same meeting, we operate like there are people that are across the country. We do this by documenting:

• the plans that we have
• the decisions we make
• the things we do
• the things we learn
• meetings or conversations we have

The tools

We implemented this at Haven by using Slack for most communication, and Trello for capturing story-specific details in line with the cards that they were related to.

Also, MeetingHero (now the inferiorly named WorkLife) allowed us to record meetings in a collaborative way, although a shared Google Drive document could achieve the same goal.

Benefits

There are usually people working remotely, even if you don't think they are. First, there may actually be remote people that you have just forgotten about. :) We had a designer working in San Francisco, and while he didn't chime in often, writing as much as we could likely gave him more context for designs.

Quick post today about something that I was debugging that I thought might help someone out.

We were using should.js for Mocha assertions. In some of the tests, I was suddenly getting warnings like:

WARN Strict version of eql return different result for this comparison
WARN it means that e.g { a: 10 } is equal to { a: "10" }, make sure it is expected
WARN To disable any warnings add should.warn = false
WARN If you think that is not right, raise issue on github https://github.com/shouldjs/should.js/issues

I tried adding the should.warn = false but that did not seem to have an effect. Plus, this code would have been required in each file that had the problem, so it is an unsatisfactory solution.

I wanted to be alerted via Slack when the coffee was finished brewing so I could be sure that I would get coffee. Also, I wanted to work on a small hardware project to have some fun. I had a few hardware pieces from RobotsConf 2014, so figured I'd try getting something working that would fix my coffee notification problem.

The end result is a piece of hardware that sends a Slack message when the coffee has started brewing, and sends another one when the coffee is probably done:

Here is what the hardware ended up looking like in the end:

I'm pretty happy with the process and the result, and wanted to share how I thought about it.

How I went about making it

I figured that I would need some of the following hardware capabilities to make this happen:

• microcontroller for programming the logic
• ability to hit the internet (possibly with a wireless adapter)
• built in breadboard helpful to wire this up as a prototype

One of the boards I had laying around was a Particle Core (formerly Spark Core), and after understanding what it did, it seemed to fit the bill. It has a built-in breadboard, and, even better, an onboard Wi-Fi module. You can set it up to talk with your wireless network through the command line or with a phone app, which is kind of neat. It also has an interesting multicolor LED which signals the current system and networking state.

I recently set up RuboCop on an existing Rails project. I'll share how I approached it and what could have gone better. Specifically, I'll help you fit RuboCop to your project's needs, and not the other way around.

What is RuboCop?

RuboCop is a Ruby linter. It has a bunch of rules about how Ruby should be formatted. It calls these formatting units cops, and has many built in. You can define your own cops if you want to get crazy. Most of the built-in cops have configuration, and at least the ability to disable the cop.

Why use a Ruby linter?

Having a style guide of some sort saves the software team time. It's nice to have a canonical guide on what the source code should look like. Having a guide saves the team from wasting time formatting and lets them get on to more productive things. It also makes reading the code easier because everything is in a consistent format.

But having a style guide is not enough. Developers end up either unwittingly violating the style guide, or feeling like they are making passive-aggressive comments in code review. With a linter and continuous integration, you can ensure that the project automatically points out style violations. It stops wasting time and effort and lets you focus on the things that matter. It takes your documentation of what the software should look like and turns it into an executable specification.

Avoiding poor decisions

The built-in cops are based closely on the Ruby style guide. However, those guidelines probably don't line up with the current code your project has. Sometimes the cops are overbearing. Sometimes they don't make much sense. Sometimes they are just too strict.

The first thing to do–which I did a poor job of this time–is to ask the team that you are working with which things in the guide they disagree with. I spent a little too much time thinking on my own and changing things that eventually needed to be reverted.

Another poor decision was when I disagreed with the linter, but instead of listening to my experience and judgment, acquiesced to the tool's demands. I think that linters should serve the project's goals, not the other way around. If you find yourself rewriting or restyling swaths of code, consider if you could make the cops less picky or disable them entirely. Hopefully this post will help with understanding the tool's settings well enough to change them.

While at Haven, I thought we had a pretty good system for tracking the current status of a given pull request. In this post I'll document some of the labels that we used, what they meant, and how they helped us collaborate.

Labels For A Leaner Workflow

One of the challenges of working with pull requests is that they can sometimes take a long time to get merged in. Some of this can be mitigated by keeping pull requests small, some by reviewing pull requests as soon as possible. However, a lot of time passes while waiting for someone to review or respond to comments, or even know that there is an issue or question that needs to be addressed.

Why do we care about reducing cycle time of pull requests? It is work that is almost finished. If we can finish it, we reduce the overall work inventory in the system. It helps us get business value more quickly and learn what doesn't work.

Labels can clarify where a pull request stands. I see the clear next step and whether I am responsible. If something needs review, I review it. If one of my pull requests can be merged or needs changes, I do these.

The Labels

I'll cover the basic labels that I thought were most helpful, and how we thought of them. We didn't start with all of these; we just built them up over time and revised as necessary.

"work in progress"

"This isn't ready for review, but I want to make it public." It might be just to get code off of my machine in case something bad happens to my laptop, or it might be work that I want help or have questions on. By pushing code up early, we can communicate with actions rather than words. Instead of "I'm working on X", you can let commits do the talking.