One of my all-time favorite programming tools is Dash by Kapeli. In this post, I’ll share some tips for leveraging this fantastic program. The ideal audience for this post is someone who uses Dash and wants to use it better. But in case you haven’t tried it yet, let me answer: what is Dash? What is Dash? Dash is a MacOS application that offers offline access to, and a user interface for searching, hundreds of API documentation sets. ...

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. ...

I believe that luck is part of every professional journey. Here’s a sampling of the luck I’ve had. A passage I recently read caught my attention: “One of the first things [Stewart] Butterfield [(founder of Slack)] wants to know about when interviewing candidates for a position isn’t which programming language they know or where their computer science degree is from. It’s whether they believe luck played a role in getting them where they are– whether they think their success is a product not just of merit and talent, but also good circumstances. His goal is simple: to build a team where people don’t assume they’re special.” –Sara Wachter-Boettcher, ‘Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech’, 190. ...

This is a list of all the best debugging tips I’ve picked up over the years. Some of these might seem obvious, yet we forget them when it counts. Debugging is a skill. You have to bring every tool you have to the job. 🚀 Update: this became an e-book! Don’t Stay Stuck: A Debugging Guide for Rising Engineers is my concise, actionable guide to debugging like a pro. Check it out! ...

My development environment depends on several processes running. Here’s how I’ve scripted this setup. Whenever I boot up, I need at least these processes running: Sidekiq (jobs) Rails (API) Webpack (frontend) Docker (containers) Here’s how I’ve scripted it: #!/bin/bash tmux new-window -n sidekiq tmux send-keys -t sidekiq 'sidekiq' Enter tmux new-window -n rails tmux send-keys -t rails 'rails s' Enter tmux new-window -n webpack tmux send-keys -t webpack 'bin/webpack' Enter tmux new-window -n docker tmux send-keys -t docker 'bin/docker' Enter open http://host.docker.internal:3000/ This starts each process in its own named Tmux window, then opens the application in my browser. That last step is a losing race condition with the other processes, which are still booting, but I just wait a few seconds and refresh the browser tab. ...

Perhaps you’re familiar with this scenario: you’re debugging and stuck. You’ve Googled, read some blog posts and docs. You return to your search engine, type some characters, and then something strange happens: the search engine autocompletes your question, and the results are all purple because they have been visited by you. I’ve come to recognize this moment as always a symptom of a broken mental model. A broken mental model is a fundamentally flawed understanding of how something works. It derails problem-solving by leading us to ask bad questions. Bad questions beget bad answers. ...

Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these. Why Are They Important? Action items steer a retro away from conversation and toward action. I once worked with an engineer who ran retros among all the contractors on the project. He’d push for action items after every discussion, saying: “I want to respect everyone’s time by making sure this leads to action.” ...

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: ...

I think a great database migration is: correct, atomic, reversible, consistent with the style of the application, and (mostly) uncoupled from your application and RDBMS. These ideas are framework-agnostic, but as an example, we’ll use this migration from the Ruby on Rails documentation: class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end end end Correct After running each migration, it’s important to inspect the database schema to ensure that the correct changes are present. I’ve seen many pull requests, and opened a few myself, where the migration and the schema tell competing stories. ...

When printing a JavaScript value to the console, I suggest using an object literal over the raw value. // Okay console.log(response) // Better console.log({ response }) It’s a little thing that over time has a big benefit. In this post, I’ll explain this technique and describe why I find it useful. First Iteration: The Raw Value Imagine you have a value assigned to the variable response, and you want to know its value. Here’s how you might print it to the console, with console.log. ...