Essays on Programming I Think About a Lot

- 11 minutes read - 2236 words

Programming is a new and abstract field, and so we place great emphasis on ideas. When I find one that sticks with me, I end up sharing it again and again. These are some of my favorites.

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 “I Found a Bug in React”, and a question that starts with: “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. Your brain is great at reinforcing flawed logic, but your mouth isn’t.

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. There’s a risk to staying in your first couple of engineer jobs for more than a few years. You’ll advance to titles like ‘Mid-Level Engineer’ just by showing up and collecting institutional knowledge, but your growth might also plateau. True seniority is earned by moving around and proving 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: state the problem, your assumptions, and what you’ve tried and learned. Show them all of your logic so that they can poke holes in it.

Remember that if your diagnostic theories were accurate, you wouldn’t be asking for help right?

This aligns with 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 vital. I believe we as a community place far too much value on new tools. 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

I liked this idea so much, I’ve adapted it as a general programming principle.

Elisabeth Hendrickson, ‘Momentum > Urgency’. Effective teams focus on the process, not the outcome. A blocked story isn’t a distraction from the process; it is many or all of the problems in the process distilled into a single obstacle. Effective technical management will unblock 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 easy to assign three boolean variables in state called loading, error, and complete, and then create a world where all three are 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 best 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 and completeness of an 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. Don’t show them something 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 worked again and again on 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 even 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.

Shawn Wang, Preemptive Pluralization is (Probably) Not Evil. YAGNI (You Aren’t Going to Need It) is a tenet of 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

Consider 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 the user table. However, every system of significance ends up with multiple roles such as employee or super-admin, at which point the column solution becomes more complex than a relationship. It’s that exceptional case where premature optimization is pragmatic.

Kent C. Dodds, AHA Programming. The AHA (Avoid Hasty Abstractions) concept has had a huge impact on my development approach. 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

Kent’s Avoid Nesting When You’re Testing applies this advice to automated tests. Many of the refined refactoring techniques we learn are not appropriate in a test. Choose explicit and dumb over abstracted and clever.

When to break up a component into multiple components applies this advice to frontend components. To summarize: breaking up components is always tradeoff; don’t do it until you’re feeling a pain.

Paul Graham, Schlep Blindness. Fixing online payments was a massive business idea that was just waiting to 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 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 feels 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.

Sarah Mei, Pairing with Junior Developers. Don’t type. Driving as the senior seems like the kind thing to do, but to learn programming you have to get into the deep end and flail for a while. With the supervision of a seasoned lifeguard, of course. They’ll thank you later (thanks Jack!).

The only way they’re going to learn is by doing it themselves, and that means they type and they move the mouse. Yes, you’ll go slowly. And yes, sometimes it will be maddening. But junior devs don’t learn anything by watching someone else program. – Sarah Mei

Jeff Atwood, The Joy of Deletion. With version control, no code is ever gone, and so 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

Thorston Ball, Two Types of Software Engineers. Makes the argument that there are two types of engineers: those who think ‘people problems’ are easy, and those (wiser programmers) who think ‘people problems’ are the hardest problems of all.

I’ve worked on teams where many technical problems have a ‘people solution’ that’s somehow constantly failing.

Teammate: “Please remember everyone: when this Slack channel’s description is a red circle, don’t merge code!”

Me: “Okay. What happens when I don’t see that, or Slack is down, or the description is out of date, or…?”

Zed Shaw via Abhishek Nagekar, Advice From An Old Programmer. There will come a day when you find programming to be a little bit boring. It will cease to be joyful as an exercise. What do you do then? It’s a question I’ve grappled with. I’m choosing to use that skill to build things I care about and help others 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

Conclusion

I plan to keep this list updated as I continue to read and think. Thanks to each author on this list for inspiring me and helping me refine my thought process. And thanks to Ben Kuhn for this blog post idea.