Your code doesn't matter. Your tools are irrelevant. Shipped beats perfect.
Your code doesn't matter. Your tools are irrelevant. Shipped beats perfect. https://t.co/UXW274kR3h— Swizec Teller (@Swizec) March 15, 2019
That's the biggest lesson I learned working in the heart of Silicon Valley. Outside your team, nobody cares about your code.
Your line breaks don't matter. Your single quote, double quote, or backtick debate is a waste of time. Named arguments or not, short functions or long, fat views or models, single file or many, React or Vue, NoSQL or Postgres, ...
None of it matters.
You know what matters?
Did you find customers? Do they enjoy your product? Are they paying? Are you improving the lives of hundreds of people or thousands?
That's what matters.
How many lives has your code improved?
Until you work on that, nothing else matters.
My former CTO once explained to me when I huffed and puffed into our 1-on-1 that our codebase is terrible and hard to work with and that if we don't do something quick, we soon won't be able to ship features anymore! What would the engineering team come to, if all we ever do is trip over ourselves and our shitty code?
"Look mate, we don't even know if we're gonna be alive in 6 months. What code quality? What impending doom? Just do your best, work around the issues, and let's survive first"
He was right.
You are a talented engineer. You're paid a lot of money. Your job is to keep the duct tape and chewing gum charade going long enough for the business people to even figure out what they want.
Companies and products go through stages.
At first everything is a prototype. You build it. Try it out. See if it works.
Then you rip it out and try something else.
How well must you engineer something you're throwing away 3 days after deploy because customers hate it?
Sometimes your prototype survives, hits its stride, and you're left dealing with your own mess for the next 3 years.
That's a good thing!
If you don't feel bad looking at your old code, you're not growing. Fact. Your old code always looks like crap.
Old code that isn't shitty was over-engineered the first time around. You want to ship prototype code. Faster iterations, faster learning, company/department/team more likely to survive.
You'll fix the code later, if it proves itself.
That's a platitude. You won't have time. You'll be working on a million other things :P
To all my over-engineerers and overthinkerers 👇— Swizec Teller (@Swizec) October 9, 2018
We are currently logging over 500,000 events per day to a PostgreSQL database running on a single Heroku instance. The table has over 300,000,000 rows.
Don't worry about scale. Stuff scales. pic.twitter.com/BljZ0dHkdu
So when do you fix old code?
When it breaks. When it tells you where it hurts.
Would you put a cast on your leg just in case? Maybe you'll get in a car crash and break it. Good thing the cast is already there!
Sounds silly right?
Yet we do that with code all the time. An article made the rounds recently: You are not Google.
"Oh noes I better build for scale! I need Hadoop and a million microservices, and I better engineer this real good. What if we get a million users all at once and our Ruby On Rails app buckles?"
To quote Rob Pike's 5 Rules of Programming: N is usually small.
Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Build it the most obvious simplest way first. When that breaks, make it more complicated, if you have to. Simple systems are easier to fix and they break less often.
Optimize for simplicity, not speed or scale.
You can often make an unsolvable problem solvable by relaxing constraints. When the business people say "the best", they often mean "good enough". When they say "guaranteed" they often mean "unlikely".
There is a world of difference between writing software that works well enough in the real world and software that is provably always correct in the mathematical sense.
You likely don't need perfection. Ask.
Can you ship on time?
Does it work when you ship?
Do your customers love it?
Do you have customers?
Can you add features?
Can you fix it when it breaks?
Not if, when.
Can your team work on your code when you can't?
Optimize for those and you'll be fine. Write code anyone can understand, write code that's easy to expand, write code that's easy to fix.
Omg it's my anniversary month!— Swizec Teller (@Swizec) April 12, 2019
4 years since I moved to San Francisco
4 years since I launched React + D3
4 years living with Girlfriend
4 years of being a very settled "digital nomad"
4 years with Kiwi 🐣
Any interest in a lessons learned article?https://t.co/D2aSkS9p4o
When I first moved to San Francisco a lot of friends back home poked fun at me. It's too expensive they said. It's not worth it. It's covered in shit. Literally. There's too many homeless people. It's too tech bro.
Yeah, it's covered in poop. There's heroin needles everywhere. You get used to the homeless people. They mean you no harm.
Don't bother them, they won't bother you. It's like you're living past each other. Two people stuck on different sides of the class divide, rarely interacting.
It's like a cyberpunk movie.
And yeah ... it's expensive. But San Francisco is expensive for a reason.
I work in and with startups. That caps my salary at Not Very High. And even that makes my life cushy enough.
Engineers back home don't make much
Back home a well paid engineer with a local job makes around \\\$25,000/year.
In San Francisco I can save almost that much every year even without my side hustle. You need about \\\$5000/month for a normal life with an SO. You won't take Uber all the time and maybe you can stick to just 1 latte per day, eat out only a few times per week, and keep it to 1 maybe 2 vacations per year.
Wait ... that sounds pretty cushy!
With a normal software engineer at a startup salary, you'll still have way more than \\\$1000 left over every month. Maybe that doesn't sound like a lot to you. To me it was unimaginable just 5 years ago.
Only people back home I know who pull that off are engineers playing the income arbitrage game. Live in a cheap country, work remotely for a rich country.
But that makes you lazy.
And I have friends here who work with big companies. They make upwards of \\\$300k per year. More cash left over than they know what to do with.
That's my favorite part of San Francisco. The fire under butt.
In San Francisco you never feel like you're making it. You never feel like you're crazy successful. You never feel like you're out of the woods.
One bad month or two and you're digging into your long term savings. You have short-term cash buffers because d'oh.
You don't want to dig into long term savings. Those exist for 70 year old you and for any Life Stuff that comes up.
Everyone in San Francisco is always crushing it. Or says that they are.
And that's a good thing.
You are the average of the 5 people you spend most time with. You can't fight your environment. But you can change it.
That said ...
This one surprised me.
I always thought San Francisco was an entrepreneurial mecca. But it isn't. San Francisco is a careerist mecca.
People don't come here to start companies. People come here to get rich in companies. It's too expensive to be on your own.
Come here, make a bunch of money, leave. 5 to 10 years.
Switch a bunch of jobs, play the career game, climb the startup ladder, and get the hell out. Catalyst for leaving is often kids or a good liquidity event.
Some just get tired of the grind.
Fire under butt is great when you want to grow, terrible when you need some rest.
And that's what I learned about San Francisco in my 4 year stint so far
- Your code doesn't matter
- Shipped beats perfect
- Everything's a prototype
- Play the career game
- It's expensive for a reason
Happy Monday ~Swizec
Here's how it works 👇
Then get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career.
"Man, love your simple writing! Yours is the only email I open from marketers 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 ❤️