Software-Engineering

After more than a decade in the field as an engineering leader and hands-on practitioner, I’m thrilled to be offering a consulting service. I am a strong contributor in three areas: technical consulting, mentorship, and workshops & teaching. Technical consulting I love digging into tough problems in greenfield and legacy code. A few things I’m good at: Raising code quality (tooling, testing, monitoring & observability, building CI/CD pipelines) Big scary bugs 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 mentored dozens of software engineers. I love listening and helping people get better! My mentees are successful software engineers across the industry. I can meet on your schedule and cadence. ...

I think many engineers would be better contributors if they started to think more about the customer impact of their work. Level One: Delivery Early in our careers, we’re looking for explicit directions, which we learn to deliver, and that is vital. Sophisticated checkout wizard? Complex domain model? I can do it! You learn to make it work and demonstrate that you can ship. Next Level: Thinking Like a Product Owner The next level is thinking like a product owner and asking: “Does this improve the customer experience?” ...

Anytime you’re making a list at work, rank it. This idea came from my recent post: Anytime you’re making a list at work, of anything, rank it. Tech debt? Security concerns? Feature requests? Rank them. Rank them so that you do the important ones first. Those are the only ones you probably will do. — Jake Worth ⚛️🌲 (@jakeworth.com) Oct 16, 2025 at 12:11 PM This is a nuanced argument; let me try and make it! ...

A suggestion about data: generate it now, and figure out curation later. Example: Labeling Tickets Here’s an example from my work. When I write software engineering tickets, I label them; if I’m writing a ticket that improves patching, I’d label it “security.” In Jira, those labels are links. Click “security” and you’ll see dozens of tickets that we’ve written to improve our security posture. And so, when a stakeholder asks: “What are we doing about security?”– we have an answer. All because we continually applied one little label. ...

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. Own Your Confusing Software Before: “If a customer thinks software is confusing, they might just need training.” Today: “If a customer thinks your software is confusing, it is confusing.” When building a SaaS product, it’s easy to write off difficult or noisy customers. Especially if that’s part of a team’s culture. ...

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. It’s Tradeoffs All the Way Down Trade-offs at a low level, such as choices made within an individual code file, and trade-offs at a strategic level, such as which technology tools to invest in and people to hire. It often feels like it’s trade-offs all the way down. ...

TONY: We should take this outside. JARVIS (O.S.): I must strongly caution against that. There are terabytes of calculations still needed – TONY: We’ll do them in-flight. Before Your Take it Outside (Ship) There’s been a lot written in our industry about the value of taking it outside (shipping). Today I’d like to write a little more, with an idea that I think makes the value of shipping clear: shipping tells you, precisely, what matters. ...

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. Example: Grow Cube When I first started programming, I took a computer science course that presented a puzzle called the “Grow Cube.” You can play it online here: ...

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.” This bit of radical candor was part of a series of challenges I faced early as a junior engineer. They shook me out of impending Expert Beginnerism. They expanded my concept of engineering excellence. ...

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 explain what “boring” means to me. A not-boring example Sometimes programmers will write traditional JavaScript function functions and arrow functions in the same codebase: ...