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.