Have you ever tried to read the documentation for a Postgres command? Although many consider Postgres’ docs best-in-class, they include conventions that might challenge newbies. In this post, I’ll paraphrase Postgres’ conventions page to help us understand what the documentation for a command is saying. To check the syntax of a command, I start with psql, the REPL, or ‘Read-Evaluate-Print-Loop’, of Postgres. I query using \help , and get output like this for update: ...

If I could give one piece of advice to anyone learning to program: build. This advice might be most helpful to beginners. But it’s been valuable to me to revisit at different points in my career. In some ways, this post is for me. Steve Martin once said the secret to success is to “Be so good they can’t ignore you.” How do you get that good as a programmer? The most direct path I know is to build things. ...

Which operating system is the best for programming? This is a perennial question in code boot camps where I’ve taught. I think students see the choice as a fork in the road, and they want pick the right direction. I don’t think there is a right direction. When you’re starting out, my advice is to try each one and choose for yourself. Don’t be this person: “I hate Linux! Full disclosure, I’ve only ever programmed on Windows…” ...

Auto-formatting code is good, and you should be doing it all the time. Why? It helps you write better code in real-time, preempt trivial discussions, and maybe even democratize programming. Better Code in Real-time First, writing better code in real-time: I’ll use the Prettier auto-formatter as an example. I have Prettier running everywhere, auto-formatting on write. This means that each time I write my file, which I do a lot, Prettier attempts to format my code. Neatening my work as I go along helps me think clearly and see refactoring opportunities. ...

Code reviews are important on many teams. Do them well, and your code ships quickly and safely. Do them poorly, and your code ships slowly and riskily. I try to contribute good code reviews. In this post, I’ll share my process. What I Bring First, I try to be nice 😊. There’s a lot of writing about how internet comments can be perceived as less friendly than the author intended, and code reviews suffer from this. The comments are visible to your team, too, so the emotional stakes can be high. Approaching the work with curiosity, saying “thank you”, and adding emojis and GIFs, are little ways to be more human. ...

I think the most important factor in consistent delivery is understanding the work. When you understand the work, you build what the stakeholder wants, better and faster. Here’s an idea that’s not ready for programming work: “Let’s add social login to our website.” Same idea, ready for work: “A logged-out customer sees the Google login button,” with clear acceptance criteria about what that means. In this post, I’ll explain how I go from such a vague idea to a deliverable unit of work. ...

We’ve all seen this: a frustrated coworker hunched over a computer after hours, flailing alone against some impossible bug. Go home, coworker. Don’t stay stuck. I once took a CS course that featured an online puzzle where you had to perform a series of tasks in a seemingly random order to solve it. The solution was not discoverable without brute force. You just tried each step until something happened, and then you tried another. It was maddening, and I gave up. ...

I’ve been using, teaching, and stanning Vim since almost the beginning of my programming career. Yet, when asked to explain this preference, I stumble. In this post, I’d like to explore why I love Vim. Disclaimer: I haven’t used every text editor that has ever existed! I haven’t used Emacs or some of the GUI editors that have come and gone over the years. I’m not arguing that Vim is better than any of these. In particular, VSCode in Vim mode seems to rival Vim in some ways. ...

Today I want to talk about a common technique: disabling failing tests to allow a feature to ship. Maybe sometimes you gotta do it. But long-term I think it causes more problems than it solves. Here’s the scenario: we’re shipping an important hotfix, but there’s one red test blocking a green suite, and thus our deploy. This test is flaky– it’s known to pass and fail on the same commit. Folks on our team are suggesting disabling it. Wanting to be a team player, we disable the test with a short commit, “Disable this test for now” and ship our code. ...

Here’s a trick that that has helped me as a programmer: before doing anything major, like killing a process, stop and count to ten. I learned this in IT. When a screen froze, the IT professionals I worked with would stop and count to ten before taking action. You’re watching a process run, it seems to have frozen, and you’re getting no instructions. Before killing it, stop and count to ten. If the process is still hanging after that, kill it, if you must. ...