Software-Engineering

When it comes to controlling frontend presentation, developers often rely on booleans. However, this approach can be limiting. In this post, I’ll explore the drawbacks of using booleans and introduce a more versatile alternative: plain old strings with type safety. While this example uses React, the principles can be applied to other frontend frameworks as well. The Setup The React useState hook gives us local state, and it’s often instantiated with a boolean. Open any complex React codebase, and you are sure to see something like this: ...

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton Let’s talk about variable name antipatterns! I use the term ‘antipattern’ a lot on this blog. To make sure I’ve defined it at least once, an antipattern is a technique that seems good but has more bad consequences than good ones. These are antipatterns because they often make sense in isolation and can propagate through a codebase, to the detriment of developer experience and maintainability of the codebase. If you’re interested in a similar take on this idea but from the ‘pattern’ perspective, check out Pick a Good Name on the Hashrocket blog. ...

Great developers review their own code often and effectively. In this post, I’ll share a checklist of all my best tips for maximizing this important practice. 1. Wait As Long As You Can Wait as long as you can before reviewing your code. In On Writing, Stephen King recounts that when he finishes a first draft, he puts it away and doesn’t look at it for a long time. The closer we are to our work, the harder it is to see its flaws. ...

Some advice I offer people entering the programming profession is to buy the best hardware you can. You’re going to need it. Get the most powerful computer, the biggest monitor, the best keyboard, mouse, headset, microphone, and webcam your budget allows. If you have to choose one, invest in the computer and collect the peripherals later. In other desk jobs, there’s a frugality about hardware. “I’m just editing spreadsheets– I don’t need a powerful computer.” Programming is different. It’s resource-intensive work. In the web development, not only are you running multiple servers and processes, you might be running containerization software, multiple browsers, automated tests, and supporting tools like documentation and screenshot software. ...

The exit code of a command in a Unix-based system is an important and easy-to-miss piece of data. It isn’t printed to standard out; you have to go looking for it. I find it useful to inspect this information when debugging or considering chaining unfamiliar commands. To see the exit code of your last command, echo its variable ($) value: $ echo "something" "something" $ echo $? 0 # Success! # '1' example $ rm nonexistent-file rm: nonexistent-file: No such file or directory $ echo $? 1 # Failure. The two exit codes you must remember are 0, command was successful, and 1, a catch-all for errors. Zero is success, not-zero failure. ...

Trying to enforce unconventional coding preferences on a team is an uphill battle. When in doubt, default to convention. Contrived Example Consider this contrived example. Imagine that you don’t like Ruby on Rails delegators, which let you call a method on an instance through another instance. Here’s an example: class Greeter < ActiveRecord::Base def hello 'hello' end end class General < ActiveRecord::Base belongs_to :greeter delegate :hello, to: :greeter end General.new.hello # => "hello" .hello is not defined on class General, yet we can call it because it is delegated to Greeter. Pretty cool! ...

How do you introduce new ways of working? We want to bring a new idea to our engineering teams, such as a new command-line configuration, testing tool, or design pattern. But engineers can be discerning and stubborn customers. The idea needs to stand on its own. And, you have to sell it. Here are some approaches that I’ve tried to introduce new ideas to a team. Combine them all, and you’re on a good path. ...

When testing with data, I prefer realistic data rather than random data. Here’s the common pattern I’m challenging: when testing forms, data presentation, or even seeding data, a programmer (often in a rush) will enter gibberish or jargon instead of something like a real user would enter. An example might be an address form, where we mash some combination of the home row letters into each field. In this case, I prefer to enter “123 Milwaukee Ave.” or similar into the first address field, “Chicago” in the city field, and so on. ...

There’s almost always a better variable name or value than ‘foo’. It’s useful as a debugging placeholder, but it almost never belongs in production code, even and especially in automated tests. What is ‘foo’? The Jargon File calls ‘foo’ a metasyntactic variable: “[a] name used in examples and understood to stand for whatever thing is under discussion, or any random member of a class of things under discussion.” Two programmers stand at a whiteboard, working on an authentication feature. One says: ...

We’ve all seen a desire path. They are footpaths created by erosion from human and animal traffic that communicate a wish for a path that doesn’t exist. When you walk on a paved path toward a destination and notice a shortcut in the earth, that’s a desire path. It’s the way people go, rather than the way we would wish them to go. I once read about an architect who omitted footpaths in a college campus design. They built and opened the campus without them. Then, they waited for a year for the desire paths to appear. When they did, the architect paved those paths, reflecting the desires of the campus users. ...