Archive

Hello!

New blog post just dropped on a little app I built over the weekend called Dream Diviner. The app provides free dream interpretations.

This app is built using the OpenAI API and uses GPT-3.5 under the hood. This is an exercise in leaning into the hallucinations that large language models (LLMs) tend to generate.

I put together a blog post to reflect on the process of building this, along with where tools like this will fit in to a product’s stack:

Greetings on this fine Monday.

Over the past few weeks I’ve started to put together a new project: a book. The goal is to write a book about finance for software engineers.

Finance is a topic that’s always been interesting to me. What’s the difference between get-rich-quick schemes and more sustainable wealth-building efforts? Can you tell the difference? Can you get better than a coin-toss when it comes to selecting healthy, sustainable companies?

By gaining a surface-level understanding, I hope developers can unlock more career growth for themselves and personal financial gain. The companies they work for will be more well-rounded, able to innovate not just on engineering axes but financial as well.

Hello!

This week’s blog post tries to answer a question that I’ve been receiving a bit more at work. When and how do we make the decision to finish technical migrations?

In a perfect world, every technical migration is staffed and finished within the expected timeframe.

Hello!

This week’s blog post explores a concept from workplace safety as it relates to engineering team health. It’s called:

This week’s blog post is distilled from several conversations I’ve been having at work recently.

Why do we use S3? What’s an asset pipeline? Why should all application-stored files be marked as private, even if they are things like profile pictures?

I explore these questions and provide a bit of a history lesson in

Hello Folks!

This week’s blog post is on a concept I use when starting or joining a young team. It helps build accountability and is a tool for radiating intent.

The concept is simple: Every week the team gets together to write a of their progress.

Happy Tuesday, Folks.

It feels a little weird to be publishing a newsletter, given the recent events in the U.S. over the past week. I’ll do something I usually don’t do, which is address a political topic, and then move on with the normal newsletter.

Consequences

”,” my German teacher corrected me.

Hello!

It’s been a little while. I have not written a newsletter in nearly a year.

2020 threw a wrench into all of our plans. My wife and I tried to make the most out of last year. We spent some time in Europe visiting her family, we moved to Seattle, and we bought a house. As if the year wasn’t already eventful enough!

Here’s some of the writing done since the last newsletter.

Hello Folks,

Today we published the last episode of our Test Desiderata series. Over 12 episodes and 12 weeks, we examined different desirable properties of software tests.

Kent and I rounded the series out with two last episodes:

Hello Folks!

My colleague, Kent, and I have continued to produce videos around the desirable properties of tests. Today, we released our 10th episode.

These videos are based on a blog post Kent wrote titled “Testing Desiderata.” We’ve been recording weekly videos exploring each property.

The two most recent videos are:

Hello Folks!

I have not had the chance to write much in the past few weeks, but I have had the chance to put a few videos together on the ideal properties of tests with my colleague, Kent.

Kent wrote a blog post titled Testing Desiderata that explored the 12 ideal properties of tests. We’ve been recording weekly videos exploring each property.

Hello Folks!

This week, my colleague and I recorded the first video in a series on testing. My colleague, Kent, wrote a post titled Testing Desiderata a few weeks ago covering the 12 properties of good tests in software.

The first property we cover this week is Behavior. How should we write tests that exercise the behavior of the code?

Hello Folks!

This week’s post follows a similar theme of many previous talks and posts: How can we wrangle large Rails applications?

As a business scales and adds more engineers, some of the Rails defaults start to become difficult to work with. Putting everything in the app/ folder stops being the best idea.

“$10 million?!” We felt like shit.

Hello Folks!

Throughout my career, I’ve had projects go well and less-than-well. Today brings a few stories and a framework that try to make sense of the differences.

Hello!

It’s been a little while. I took some time off of writing to get married in August. My wife (still weird to say) and I had a lot of fun and enjoyed some time in Napa afterward.

