Swizec Teller – Senior Engineer Mindset
If your manager can count on that little update at the end of the day, they will never bother you with status updates ever again.
Can you cary a project from start to finish without your manager’s input? Then you’re a senior software engineer. Bonus points if you can do this for a team building a larger project together. Now you’re a team lead!
Make sure you code on the side!
If you want to improve your career a lot, you have to work on your career. You have to do work that force multiplies yourself, not just those around you.
There’s 3 ways to grow as a senior engineer:If you ever worked at an agency, you’ll know this deep in your gut. Every project is about the same as every other project. Details change, requirements evolve, the industry moves, but a website is just a website.
You might get faster, you might build tools, you may screen clients better … but you’re building the same thing day in and day out. 🥱
So how do you grow?
- bigger company with bigger problems
- become junior in new thing
It doesn’t matter how hard or how much you work, it only matters how much value they get. I think that’s why engineers are squeamish about salary. We think we’re overpaid. We think our work’s too easy. We come from backgrounds where hard work is a virtue, physical labor is king, doing stuff is the norm, and your boss is a jerk. And all we do is sit there and type and think. But YOU deliver tons of value. Tons.
Ok so you’re being paid for value, your value is massive, and what’s the point of sharing salaries? Sharing your salary in public might hurt your negotiating position, this is true. They’re gonna say “Yo you did this work for $X, why you want $Y now?” You are talking to a wage slave. Stop. Find someone else. Change the conversation. It doesn’t matter that you did similar work for $X. The new company is bigger, more profitable, and has more painful more expensive problems. You are here to help and deliver more value. That’s why you’re getting more.
If you like the [startup] company and think it’s a rocket, you wait out your vesting cliff. Maybe even the whole vesting period. A business coach once told me that vesting is considered finished for retention purposes when an employee hits 75%. That’s the point where their vested stock outweighs what’s left to vest and they start looking.
Sell products. It doesn’t matter how much you feel comfortable charging. Just do it. The feeling of making money, any money, passively is amazing.
[Focus] marketing on “You need this because” and not on “I made this and need sales”.
Reading Nathan Barry’s Authority before the launch was paramount. I probably would have fucked it up completely without his lessons. [When writing a book, hire an editor.]
Past a certain level companies stop seeing you as a code monkey. They don’t care about your hours, lines of code, or tickets closed. Companies care about the systems and tools you put in place to make the whole engineering team run better, do more, and make bank. You’re paid for value, not work. Now what? Cash, baby.
A 30% raise is common when switching jobs. Lots of advice on salary negotiation and how to make this happen. I recommend Josh Doody’s Fearless Salary Negotiation. He’s helped me in the past.
You are the average of the five people you spend the most time with. Associate with those who say “What can we do to make more?” not those who say “The system is rigged and we’re stuck” Hang out with ambitious folk. It’s gonna rub off on you. Become friends with those who push you to strive not those who pull you back. Read books that normalize success. Avoid books that call successful people crooks.
Remote work: RemoteOK is a great job board with remote positions, HackerNews has a “Who’s hiring” thread every 1st of the month with hundreds of posts, you can try something like TopTal or Upwork.
“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” 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.
If you don’t feel bad looking at your old code, you’re not growing. Fact. Your old code always looks like crap.
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.
In a “true” team, the surgicalness is fluid. Sometimes you’re the expert, sometimes you’re the code monkey. That way everyone helps everyone and you’re all getting better.
Extreme Ownership is a book you should read. Here’s a TEDx recap from the author. Ignore the navy seal hardass delivery.
Your objective is a successful project Make sure you check with your boss to know what that means. “What does success look like?” is the most important question in your arsenal when starting any project.
What this means is that you will have to deprioritize your own work in favor of everybody else’s work. Somebody blocked? Help them. Decision needs to be made? Help. Code review waiting for ya? Do it now, not later. Stuff needs to go into QA? Do it. Your job is to take on the crap work nobody else wants to do.
At its core, ownership is about overcoming obstacles. How good are you on your worst day? When the code hates you, production is on fire, user story makes no sense, and half your day is spent helping others? That’s when ownership shines.
When shit hits the fan, opt for speed. When there’s time, train others.
Ungritty people fail and say “Fuck it, I’m too dumb” Gritty people fail and say “Fuck that, I gotta try harder” It boils down to growth vs. fixed mindsets. Gritty people have a growth mindset.
And if you are like me, I suggest reading Pragmatic Programmer anyway.
So how do you hack The Process when it gets in the way? First you have to build trust. Without trust you won’t have the leeway to hack the process. Trust is best built by not fucking up. Second, you need to take responsibility. When something goes wrong and you followed The Process, your ass is covered. Process is the ultimate cover-your-ass strategy. The last step is good judgement. You’re about to hack The Process. Is it worth the risk?
Google recommends using fakes instead. Simplified implementations of the real thing maintained by the same team for API parity.
A small release is easier to manage. A small release is easier to revert. A small release is easier to understand. Keep shipping.
Upgrade dependencies early, fast and often.