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.
“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.”
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 – 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.
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 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.
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.
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.
“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 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".
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.
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.
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.
“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.
Here's how it works 👇
And get thoughtful letters 💌 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. 👌"
Ready to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization
Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.
Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️