Software-Engineering on Jake Worth

Consulting

Wed, 29 Apr 2026 00:00:00 +0000

After a decade in the field as an engineering leader and hands-on practitioner, I’m thrilled to be offering a consulting service.

I can add value in three areas: technical consulting, mentorship, and workshops & teaching.

Technical Consulting

I love digging into thorny problems in greenfield and legacy code. A few areas I can contribute:

Raising code quality (tooling, testing, monitoring & observability, building CI/CD pipelines)
Big scary bugs
An infestation of little bugs that keep lingering
Process improvement
Internal/external communication and meeting/ceremony refinement
Refactoring
Complex feature building
Requirements gathering and story-carding
Pair programming, code reviews, and hands-on coaching
Technical writing and documentation modernization

Mentorship

I have been mentoring software engineers for a decade. I love listening and helping people get better! Dozens of my mentees are successful software engineers in the field. I can meet on your schedule and cadence.

Prioritization for Engineers: Rank Every Work List

Thu, 23 Oct 2025 13:46:50 -0400

Anytime you’re making a list at work, rank it.

Generate the Data. Worry Later.

Mon, 07 Jul 2025 11:58:44 -0400

A suggestion about data: generate it now, and figure out curation later.

Four Things I've Changed My Mind About in Engineering

Thu, 29 May 2025 09:20:14 -0400

I think a mark of a great engineer is being willing to change one’s mind when presented with new information. Here are four technological things I’ve changed my mind about.

It's Tradeoffs All the Way Down

Wed, 19 Feb 2025 10:11:37 -0400

One common trait among early-career programmers is seeing technology choices in black-and-white. I’ve been there. “Redux is awesome!” “Nested ternaries are terrible!” As you advance as a programmer, for better or worse, you start to see almost everything as a trade-off.

Ship Earlier to Learn What Matters

Sun, 24 Nov 2024 10:16:49 -0400

TONY: We should take this outside.

Getting Comfortable With Discomfort in Software Engineering

Tue, 03 Sep 2024 00:00:00 +0000

Today I’d like to talk about a quality that’s essential to success as a computer programmer. Let’s call it “comfort with discomfort.” As programmers, we live in this unsettling space. Here are some thoughts on discomfort and tips for dealing with it skillfully.

Master the Fundamentals First

Thu, 07 Dec 2023 00:00:00 +0000

When I was learning to program, I was fortunate to pair with very experienced engineers. One day while coding, I said: “I think we need to use Ruby’s map method, but I’m not sure how that works. Let me look it up.”

Later, my pair offered some feedback: “You can’t be looking up map. You need to know how all of Ruby’s Enumerable methods work.”

Write Boring Code

Wed, 13 Sep 2023 00:00:00 +0000

Write a little bit of code, and you may come to an unsettling realization: there are multiple ways to do almost any programming task. How do we choose between several that work? I manage this uncertainty with a guideline: writing boring code. In this post, I’ll try to explain what boring means to me.

From Booleans to Strings in Frontend State

Fri, 04 Aug 2023 00:00:00 +0000

When it comes to controlling frontend presentation, developers often rely on booleans. However, this approach can be limiting. In this post, I’ll explore the drawbacks of using booleans and introduce a more versatile alternative: plain old strings with type safety.

Variable Name Antipatterns Named and Explained

Mon, 03 Apr 2023 00:00:00 +0000

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

Let’s talk about variable name antipatterns!

All My Best Tips For Expertly Reviewing Your Own Code

Sat, 12 Nov 2022 00:00:00 +0000

Great developers review their own code often and effectively. In this post, I’ll share a checklist of all my best tips for maximizing this important practice.

Buy the Best Hardware You Can

Tue, 25 Oct 2022 00:00:00 +0000

Some advice I offer people entering the programming profession is to buy the best hardware you can. You’re going to need it.

Print Last Exit Code

Fri, 21 Oct 2022 00:00:00 +0000

The exit code of a command in a Unix-based system is an important and easy-to-miss piece of data. It isn’t printed to standard out; you have to go looking for it. I find it useful to inspect this information when debugging or considering chaining unfamiliar commands.

Default to Programming Convention

Fri, 14 Oct 2022 00:00:00 +0000

Trying to enforce unconventional coding preferences on a team is an uphill battle. When in doubt, default to convention.

How to Introduce New Ideas

Thu, 08 Sep 2022 00:00:00 +0000

How do you introduce new ways of working? We want to bring a new idea to our engineering teams, such as a new command-line configuration, testing tool, or design pattern. But engineers can be discerning and stubborn customers. The idea needs to stand on its own. And, you have to sell it.

Prefer Real Data For Software Development

Thu, 18 Aug 2022 00:00:00 +0000

When testing with data, I prefer realistic data rather than random data.

Better Than 'foo'

Wed, 13 Jul 2022 00:00:00 +0000

