Here’s my list of favorite programming books. It’s been said that most programmers read less than one professional book per year. I get it. Books about programming can be have short shelf lives, as well as be expensive, hard to find, and challenging to read. But in my experience, great programmers have read a lot of them anyway. There are concepts defined in classic programming books that are ubiquitous in the field. When you read those books yourself, you absorb those concepts. Or at least develop informed critiques of them. ...

I’ve practiced TDD (Test-Driven-Development) for years and feel knowledgeable about when it’s useful and when it isn’t. In this post, I’d like to summarize what I’ve learned. My definition of TDD It’s worth mentioning first that there are different versions of TDD. There’s outside-in or black-box TDD, red-green-refactor, BDD, ATDD, and more. They’re all in the same family, but they are distinct. Getting to caught up on terminology can quickly distract from the core concepts they share. ...

I’ve been doing Exercism’s TypeScript exercises, and wanted to share my pangram-checking utility. A pangram is a sentence that contains each of the 26 English letters at least once. Here’s my TypeScript class to determine if a sentence is a pangram. class Pangram { input: string; constructor(input: string) { this.input = input.toLowerCase(); } isPangram(): boolean { const letters = this.input.replace(/[^a-z]/g, ''); return new Set(letters).size === 26; } } export default Pangram; isPangram/0 does the work: replacing all characters not a-z with empty strings (the sentence is already lowercase), breaking the string apart via new Set, and comparing the size to 26. 26 is a borderline magical number, but it’s such a famous one in the English language that I think I get away with it.

A few weeks ago, I built an app with React and create-react-app that I call ‘JavaScript Equality’. View deployment here. This application demonstrates the JavaScript value-comparison operators == and ===. It’s inspired by the JavaScript Equality Table. The image above shows why the threequals is superior to the twoquals equals. If you want true equality, the kind of logic you’d expect with any other programming language, use threequals. My favorite implementation detail of this app is the data model, which is created in the constructor function: ...

My current favorite command line alias is mgrim, composed of four other aliases. Here’s what it is, and what it does. alias gmr='gco master && gpr && gco - && git rebase master' alias grim='git rebase -i master' alias mgrim='gmr && grim' Starting from a feature branch: gmr - checkout the master branch (gco is a Hashrocket alias for git checkout. Pull from origin/master and try to put my commits in the right place in history (gpr is a Hashrocket alias for git pull --rebase). Checkout my feature branch. Fast-forward my branch to the top of master (as though I had branched off master’s current HEAD. grim - Open an interactive rebase to cleanup everything on my branch (see ‘Squash Your PR’) I use feature branches for work, and use this command right before merging into master. The result? I’m always forced to look at my branch history and squash it down to the minimum, which is good for everyone (including future me). And, I never have a merge conflict with master.

A user opened an issue in Tilex last week that I spent a significant amount of time thinking about and talking about (thanks JB) before responding to. Here’s the truncated request: May I ask you to compile a step-by-step list to set up a running TIL instance? Tilex Issue #286 I knew the answer was ’no’, but I reflected on my answer for a long time. When does documentation become too specific? What’s a fair request of an open source project maintainer’s time? How do I decline a request while still thanking the requester and making sure the interaction remains positive? ...

Recently I tried to answer a question that I think is common to consider when you’re first learning about computer programming. I’ll paraphrase: Why can’t there be an “universal” programming language that serves all purposes? The number of programming languages in the world is dizzying. Names like JavaScript, Ruby, and C are known by programmers and non-programmers alike. Since technology constantly evolves, and learning many things takes more time than learning one thing, wouldn’t a reasonable expectation be that we’ll all someday coalesce around an ideal language, that’s perfect for every situation? ...

I’ve been giving technical talks for a few years, and I’m speaking at the Vim Chicago Meetup next month about integrating React with Vim. In this post, I’m going to use that opportunity as an excuse to document my speaking process. Some smart people have written on this subject, and anything I’d have to say is partly inspired by these ideas: Conference Prompts: Or How to Submit Proposals and Influence People How to Prepare a Talk Improve Your Presentations In Under $50 Speaking.io What I learned from reading 429 conference proposals What Your Conference Proposal Is Missing Several of these writers talk about submitting conference proposals, AKA CFPs. I don’t plan to cover that in-depth. Why not? I believe once you can write a compelling proposal, getting accepted is the product of a variety of factors you can’t control. So, submit many proposals, and be like Thomas Jefferson, who once said: “I’m a great believer in luck, and I find the harder I work the more I have of it.” And in the meantime, learn to give a great talk. ...

As soon as you can, just do the thing you have to do, and respond with: “It’s done.” When a stakeholder asks for a change to the software I’m building, my typical responses are, in order: “Got it.” Then: “I’m working on that issue.” Finally: “It’s done.” Here’s an alternative: skip the first two conversations and go straight to the third. Ship, then signal. Underpromise; overdeliver It’s a variation on the idea of “Underpromise; overdeliver.” In this case, by waiting to respond, I’m promising nothing, the most under of underpromises. And I over-deliver by shipping when the stakeholder is least expecting it. ...

There’s a detail about Today I Learned some might find unusual: we never added a way to delete posts from the site. Why ignore a basic CRUD feature? We didn’t ignore it. It was intentionally omitted. I’ve thought about this decision a lot over the last two years. It’s lasted over many pull requests, issues, forks, and discussions. I addressed it directly in a Github issue not long ago. Preventing deletes was a hack to make Today I Learned feel permanent. If the goal of the site was to show the world what we at Hashrocket are learning, why allow people to self-censor that journey? The temptation to obsess over your output until it’s a flawless diamond of competence is too great, especially among high-performing programmers. ...