8 Crazy Blog Posts!

I have a confession to make. I’m embarrassed by my blog.

I’m certainly proud of (most of) the content. It’s shown significant development in complexity and depth since I started. But I have a lot of ideas running around my head all the time, some of them even good ideas, and I’d like the blog to reflect more of them.

So I’ve decided to give myself a Chanukah gift: I’m requiring myself to make every effort to come up with one blog post every day of Chanukah.

This probably makes you wonder a few things.

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?