There’s almost always a better variable name or value than ‘foo’. It’s useful as a debugging placeholder, but it almost never belongs in production code, even and especially in automated tests.

Desire Paths in Software

Sun, 05 Jun 2022 00:00:00 +0000

We’ve all seen a desire path. They are footpaths created by erosion from human and animal traffic that communicate a wish for a path that doesn’t exist. When you walk on a paved path toward a destination and notice a shortcut in the earth, that’s a desire path. It’s the way people go, rather than the way we would wish them to go.

Spend More Time Thinking Hard

Wed, 01 Jun 2022 00:00:00 +0000

Ben Kuhn’s ‘Think Real Hard’ shares a problem-solving checklist from the scientist Richard Feynman:

Write down the problem.
Think real hard.
Write down the solution.

On its face, this advice is ridiculous. If only we just sat and thought about the problem, we’d win a Nobel Prize like Dr. Feynman!

Goodbye Shared Dotfiles

Wed, 25 May 2022 00:00:00 +0000

A lot of people start programming with shared dotfiles, copied from a team or online. I did. Maybe you’re ready to move on; how would you do that?

On Starting Over

Wed, 18 May 2022 00:00:00 +0000

I used to have a bad habit when working alone: I’d start a feature, begin doubting my approach, throw away my work, and start over from scratch. Sometimes more than once. The result? Wasted energy, abandoned code, confusion about what I had and hadn’t implemented, and repetitive rework. This post is a collection of thoughts on this practice.

It's Harder to Read Code Than Write It

Mon, 25 Apr 2022 00:00:00 +0000

In Things You Should Never Do, Part I, Joel Spolsky narrates Netscape’s ruinous decision to rewrite their browser from scratch. This introduced the following concept to me: “It’s harder to read code than to write it.” I believe this is true. Today I’d like to explain why.

Avoid Similar Variable Names

Mon, 14 Feb 2022 00:00:00 +0000

A common, problematic convention I see in Ruby tests are variable names like this:

user_a = create(:user, last_log_in: today)
user_b = create(:user, last_log_in: last_year)

Opt Into Beta

Wed, 02 Feb 2022 00:00:00 +0000

Here’s a technique I’ve used on launches: instead of a big scary waterfall, or, in tandem with a phased release, let customers opt into a new feature.

Use a Dev Email

Sat, 29 Jan 2022 00:00:00 +0000

An engineering technique I recommend: when you sign up for any service, even on a side project that’s just getting off the ground, create an email group called dev@<your-domain.com> that forwards to you and any other technologists, and use that email to sign up.

How to Answer Questions on Stack Overflow

Thu, 27 Jan 2022 00:00:00 +0000

Here’s my simple framework for answering questions on Stack Overflow that reach and help people and earn reputation.

Presence is Boolean

Mon, 24 Jan 2022 00:00:00 +0000

When possible, I prefer to use the presence of data to represent a boolean, rather than a boolean itself.

Be a Better Technical Consultant by Saying "I Think That..."

Wed, 19 Jan 2022 00:00:00 +0000

An idea I find useful as an individual contributor is starting my consulting with this phrase: “I think that…”. The idea is to let your arguments stand on their own, rather than appealing to your experience or other authorities.

Exercism Raindrops in Python

Sun, 06 Dec 2020 00:00:00 +0000

I’ve been learning a bit of Python this Fall to facilitate conversations with a mentee. In this post, I’m going to share the first Python function I’ve ever written, a solution to the Exercism challenge ‘Raindrops’.

Essays on Programming I Think About a Lot

Thu, 29 Oct 2020 00:00:00 +0000

Programming is a new and abstract field, and so we place great emphasis on ideas. When I find one that sticks with me, I end up sharing it again and again. These are some of my favorites.

You Have New Mail

Fri, 16 Oct 2020 00:00:00 +0000

Here’s a familiar scenario: you open a new terminal, and before the prompt appears, you see the following.

You have new mail.

What’s going on here?

Technologist Reading List

Sat, 28 Sep 2019 00:00:00 +0000

Here’s my list of favorite programming books.

The Universal Programming Language

Sun, 17 Sep 2017 00:00:00 +0000

Recently I tried to answer a question that I think is common to consider when you’re first learning about computer programming. I’ll paraphrase:

Why can’t there be an “universal” programming language that serves all purposes?

Execution Credibility: Ship, Then Signal

Wed, 19 Jul 2017 00:00:00 +0000

As soon as you can, just do the thing you have to do, and respond with: “It’s done.”

The N + 1 Problem

Sun, 22 Feb 2015 00:00:00 +0000

Recently, I was thinking about the N + 1 problem. N + 1 is a performance issue in a web application, where a method call unleashes a torrent of database queries.

The Case for One Computer Monitor

Mon, 31 Mar 2014 00:00:00 +0000

I have one computer monitor on my desk. Not long ago, this was common, but today, many people have two, three, or four monitors. In this post, I’d like to make the case that most professional programmers can use just one monitor.