Pragmatic Programmer is a book everyone should read at the start of their career. The earlier the better.
Don't be like me and wait until every lesson is a "Oh yeah, learned that the hard way" ... "Hah yes! That was a fun and painful lesson" ... "ooo good one! I remember a project just like that. Fuck that hurt"
And if you are like me, I suggest reading Pragmatic Programmer anyway.
David Thomas and Andrew Hunt put into words a lot of those little feelings inside your gut that you can't quite verbalize.
When you say "No, we shouldn't do it that way." and someone asks why and you're like "I don't know. It just doesn't feel right."
"it doesn't feel right" is no argument, so your team does it that way anyway. 6 months later the codebase goes to shit and you're like "See! That's why".
But now it's too late.
The Cat Ate My Source Code
“Don’t blame someone or something else, or make up an excuse. Don’t blame all the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses.”
Good-Enough Software
Building software is about trade-offs. Perfect software doesn't exist and the more you chase perfection, the more off target you'll be.
Good enough doesn't mean "sloppy". It means good enough to fulfill all requirements, but no better.
Don't waste time and effort on things nobody needs.
DRY—The Evils of Duplication
DRY – do not repeat yourself, is a maxim of the software industry. Touted as a basic wisdom, it's caused more harm than good over the years.
The beginner thinks DRY and bends over backwards to avoid duplicating her code.
The expert thinks DRY and copy pastes code to avoid duplicating the architecture.
Duplicate your code, not your intent. Just because it looks the same doesn't mean it is the same.
Tracer Bullets
It's hard to hit your target. Especially when you can't see the target.
That's why machine gunners use tracer bullets – glow-in-the-dark bullets loaded as every 5th on the reel. They help you see where you're shooting.
The same works for software.
Build a working happy path version of your program first. That's your tracer bullet.
Users see if you're going the right way, you and your team get a skeleton to hang edge cases off of. This is not a prototype. This is part of your real code.
Prototypes and Post-it Notes
Prototypes are throwaway. You build them to explore a new idea, technology, or architecture.
Do not refactor a prototype into production code. Stay away from shipping a prototype as production code. Despite the business folks protestations of "But it already works!"
Best build your prototypes with post-it notes instead of code. Removes temptation.
Engineering Daybooks
When you code, write down everything
Keep a notebook. Write down your thoughts and ideas. When you get distracted, you can look it up. When you come back to some code 2 weeks later, you can look it up.
As the old proverb from the balkans says: Budala pamti, pametan piše. The fool remembers, the clever one writes.
Don't Outrun Your Headlights
Build only as much as you can test. Run your code early, run it often.
Don't code for 2 hours then see if it works. You'll find it's hard to tell which change broke your program.
Test your code after every significant change.
What's significant depends on many factors. When you're new to a codebase you'll make smaller steps than when it all fits in your head.
Transforming Programming
“All programs transform data, converting an input into an output.”
When you think of code as a series of transformations, your life will be easier. Small discrete steps, rather than large objects and codebases.
Spend an afternoon learning about functional programming.
Inheritance Tax
Inheritance is a trap, often misused, rarely understood.
Are you using inheritance to share code? Try mixins or traits.
Are you using inheritance to build types? The real world never fits a clean taxonomy. Try interfaces instead.
"Can do X" trumps "Is a X".
Shared State Is Incorrect State
Modern computing is full of concurrency and parallelism. Anything you build has to deal with this reality.
Shared state is your enemy.
Immutable shared state and mutable local state are your friends. Avoid relying on state others may have changed.
Programming by Coincidence
Do you know why your code works?
If not, it might be a coincidence. Code that works for the wrong reason is worse than code that doesn't work.
Verify until you're certain.
Coconuts Don't Cut It
Do what works, not what's fashionable.
You are not Google. You are not Facebook, Amazon, Netflix, Apple, or Spotify either. What works for them will not work for you.
Listen to the trends, try their ideas, judge for yourself.
What works for Google in 2020 wouldn't work for Google in 2010. Every team is different. Find what works for you now. Change when it stops working.
Delight Your Users
“Your users are not particularly motivated by code. They have a business problem that needs solving within the context of their objectives and budget.”
Find what your users need, not just what they ask.
The biggest danger to a software team is a client that limits their ask based on perceived software limitations. Encourage clients to ask for their wildest dream. Work together to find a solution.
Their goal is not the tool, their goal is what your tool enables them to do.
And remember, programming is not meant to be safe. It's a life-long lesson in building wisdom and tradeoffs.
Cheers,
~Swizec
Continue reading about My favorite lessons from Pragmatic Programmer
Semantically similar articles hand-picked by GPT-4
- 25 lessons from 25 years of coding
- What I learned from Software Engineering at Google
- The best engineering books get good 5 years into your career
- Don't neglect your upgrades
- 4 years of coding in San Francisco, lessons learned
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️