Hard-coded test expectations have many benefits that I’ll explore in this post.

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

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.

Me: Hey, I’m experiencing an issue with your software. Here’s a detailed bug report.

SAAS Engineer: What you’re describing isn’t possible.

Narrator: But it was possible.

This is a frustrating, unproductive snippet of a conversation I’ve had a few times in my career. What can we learn? Treat bug reports like gold.

What should you focus on at the beginning of your programming career? My unflashy answer is: being really good at programming.

The import statements at the top of a JavaScript component file can be a confusing, duplicative, churning mess. Is there a way to organize them that makes sense and scales? In this post, I’d like to share the way I handle this detail.

When I review code, I sometimes request that refactoring changes be removed. Even when I think the changes are are objective improvements, and even when they support my personal preferences. My reasoning? Refactors are not free.

Here’s a scenario: you’re applying for your first tech job. You’ve found a bunch of hands-on tutorials and you’re speeding through them. When you finish, you upload the code to Github and add a new line to the ‘Projects’ section of your resume. Maybe you even deploy the code as a production website. My advice: stop.

Working at a quality software development consultancy like Hashrocket early in your programming career could be a game-changing move.

Today I’d like to explain the sub, or subject, registered claim of a JSON Web Token.