When possible, I prefer to use the presence of data to represent a boolean, rather than a boolean itself. Example: Error State Here’s a bug vector I see a lot in frontend code. Imagine we’ve made a network request that returns an error. Our code sets a boolean errorState, meant to convey “we are in an error state”, to true. Then we display an errorMessage in that condition: if(isErrorState) { displayMessage(errorMessage) } The problem here is that we now have two variables tied to our error condition: isErrorState and errorMessage. And when that happens, it’s easy to put the app into one of these illogical states: ...

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. I think a mark of a mature engineer is having strong opinions, weakly held, that you can articulate. Having some experience is a conundrum. You know a lot of good and bad ways to do something, but you can’t just download your expertise onto someone else. If you don’t share it wisely, it’s easy to sound pessimistic, preachy, or arrogant. ...

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. For every person who takes the time to fill out your support form, there are many more who just gave up, found a janky workaround, or possibly abandoned your product altogether. It costs them nothing to move on. You might not like the message, or how it was delivered, but you are still lucky that they spoke up. ...

What should you focus on at the beginning of your programming career? My unflashy answer is: being really good at programming. “Be So Good They Can’t Ignore You” My thoughts here are borrowed from Steve Martin, who advises entertainers to “be so good they can’t ignore you.” When you’re objectively great at your job, things start to get easier. Programming is tough. There is an insane amount to learn across languages, platforms, and tools. You’re going to be building mental models, pushing your limitations, and considering counter-intuitive ideas. Just when you think you’ve got it all figured out, it changes. ...

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. Who Cares? Wait; who cares? Isn’t this like discussing the color of the bike shed? Years of programming with other humans has taught me that, for loosely-defined tasks like this, any convention is better than no convention. Without it, you’ll see in many, many codebases: ...

When I review code, I sometimes request that refactoring changes be removed. Even when I think the changes are objective improvements, and even when they support my personal preferences. My reasoning? Refactors are not free. In this post, I’ll list a few times when I think a refactor is worse than leaving the code unchanged. No automated tests Do you have automated tests? Can you run them? Do you trust them? If you don’t, don’t refactor. ...

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. Tutorials are fun: you get to work through tough problems, like building an application with authentication, social posts, and tests, and learn to deploy to production. It feels like you’re accomplishing something. ...

Working at a quality software development consultancy like Hashrocket early in your programming career could be a game-changing move. For background, I worked for six and half years at Hashrocket in Chicago. I started as an apprentice and left as a senior developer. I worked with brilliant people on interesting, challenging, and profitable products. I got to write Ruby, Elixir, Node, React, SQL, and even some PHP, spoke at RailsConf and ElixirDaze, and drove internal projects. ...

Today I’d like to explain the sub, or subject, registered claim of a JSON Web Token. Registered claims are predefined fields of the JWT that are not mandatory but recommended. Like all JWT claims, they must be unique. sub is the subject of the JWT– the user who requested the token, typically an email address. By using it, we can send and receive a small, unique piece of data about a user along with each request, without any additional requests. ...

Let’s look at the proxy pattern in Ruby. Here’s a Ruby class that claps: class Hands def clap "👏" end end And here’s me using an instance of it to do something surprising. >> 3.times { hands.clap } "👏" "👏" "👏" => 3 >> hands.times_called(:clap) => 3 times_called is not defined in Hands, or any parent of it. So what gives? Did I leave it off the first code block? What’s going on here? I recently learned about and had the opportunity to implement a proxy class. In this post, I’ll share what I learned, showing how hands gets this special behavior. ...