How I work

My goal is to help your team ship your product faster while improving your software’s quality. To do so, I like to integrate closely with your team, share best practices, and mentor developers.

Integrating with your team

Some freelancers ask you to give them some specs, and they’ll leave you in the dark for months. Later they come back with something you may or may not want.

That’s not how I work.

I work closely with you and your team to help plan, define, choose the highest priority work, and break it into slices. I encourage your team to work in short iterations, releasing work frequently so we constantly work on what’s most important and you always know what’s being built. That lets us stay flexible and adapt to your customers’ changing needs.

Remote but synchronous

I love remote work.

I’ve been working remotely since 2019 and often advocate for teams to adopt it. But not everything needs to be asynchronous.

In fact, to help my clients best, I like to collaborate closely with their teams synchronously.

Planning meetings and retrospectives are vital. Quick feedback from founders or product managers can save countless hours of building the wrong thing. And having a time overlap allows me to pair-program with your team to solve complex problems, share knowledge, improve code quality, and mentor junior developers.

That means I prefer to work with teams with at least a four-hour time overlap with the ET time zone.

Building high-quality software

In order to build high-quality software, I practice test-driven development (TDD) and encourage pair-programming.

TDD helps developers design high-quality code while ensuring we only build what’s absolutely necessary to support a given feature. It also means we have a test suite that covers the behavior of our code, so we know if we’re introducing a regression at any point in time. That gives us the confidence needed to ship releases frequently.

If you want to read some things I’ve written about TDD (and its close relative, BDD), take a look at

• the intro to my TDD Phoenix book,
• how TDD changes code design from a process of invention to discovery,
• a short introduction to BDD, and
• how BDD helps us with just-in-time development

I’m also an advocate of pair-programming.

Though I don’t think it’s necessary to do it all the time—it does take a lot of emotional energy to do it— I think pairing is one of the best ways to build high-quality software quickly.

For that reason, I have an open-door policy for pair-programming with clients. I won’t force it on other developers, but I encourage teams to consider pairing on complex problems and always accept a request to pair.

With two developers collaborating on the same problem, we can arrive at better solutions faster. It removes distractions and prevents developers from getting stuck. It also promotes shared ownership of the codebase—a fundamental quality of high-functioning software teams.

If you think I’m the right fit for your team, I’d love to see how I can help. Send me an email, and let’s schedule a call!