Stuff Everybody KnowsSoft Skills & Career Advice
The hardest skills in the industry, misnamed
We call these “soft skills,” which is a terrible name, because they are the hardest skills in the industry. They’re impossible to master, they take a lifetime to learn, and we consistently undervalue them. The fact that we call them “soft” skills is itself evidence that we think they’re easy. They’re not.
Don’t be an asshole
The most important soft skill — really the only one — is: don’t be an asshole.
Don’t belittle people. Don’t undervalue the non-technical people in your organization. Developers have this idea that without the coders, the company doesn’t have anything to sell, so the sales department and the marketing department don’t really matter. But without the sales department, nobody buys what you built. Without marketing, nobody’s heard of you. Without managers, nobody knows what’s going on. Without HR, well… things go very badly very quickly.
Everyone is equally important. You don’t have to look very hard to think of companies that violated this principle — where technical supremacy was valued above everything else, and it went horribly, horribly wrong.
Don’t let the money go to your head
This is a strange time in the world. Developers are ridiculously well-paid. You’re going to walk out of a bootcamp and people will offer you six-figure salaries, approaching seven if you know anything about AI. That’s an absurd amount of money, and it’s very easy — when you’ve gone from broke bootcamp student to earning a quarter million dollars for hitting little bits of plastic with your fingers — to think that you’re a better person than you used to be.
Your salary is not part of your worth as a human being. Be nice. Be helpful. Be kind.
Value yourself
Here’s where your interests and your employer’s interests diverge. Your employer wants you running as much code as possible, as fast as possible. If the strain of that breaks you a year later and you burn out, you’re the one who’s burned out. They’ll just hire someone else.
For your own safety and your own career, you need to make sure that everything you do is sustainable.
The 40-hour week is not arbitrary
Working more than 40 hours a week is not sustainable. This isn’t some number pulled from thin air — it has over 120 years of research behind it, going back to the invention of mass production. When factories tried to get workers to do 70-80 hour weeks, they discovered productivity collapsed. People were so exhausted they kept dropping heavy things on each other.
Crunch mode feels like it works, and it does — for about four weeks. During those first four weeks, you’re producing more than someone working 40 hours. But at the four-week mark, you’re producing less. By eight weeks, you’re exactly as productive as the person who worked 40 hours the whole time — except you’re now physically and mentally depleted, and they’re fine. They can keep going for another month. You need a month to recover.
Three months into “permanent crunch,” you are significantly worse off than someone who just worked 40 hours per week from the start. Startups don’t understand this. They refuse to understand it. They continue to pretend it isn’t true despite literally a century of research proving it.
People are going to offer you absurd sums of money to do work that you enjoy. Why on earth would you work for someone who makes you miserable when you could go to any other company and do the same work but go home at the end of the day?
Never work alone
This means two things.
First, as a new developer: you’re going to walk in on your first day, having just convinced them in the interview that you’re a genius, and they’re going to tell you something you don’t know. Your instinct will be to figure it out yourself so nobody discovers you’re a fraud. Don’t do that. If it takes you an hour to figure something out alone, and it would have taken ten minutes to lean over and ask the person next to you — you’ve wasted 50 minutes for no reason. Ask for help after the first five minutes of struggling.
Second: don’t be the only technical person at your company. If someone says “we have a team of three developers and a thousand other people,” do not work there. If you work with too few other technical people, you develop a kind of Galapagos syndrome — weird habits, strange adaptations, funny idioms that only work on your little island. You become a developer who can only do the specific kind of development you’ve already been doing.
Keep learning
Your skills have a shelf life, and it’s really short. Some of what you know will last forever — that’s the kind of knowledge this guide tries to focus on. But a lot of the on-the-ground knowledge — how this API works, how these tools fit together — will have changed beyond recognition in six months.
That means two things: you need to be constantly learning the new stuff, and you should be sharing what you already know as fast as possible, because it expires. Give it to people before it goes stale.
Read articles. Go to meetups. Go to conferences — if you have a full-time job, you can often get them to pay for it. Write blog posts. Give talks. If you can turn the stuff you know into open source software, do that — it’s a way of taking a problem you solved once and turning it into something self-sustaining that other people can maintain and improve as conditions change.
Why we share
The tech industry moves faster and has taken over more of the world economy than any other industry in history. One of the reasons is that deep in the DNA of tech is a culture of sharing. When a car manufacturer discovers a new way to build cars, they patent it and keep it secret. When a tech company discovers a great new way to do something, they give a conference talk about it, and everybody goes faster.
That’s the culture. That’s why this guide exists. For decades, people with no vested interest in my success sat me down and taught me how to be the person I am today. The only thing I can do is pay that forward. That’s what this guide was, and I hope it was useful.