Published: October 29, 2020 • Updated: November 30, 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 tend to think about and share it a lot.
Here are some of my favorites. 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. 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. The best way to get unstuck is to explain what you’re thinking out loud.
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. You’ll advance in collect title (‘Engineer’, ‘Engineer II’) just by showing up and acquiring institutional knowledge. But you will quickly plateau. True seniority is earned by moving around and continuing to grow 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. 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. Picking the right technology with which to build your project is massively important. 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’ (unable to find online as of 11/5/22). 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 world where all three are
inexplicably true. 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 whether I’m communicating with the most impactful tool I have.
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 represents a fraction or none of the true functionality, completeness, and complexity of the application. People who don’t write software don’t automatically know that.
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 detail you add to the visual design of software implies a working or in-development feature in the eyes of some stakeholders. For those particular stakeholders, don’t put something in the design that you can’t build.
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 improved 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 reduces tons of
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 overlap between these competing 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 with multiple
roles such as ‘employee’ or ‘superadmin’, at which point the column solution
becomes more complex than a relationship. It’s that exceptional case where
premature optimization is actually the right choice.
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
Avoid Nesting When You’re Testing applies this advice to automated tests. Many of the refined refactoring techniques we learn are surprisingly counterproductive in a test. Choose explicit and dumb over abstracted and clever.
Paul Graham, Schlep Blindness. Fixing online payments was a massive business idea that was just waiting be solved, so why didn’t anyone solve it before Stripe? Because it was a hard problem. It presented tedious drudgery and unknowns. Paul argues that our brains hide these problems from us because they want to protect us from failure.
What’s the workaround? Think about problems that you wish someone else would solve.
Your unconscious won’t even let you see ideas that involve painful schleps. That’s schlep blindness. — Paul Graham
Adam Wathan, CSS Utility Classes and “Separation of Concerns”. Makes a thoughtful case against the dominant CSS strategies of today, and for a functional, utility-first style exemplified in Wathan’s library TailwindCSS. 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 tech-debt-ridden application is tempting, but it doesn’t change the fact that your team’s processes created that 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 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.
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 other get better through mentorship and 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. Thanks to each author on this list for inspiring and helping me refine my thought process.
Get better at programming by learning with me. Subscribe to my newsletter for weekly ideas, creations, and curated resources from across the world of programming. Join me today!