This week, I recorded a video at work with Kent Beck. Kent has been exploring a few ideas recently, one of them being test && commit || revert (TCR). The idea is you run this command often while developing. It gives you instant feedback. If your tests pass, the code is committed. If the tests fail, your work in progress is wiped away. This way of working sets up a lot of nice constraints, and I find it a great tool to use from time to time.

Hello!

It’s been a little while since sending a newsletter out. I have not been writing that much in the past few months. Wedding planning, speaking gigs, and work has been occupying a bit more of my time.

I have squeezed out a few blog posts worth highlighting, ranging from personal to tactical. Hopefully all of them challenge your thinking and can help you build better software.

Here they are:

Howdy Folks!

I’ve finally recovered from the jet lag after heading to Australia for RubyConf AU. It was a great conference: many great talks and even better people to meet.

The fine folks had me out to give a talk titled . It’s a talk that covers wrangling large Rails applications without reaching for microservices.

Hello Folks!

I hope you’re having a relaxing holiday season. For myself, this is one of the busiest times of the year for work as Gusto helps its customers close out their years and get everyone paid.

This week, I’ve put together a blog post and Ruby gem around mutation testing. Mutation testing is the practice of programmatically changing code to see if it breaks. It’s a great practice to see how well-tested code is. “If I delete this line of code, will the tests still pass?”

Hope everyone had a great weekend!

Earlier last week, the video for my EmpireJS talk was posted. This talk starts with a question: “What is webpack and why do we use it?” It later moves through how the rapid change in JavaScript community is a feature not a bug and not the first time rapid change has exited in the industry.

Welcome to Thursday, Folks!

Today brings the final post in my feedback series, Encouraging Feedback on Your Team.

Good morning, Folks!

This week I’m exploring the topic of giving and receiving feedback as a software engineer. Hopefully by writing this stuff down, we can all get a bit better at it.

Today’s post turns the tables and discusses . How can you gracefully listen and receive feedback as it’s being given? What are some no-nos? How do you balance wanting to interject with looking for more clarification?

Hello Folks,

This week I’m trying something new: Rather than putting together a single blog post for the week, you’re getting 3. It’s an entire series called Feedback for Engineers.

It’s Tuesday, my friends.

This week has a new blog post about giving great code reviews for your teams: 8 Tips for Great Code Reviews. This is a post that had been kicking around in the brain for a little while. I finally took the time to write it down.

Hello Folks!

A week and a half ago, I had the opportunity to speak at EmpireJS. This was a 2-day JavaScript conference in New York with interesting talks ranging from designing keyboard-accessible applications to dealing with JavaScript technical debt.

It is Wednesday, my folks.

This week brings a blog post about continuous improvement and the perils of large releases. I first heard the idea while listening to the CTO of Slack, Cal Henderson, long before he started Slack. While in school, my idea of a bangin’ spring break was to spend it in Miami, holed up in a convention center for the Future of Web Apps conference. The year was 2008.

During his talk at the conference, Cal talked about “the teeth” of long release cycles. The teeth bite you and break the skin when you take too long to ship. This image has been seared in my head ever since my less-than-raucous spring break, and I’ve finally gotten around to writing a blog post about it.

Hello, Monday!

This week brings a post that continues the exploration from Rich Hickey’s Simple Made Easy talk. We dive into the next item in the Simplicity Toolkit: functions.

Specifically, we look at how functions instead of methods can simplify your applications. That is not always the case, though. Special thanks this week to for pointing out how embracing functions can lead to another problem: an .

It is Wednesday, my dudes folks.

This week brings a new blog post based on one of my favorite technical talks, by Rich Hickey. The talk covers some great fundamentals of simple software, and how we often confuse “simple” with “easy.”

Hello Folks!

The video to my talk at Goruco 2018 was posted. This talk covers breaking up a Rails monolith at Gusto along with some concrete tips we use day-to-day when developing Rails applications.

Hello Folks!

This week brings a blog post of a talk given at the Gotham Ruby Conference on June 16, 2018. I had the privilege to deliver a talk about some things I’ve learned over the years breaking apart Rails monoliths.

