I've written in the past about breaking problems down in the abstract. For the last couple months I've worked on a project where I can demonstrate it in real life!

Recently I needed to make a bunch of nearly duplicate pull requests. Like any good programmer, I automated the repetition, using sed and the GitHub CLI.

Work projects require git commits to be signed with my work email; I'd like commits on my personal projects to be signed with my personal email. The solution: conditional includes in my .gitconfig!

New job time means new dev environment time! I used RCM to save my previous dotfiles environment...what does it look like to use RCM to initialize my new environment from those existing dotfiles?

2021 was significantly better than I remembered it! Why do I feel like it was so awful?

I've started putting together my 2021-in-review article, and while doing so I've been thinking about why I think it's so important.

Recently I had an experience where a conviction and my determination helped me dig deep to solve a problem. When reflecting on it, I started to wonder when conviction is helpful as a developer, and when it is harmful.

I've been thinking this week about code distance — the distance between bits of code that are related to the same feature. I wonder if there's a good metric for this?

I've written far more JavaScript tests than Ruby tests in my life. But every time I write a test in JavaScript, I long for two features from RSpec.

I'm planning to work on a podcast this upcoming winter about how developers work. I'm calling it, fittingly, "How Devs Work."

Sometimes you want to write tests for a business rule that's based on multiple variables. Covering every possible permutation of the variables quickly becomes unsustainable. I've found myself using a different approach — one test for the positive case, and one test for each variable's negative case.

Did you know your blog's syntax highlighter probably has support for highlighting code diffs? I didn't.

Automation is weird. Sometimes we automate the smallest things, and even though it might not save us that much time, it's totally worth it. Like when I didn't want to spend five minutes tweeting my new articles anymore!

In a recent episode of Artsy Engineering Radio, we talked about styles of tech leadership. It helped me realize in hindsight that I'd tried to figure too many things out on my own.

I'm in love with RedwoodJS. I noticed that a recent PR on a personal project nicely captured a cross-section of a Redwood app — all the bits needed to pass data from the UI to the database and back.

I got hung up trying to set a default value for a Redwood CheckboxField. Turns out I just had the prop name wrong.

PRs are critical for collaboration. But they're also valuable for solo personal projects!

How do I get into flow state sooner so that I can make meaningful progress more quickly? By warming up.

How can you take advantage of *very* small blocks of time? By dedicating them to your shallowest work.

Rule 2 for taking advantage of small blocks of time — slice your work smaller to shift the meaning of "meaningful progress."

My first rule for maximizing productivity in small blocks of time — dedicate time to a specific goal. And schedule it on my calendar, before that hour gets taken.

As a maker with a manager's schedule, I need to figure out how to make meaningful progress in small blocks of time. I've got a few rules to help me.

Has discipline been a muscle this whole time and I just figured it out?

2020. Yikes! Ouch. Woof. What a year. It was awful at times — but some good things still came out of it.

The self-evaluation I gave myself this quarter included some of the nicest words I've ever said about myself.

In my head I created a distinction between long content and short content. I think the distinction is really there, but I don't think it warrants separate communication channels.

Today I'm thinking about lowering the bar for content creation by embracing smallness. Often when I want to create something it becomes *huge* in my mind, and I don't deliver it because I lose interest before achieving the grandiosity.

I recently replaced my kitchen faucet. The project reminded me of working with legacy code.

Standing on the shoulders of giants makes it possible to generate social sharing images with very little code.

Mmmmmmmmmm, sandwiches. Mmmmmmmmmmm, froyo. Not only are they both delicious, but they can both help you communicate better.

It's taken me many years as a developer to become comfortable with the speed at which I work. I'm slow! Recently my friend Nicole helped me understand more about why I work slowly.

I built a URL expander with Netlify functions, and connected my browser to it with a custom search engine. It saves me about 1 minute per day and now it feels like my search bar is a CLI.

I'd read that working with variables in Cypress tests was tricky, but I dismissed it as an edge case I didn't need to know about. Then I needed to store a variable in a test and hilarity ensued.

2019, am I right? It was a year! It occurred after 2018! And before 2020! And a bunch of things happened!

Is becoming a tech lead just like having children? Absolutely not! But I found at least one parallel.

Most refactoring resources are about specific actions in your code. This article aims to provide more general guidance for undergoing THE BIG REFACTOR.

I recently built some workshops. It was a lot of work, but it was fun and I learned some things!

2018 happened. There were some lows. But there were a lot of highs!

We recently finalized the speakers and sessions for Cream City Code 2018. We received a great number of submissions this year, and after reviewing them all, I've put together 5 tips for writing your next conference submission.

In the last couple years, I've given over 20 talks at local meetups and code camps, and conferences throughout the Midwest. Here are 10 tips for preparing talks.

Rejection feels bad. Sometimes I forget how to deal with it. Here are some of the strategies I keep forgetting.

2017 was awesome! I hit the speaker circuit hard. I'm hoping for a great 2018 as well!

What can we learn about testing from a Russian playwright that's been dead for over 100 years?

I wanted to speak more in 2017. Looks like I'm getting my wish!

When unit testing your ES2015 code, you'll probably want to mock dependencies. My team had been tolerating some test-induced damage to our code, in order to allow mocking of ES2015 module exports. But recently we discovered a feature of ES2015 modules that allowed us eliminate the test-induced damage.

2016 was a ...year that happened. At a personal level, I had a great 2016.

The project I'm currently working on requires a spreadsheet to be imported into the database. SSIS seemed like the logical solution to this. Then the honeymoon ended, and I found out SSIS was stealing my money and slowly poisoning me. Here are some other things SSIS does wrong!

October was a crazy month! Aside from being peak soccer season for my kids, I had two speaking engagements, and helped organize a conference.

Some advice and resources to help someone get started with TDD.

A coworker recently asked me to send some good resources for introducing a team to TDD. I thought the internet was a good place to put it.

I got to present a variation of my static site generator talk at Chicago Coder Conference this year. Here are the slides!

Setting up a React project proved to be a challenge for me the first time I tried to learn it. It went a little better the second time around.

I am in the market for a new MV* framework in Javascript. I'm not totally sold on Angular 2 or React, but I think Ember looks neat.

I recently presented at MKE Web Pros, about static site generators. I put together some slides and notes.