Choose Your Constraints

A while back I published a few Tweets about constraints. They seemed to strike a chord with others, and I want to develop the point a bit more.

So let’s start with this: What are some constraints you feel in your day-to-day coding? Which factors are limiting your ability to produce new, shippable features? Consider the following list:

Take a moment and check off the 3 biggest pain points in your current job.

Metrics That Matter

Many of us are familiar with the standard tirades against the use of metrics in judging developers. Most of these arguments basically boil down to one of two concerns:

  1. Metrics tend to value things which shouldn’t be valued
  2. Metrics attempt to quantify things that fundamentally elude quantification

Examples of the first may be measuring lines of code (which rewards overly verbose, unmaintainable solutions) or test coverage (which encourages test suite bloat and doesn’t ensure good testing practices). The second applies to metrics like story points completed (which attempts to quantify productivity as story points – a bad measure of accomplishment – per time, and encourages high estimates and rush jobs).

While these points are true, I would argue that there’s a bigger issue here. We should judge the utility of metrics by the results they incentivize. These metrics are meant to encourage individual performance, but from a company’s perspective, the goal should be total performance as a team.

Formulating the Ethics of Programming

Uncle Bob recently published a post where he attempted to formulate the ethical principles that should guide programmers. It was an interesting concept, but I immediately felt it could use a rewrite.

Although I agree that everything in his version is a good idea, I disagree with the formulation as an ethical guideline for programmers. Simply put, the principles of Agile are brilliant. But they hardly deserve mention in a list of ethics, and – I would contend – detract from the list.

Recruit Software Engineers With This 1 Weird Old Tip

I’ve read a lot recently about how hard it is to recruit programmers in today’s market. Personally, I think it’s all hogwash.

There are plenty of great programmers out there, but companies aren’t actually looking for them. What they really want is a plug-n-play solution, a programmer who knows what they need him/her to know, who can churn out code and build software solutions.

The problem is that engineering is an art and a discipline, and you can’t just expect to hire someone and have them show up batteries included. A company that refuses to train its coders is a company that won’t find enough people to meet its needs.

What Should a Junior Developer Work on First?

Recently, a new member of our team asked me (and other coworkers) to list 3 things a junior developer should accomplish within their first 3 months on the job. Being at the end of my first year on the job, it was an excellent opportunity for reflection on what I have learned during this year which was most useful.

After some thinking, I came up with 3 concrete goals, emblematic of 3 big-picture objectives which should be guiding lights for the new developer.

Here are my picks:

  1. Be reasonably comfortable with TDD
  2. Write good commit/PR messages
  3. Present at a team hangout

These might seem like arbitrary goals, so they deserve some explanation.

The Making of PersistentOpenStruct

So I built this thing…

The Challenge

Here’s the problem we were having at work. We have a bunch of microservices which communicate with each other via HTTP. Since they’re passing around raw data, and the shape often changes, we decided quite some time ago to use classes inheriting from OpenStruct, that magical schema-free class, as a data container.

The problem is, OpenStruct is also ridiculously slow…

Feature Flags in Ruby, Part II: How and Where

Note: Part II assumes familiarity with the idea of feature flags. For the theoretical background, see Part I.

Alright, you’re convinced that feature flags are a necessary tool for your app. Let’s discuss a gem, created by the late James Golick, which make the process of feature flagging as simple as could be.

Feature Flags in Ruby, Part I: What and Why

Note: Part I will be more theoretical. If you already know about feature flags and want to learn about the rollout and degrade gems, check out Part II and Part III.

What are Feature Flags?

Glad you asked!

Feature flags, also known as “feature flippers,” “feature toggles,” and more, are a way to simply turn bits of code on and off in a live, running application.

While we won’t get into too many of the details in this post, here’s a simple way to think about it. Let’s say you run a bowling alley. Most of the time, it’s a straightforward establishment – lanes, balls, scoring computers, shoes… you get the idea. However, every Tuesday night you turn over the place, and now it’s Cosmic Bowling night! You’re blasting music, shining blacklights, the disco ball is spinning… it’s a different world. How are you going to carry out this operation?

Closures and Callbacks: Running Arbitrary Task Sets Synchronously in JavaScript

On the Vitals Choice team, we have divided our product into a number of apps. Each of those apps has one running instance per environment , and we have several environments. So as you might imagine, making sure updated code gets propagated through all those places at the right time can be quite the task. Luckily, we have a Hubot instance which does most of the heavy lifting, but even issuing all the Hubot commands for every single app makes you wonder: shouldn’t there be a way to automate this better?

Well, it turns out that an attempt had been made in the past, but we ran into a problem: JavaScript’s asynchronicity. The server hosting Hubot was suddenly told to update all the apps for a particular environment, and the simultaneous processes overwhelmed the CPU and memory.

Considering the problem, I realized that callbacks were the way to go. Hubot comes with an evented system, which we could utilize to force Hubot to only launch one app at a time. Here’s what I came up with, and what I learned along the way.