Your code doesn’t matter. Your tools are irrelevant. Shipped beats perfect.

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.

Your code won’t matter if you’re dead

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?

You die a prototype or become that code everyone hates to work with

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 ๐Ÿ˜›

Don’t fix it until it breaks

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?”

You won’t.

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.

Relax constraints

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.

If your code doesn’t matter, what does?

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.

However you and your team get there, it’s all good. React, Vue, Reason, JavaScript, Java, or FORTRAN. Whatever floats your team’s boat and gets the software shipped and in user’s hands.

San Francisco is expensive but worth it

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
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.

The environment pushes you ๐Ÿ”ฅ

Click through for source

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 …

SF is not an entrepreneurial mecca

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

  1. Your code doesn’t matter
  2. Shipped beats perfect
  3. Everything’s a prototype
  4. Play the career game
  5. It’s expensive for a reason

Happy Monday
~Swizec

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works ๐Ÿ‘‡

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet ๐Ÿ“–right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter ๐Ÿ‘‰ here.
It's where I go to shoot the shit about programming.