Published: October 29, 2020 • Updated: July 04, 2022 • 10 min read
Programming is a game of abstractions, and we programmers traffic in ideas. When I find an idea that resonates with me, I turn into an evangelist for it to everyone who works with me.
Here are my favorites. Some of these essays are purely about technology, and some are about programming culture. The longer I work in this field, the more these two domains merge in my mind.
Thanks to Ben Kuhn for this idea.
Jeff Atwood, The First Rule of Programming: It’s Always Your Fault. I like to answer questions on Stack Overflow, and an amazing amount of questions on that website have a title like “Found a bug in React?” followed by: “I’m brand new to React.” It’s human to assume there’s a problem with your tools. This essay’s message to me is that it’s more profitable to assume that you are wrong, because your code hasn’t stood up to anything close to the scrutiny of a popular software project.
If you truly aspire to being a humble programmer, you should have no qualms about saying “hey, this is my fault— and I’ll get to the bottom of it.” — Jeff Atwood
Shawn Wang, Learn in Public. Be public, leverage the encouragement and criticism of others, and build a footprint for yourself on the internet. The fastest path to expert beginner status is hiding your work in an attempt to avoid criticism. Learning in public lets you leverage the adage: “the fastest way to get the right answer to a question is to post the wrong answer on the internet.”
People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. — Shawn Wang
David B. Hayes, Rubber Duck Debugging: The Psychology of How it Works. Trying to understand these ideas, which humans aren’t inclined to understand, has been the most positive influence overall on my debugging skills.
Because of the psychology of how we humans relate, you’re forced to think fresh when you invoke your little rubber ducky, and your problem may be quite simply solved. — David B. Hayes
Charity Majors, The Trap of the Premature Senior.
Don’t stay in your first couple of developer jobs for more than a few years. On many teams you get promoted in title (‘Junior Engineer’, ‘Engineer’, ‘Engineer II’) just for showing up and acquiring institutional knowledge. It’s a trap. True seniority is earned by moving around and continuing to grow and prove yourself on several teams.
After you have gotten a new job or two, and proven to yourself that you can level up again and master new stacks and technologies, that fretful inner voice questioning whether you deserve the respect you receive or not will calm down. You will have proven to yourself that your success wasn’t just a one-off, that you can be dropped into any situation, learn the local ropes and succeed. You will be a senior engineer. — Charity Majors
XY Problem. When you’re asking for programming help from someone, start by easing them into your situation, stating the problem, your assumptions, and what you’ve tried and learned. Start from the beginning and give them the chance to poke holes in all of your logic.
Remember that if your diagnostic theories were accurate, you wouldn’t be asking for help right?
This echos one of my favorite quotes about feedback:
If, instead of seeking approval, you ask, ‘What’s wrong with it? How can I make it better?’, you are more likely to get a truthful, critical answer. — Paul Arden
Dan McKinley, Choose Boring Technology. As I’ve cycled through side projects in Phoenix, Rails, and React this year, this post has resonated with me. Picking the right technology with which to build your project is massively important, and I believe we as a community place far too much value on tools that are new. How do we make pragmatic choices? Consider Dan’s concept of ‘innovation tokens’:
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. — Dan McKinley
Elisabeth Hendrickson, Momentum > Urgency. Effective teams focus on process, not outcome. A blocked story isn’t a temporary distraction from the process, it is the process. Effective technical management will focus on it like a laser.
What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency. — Elisabeth Hendrickson
Matt Pocock, State Management: How to tell a bad boolean from a good
boolean. This post upended how I think about booleans in state. It
is too easy to assign three boolean variables in state called
complete, and then create a situation where they are all true
and words have no meaning. Booleans are an overused primitive in all of
programming, and this post is the way out.
Bad booleans represent state. Good booleans are derived from state. — Matt Pocock
Scott Hanselman, Do they deserve the gift of your keystrokes? This post isn’t just for programmers, but the statistical nature of it resonated with me. Since reading it, I often consider the reach of my chosen communication method, and whether I’m making efficient use of time.
Assuming you want your message to reach as many people as possible, blog it. You only have so many hours in the day. — Scott Hanselman
Joel Spolsky, The Iceberg Secret, Revealed. Programmers know that what we can see on a web page can represent a small fraction or none of the true functionality, completeness, and complexity of the application. People who don’t write software don’t automatically know that. Factor this into all communication.
Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it. — Joel Spolsky
Understand that any demos you do in a darkened room with a projector are going to be all about pixels. If you can, build your UI in such a way that unfinished parts look unfinished. — Joel Spolsky
A quote I find relevant, from It’s Not How Good You Are, It’s How Good You Want To Be by Paul Arden: “The more strikingly visual your presentation is, the more people will remember it.” Every visual detail you add will translate to a working, MVP feature in the eyes of some stakeholders.
Paul Slaughter, Conventional comments. I believe code reviews can raise quality, share information, and help people grow. But they can go wrong in so many ways. This technique– labeling comments to help the recipient contextualize your feedback– has had a positive impact on several teams I’ve been a part of.
Labeling comments saves hours of undercommunication and misunderstandings. They are also parseable by machines! — Paul Slaughter
In Bitbucket and Github, you can take the
suggestion: prefix a step farther
by embedding a code suggestion in your comment. If the reviewer likes your
proposal, they can click a button and merge your change! This really reduces
the extra conversation around a suggestion.
Shawn Wang, Preemptive Pluralization is (Probably) Not Evil. YAGNI (You Aren’t Going to Need It) is a tenet my programming practice; it’s better to build something simple when we don’t know much about a system. Yet I also seek future-proof designs. This post tries to identify the boundary between these concepts.
Before you write any code — ask if you could ever possibly want multiple kinds of the thing you are coding. If yes, just do it. Now, not later. — Shawn Wang
I think of user roles. Let’s say we need to add a concept of a user having
admin privileges in a system. Rather than adding a
roles table with one
‘admin’ record, the YAGNI approach would be to add an
admin boolean column on
user table. However, every system of significance ends up adding more
roles, such as ‘employee’, ‘engineer’, or ‘superadmin’, at which point the
column solution becomes more complex than a relationship. It’s is a rare case
where premature optimization is actually not evil.
Kent C. Dodds, AHA Programming. The AHA (Avoid Hasty Abstractions) concept has had a huge impact on my development approach in the last few months. Kent quotes Sandi Metz as an inspiration: “Prefer duplication over the wrong abstraction.” I’d add two more favorite Sandi quotes to the mix: “We’ll never know less than we know right now,” and so you should ”[a]lways delay making design decisions until you need to.” DRY is a technique, not a law of nature.
Now, don’t get me wrong, I’m not suggesting anarchy. I’m just suggesting that we should be mindful of the fact that we don’t really know what requirements will be placed upon our code in the future. — Kent C. Dodds
Paul Graham, Schlep Blindness. Fixing online payments was a massive business idea that was just sitting there, waiting be solved. So why didn’t anyone solve it before Stripe? Because it was a hard problem, full of tedious drudgery and unknowns. Paul argues that our brains want to protect us from failure, and thus won’t even let us see these kind of problems.
Your unconscious won’t even let you see ideas that involve painful schleps. That’s schlep blindness. — Paul Graham
What’s the workaround? Think about problems that you wish someone else would solve.
Adam Wathan, CSS Utility Classes and “Separation of Concerns.”. Makes a thorough, thoughtful case against the dominant CSS strategies of today, and a case for a functional, utility-first style exemplified in Wathan’s library TailwindCSS. I’ve fought some of these battles myself, the advice rings true, and the patterns he describes feel really comfortable to me.
When you think about the relationship between HTML and CSS in terms of “separation of concerns”, it’s very black and white. You either have separation of concerns (good!), or you don’t (bad!). This is not the right way to think about HTML and CSS. Instead, think about dependency direction. — Adam Wathan
Erik Dietrich, The Myth of the Software Rewrite. Most of the time it’s preferable to salvage an existing application than rewrite it. Rewriting a technical-debt-ridden application is tempting but it won’t change the reality that your team’s processes create technical debt.
If you have a crew of people that have built you a crappy table, and they’re telling you the only way to fix the situation is to let them build you another table, don’t believe them. — Erik Dietrich (from the comments)
Another great read is Things You Should Never Do, Part I, which makes a similar argument using Netscape 6.0. Introduced the concept “it’s harder to read code than to write it” to my vocabulary.
Jari Komppa, Don’t ask to ask, just ask. In remote communication channels like Slack, if you have a technical question, just ask it. A direct question shows that you’ve thought about the problem somewhat and aren’t passively waiting to be rescued.
The solution is not to ask to ask, but just to ask. Someone who is idling on the channel and only every now and then glances what’s going on is unlikely to answer to your “asking to ask” question, but your actual problem description may pique their interest and get them to answer. —Jari Komppa
Jeff Atwood, The Joy of Deletion. Unused code should be deleted, not commented out or otherwise set aside for future use.
I say, give me a reason not to delete it, and I won’t. Otherwise, it’s fair game. In my experience this kind of “oh, I’ll get back to it” code just sits in the codebase forever, junking up the works for every future developer. —Jeff Atwood
Zed Shaw via Abhishek Nagekar, Advice From An Old Programmer. There will likely come a day when you find programming to be a little bit boring. It will cease to be joyful as a pure exercise. What do you do then? It’s a question I’m grappling with. I’m choosing to use that skill to build things I care about, and help others become programmers through volunteering.
Programming as a profession is only moderately interesting. It can be a good job, but you could make about the same money and be happier running a fast food joint. You’re much better off using code as your secret weapon in another profession. — Zed Shaw
I plan to keep this list updated as I continue to read.
✉️ Get better at programming by learning with me. Subscribe to Jake Worth's Newsletter for bi-weekly ideas, creations, and curated resources from across the world of programming. Join me today!
Blog of Jake Worth, software engineer in Maine.