Have you ever experienced this before? You’ve just finished a unit of work, and you’re rightfully proud of what you’ve accomplished. All that’s left is to commit and push. So let’s just git commit -am "… what exactly? Filling in that line can be really tricky, and you never know when another developer—or future you—will curse your name for an unhelpful commit message.

Fortunately, many common harmful practices can be summed up into a few anti-patterns. In this post, we’ll cover 5 critical mistakes to avoid.

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.

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.

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.

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.

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.

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.

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…

Note: Part III assumes familiarity with the idea of feature flags, and their practical implementation using the rollout gem. For the theoretical background, see Part I. For more info about rollout, see Part II.

You have feature flags in your application, letting you turn off calls to external services as necessary. How can we make this happen automatically?

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.