How do you catch a critical deadline that cannot be missed? We're talking external stakeholders, millions on the line, and it all hinges on your team getting it done on time.
Easy. You institute a death march, work 60 hour weeks, add a few all nighters, and everyone quits before it's over. Plus your codebase is full of bugs. Fantastic.
I have a better idea.
If the date can't move, the scope has to.
Sit down with the product owner and go over the roadmap. Anything that can be deferred gets deferred.
Those sparkly moments of joy designers love to add? Not as important as getting the user's job done. The perfect styling of a settings screen users see once a month? Focus on the screen they see on every time.
Don't be afraid to cut "Oh that's simple, I can do that in 20 minutes" features. Those are the easiest to defer. They add up fast, steal your focus, and the risk of doing it later is low.
PS: You can't solve scope by adding people. The right time to grow the team was 6 months ago.
Spoiler alert: It's your code review process.
This person was at wit's end asking the internet for advice. Facing a critical deadline tomorrow, their code sat there waiting for a senior engineer to take a look.
It's been waiting for over a week with no word from the senior. Not a comment, not a "sorry I'm busy", just sitting in the queue rotting away.
"Do I risk merging? Do I beg and plead with the senior? We can't miss this deadline. I'm afraid we'll look bad and it's all gonna fall on me. What if I get fired?"
Remove those obstacles! Work in progress kills your progress.
In my team we started with a rule: Every pull request gets 2 approvals before merging. This helps with knowledge transfer, catches small bugs, and ensures everyone feels comfortable with the codebase.
Feedback, unless critical (like a security concern), is up to the pull request owner to accept. We aren't Guarding The Codebase – we trust you know best and offer our input.
This makes the process faster.
You can turn feedback into followup tasks to do later. Deploy to a staging environment now, polish later. Plenty of time while the product owner verifies functionality.
Another hack was to build a culture of PRs Come First. Code review is not that annoying burden you do for others, it's your top priority. Clear the queue, then get to work.
Besides, code reviews are quick because the whole team works together. You know the context and the goal.
We added a rule that the 2nd approval with no comments should be a merge. Why wait for the owner to see your ✅? You know it's good, merge away.
That wasn't fast enough.
The cowboy merge is the art of skipping all that.
Do you really need two people to say you can fix a typo?
You can merge the PR yourself. It's okay. You got dis!
If a typo is fine, how big does a change have to be before it really absolutely needs a proper review?
That depends on how risky it is. What you're changing, how much it's changing, what are the consequences if it goes wrong.
Be very careful when running a script that updates production data for thousands of users. Even more careful when it charges money. A lot less careful when you're changing a font size in the footer, deploying to a staging environment, and it's all behind a feature flag in production.
Plus, how likely is it that another pair of eyes will uncover something new? Sometimes the perfect balance is to merge after 1 review. Other times best wait for 5.
Your cowboy merge says:
- the code is fine
- the change is low risk
- reviewers are unlikely to comment
- I did the work to de-risk
- I own the 💩 if this goes wrong
- I'll fix if anyone complains
Focus on making mistakes easy to fix, not impossible. But that's another post :)
1 sorry Reddit search is terrible and I cant' find the original post anymore. The quote is my summary
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Leave your email and get the Senior Mindset series - a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.
Get a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.
it describes my days in a way I have not read before.
This was a very enlightening article about being a senior engineer.
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️