Ever since we transitioned to working remotely, there’s been a lot of remote pairing going on. Previous to this, I’d only done remote pairing for quick knowledge transfers (before going off to work solo or in person with a different pair). The benefits of pairing are well understood, and going remote means that some of […]
When diving into an unfamiliar codebase, it’s tempting to pick one aspect and start exploring it in detail. But that’s like trying to navigate a forest by dissecting a tree. I’ve had to find my way around a few legacy codebases over the last few years. And I’ve learned to start with the 10,000-foot view, […]
I want the code I write to be as easy to follow as possible, and proper documentation is key to accomplishing that. Documentation’s role isn’t to give a full explanation of what the code is doing. Instead, it’s a tool for setting up context. It should give other developers the confidence to move through the […]
At Atomic Object, we work in a lot of existing codebases, editing code written by previous consultants, employees of the client organization, and sometimes even other Atomic developers. The older the codebase, the more inconsistency you’ll find in pattern, style, and organization. This, of course, makes jumping in to do additional work more difficult. I […]
On more than one occasion, I’ve found myself assigned to a project before clearly-defined development tasks were ready. Despite that, I’ve discovered several worthwhile things I can make progress on. 1. Basic Project Skeleton Even when my workflows are all ambiguous, I often have a good idea of what my tech stack will be. The […]
Yesterday, I explained the different ways that errors can be represented in your code. Today I’ll talk about error handling, which is what makes errors such a tricky subject to begin with. Why is error handling so difficult? There are typically many more ways for a system or operation to fail than to succeed. Error […]
Yesterday, I talked about the many types of errors in software and how you can categorize them strategically. Now let’s talk about how you can capture and represent errors in a useful way.
Errors are under-appreciated. I discovered that on a greenfield project when it occurred to me that I had essentially no tools in my developer utility belt for architecting them.
My latest project uses a framework that I wasn’t familiar with at the start of the engagement. It’s not the first time this has happened, but in the past, I’ve always had teammates as tour guides — at least one person on the team had worked in the codebase or with the language before I […]
I just saw a great Twitter thread by Phil Lord, one of the writers of The Lego Movie and Spider-Man: Into the Spider-Verse. I’ve written before about parallels between software and TV/movie production, and the analogy continues to be relevant. There are a few lessons from Phil that can definitely apply to software. 1. No […]