The talk dives in to story about how to sensibly break up a Rails monoliths, along with 5 few concrete tips on how to break up your own monolith. The talk touches on when you need to unwind what calls “Conceptual Compression” in Rails. What concepts do we need to expand as we start to modularize our Rails applications?

Hello Folks,

Hopefully your spring is full of longer days and more sun without too many allergies.

This week brings two new blog posts, one about refactoring and one about how the blog is built:

Hello Folks!

It’s been a little while. This week brings the first new post in some time. Slow start to the year.

Other than this new blog post, I’ve also been enjoying the work from a few friends. Sihui wrote a blog post on contributing to the Ruby language and this newsletter is sent using from Justin.

Hi Folks,

This week brings a post about circular dependencies.

It’s about Rails callbacks, but on a deeper level it’s about how those can introduce cycles in our dependency graphs and ruin projects.

This one was a lot of fun to write. I especially like how some of the diagrams turned out.

Hi Folks,

It’s been a little while! We got a TV at home so we have been getting that broken in. We’ve been enjoying The Marvelous Mrs. Maisel as of late.

This week brings a new blog post about a refactoring strategy that ties a few different best practices together. It’s a way of removing within your code to simplify its execution.

Hi Folks,

This week brings a topic near and dear to my heart: technical debt.

This topic has been an enigma in my professional life for a while now. We know that technical debt is something that we shouldn’t have too much of, but how much is too much?

This conversation started some time back based on a question I posed in the . Quantifying the different aspects of technical debt is extremely difficult. This post tries to address some of the techniques we’ve developed over the past few months at .

Hi Folks,

Happy Friday!

Today brings a simple little blog post that covers a few tactics I use to better understand legacy code.

Before you change code, you must first understand it. Any code that has aged a bit is legacy code, even code that you may have written yourself. This post covers some of the non-obvious ways of learning more about the code in front of you.

Hi Folks,

This week’s blog post is about a topic I first discovered while reading the book Seeing Like a State. It’s called “Mētis” and refers to the intelligence and expertise developed over time within a craft.

Hi Folks,

This week brings a blog post about bringing functional programming to a traditionally more object-oriented language, Ruby.

At , we’ve been experimenting with some of these ideas in a big refactor we’re working on. These ideas have changed how I write Ruby for the better. The end result is expressive code with a high level of safety.

Hi Folks,

Hope those in the US enjoyed yesterday’s holiday.

It’s been a quiet few weeks on the blog, due to keeping busy at work. We ran a boot camp for some new hires and are finishing up a few big projects.

Last week brought 2 new posts, though. One is a that I compiled for some of the folks going through the boot camp at work. It’s a combination of books, blog posts, and subscriptions that are useful for those just getting starting in their careers.

Hi Folks,

This week’s post is a project that I’ve been working on for a little while now. It’s a briefcase that deploys code, in the spirit of the fabled briefcase that follows any POTUS around.

This project began as a “What if?” that snowballed. At its core, the project is a hacked Amazon Dash button. The project slowly came together over the course of a few weeks and is in use at my day job, .

Hi Folks,

Today we’ve got a blog post on a refactoring tool we’ve been using at Gusto we call a Test Vice.

A Test Vice is a suite of tests meant to be thrown away. It’s a temporary piece of code designed to give you peace of mind while refactoring. Test Vices are very similar to , except Test Vices are designed to lock down existing behavior, not just some.

Hi Folks,

This week is a review of the seminal programming book, Extreme Programming Explained. If you can’t tell, I’m on a bit of a kick with reading decade-old programming books.

Hi Folks,

Two posts in a week! How about that?

This post details a strategy called .

Hi Folks,

We’re diving into a large refactoring at work, and we discovered an interesting little pattern in the process. As with many developers, we are on an FP bender and are striving to make our code more functional and declarative.

We have a few third-party libraries which are imperative by nature: They only do interesting stuff via side effects. We wanted to turn those side effects into return values to make testing and logging easier.

Thus, we created a pattern we’re calling . It’s useful to keep in the tool belt for turning imperative legacy code into easily-testable functional code.