Many teams start as a group of individuals.
You have Joe working on the client, Jane doing backend, and Alice who does both but much prefers her time on the client. She thinks backend is just a bunch of JSON bureaucracy, Jane resents this opinion, and Joe can't understand why the backend needs to be anything more than an API call straight to the database.
They work together on the same product.
Jane loves to jump on every backend story, Joe beams with pride when there's client work to do, and Alice tries to help them both. She rarely gets to own stories because Jane or Joe always need help with something. Joe gets stuck when an API needs to be adjusted, Jane doesn't know how best to add a button that triggers her backend code. Those little things are Alice's job.
Standup is hard
Every morning they have standup. They've heard that's how big companies do engineering so that's what they're doing.
Standup sucks.
Joe doesn't understand Jane's updates about queues and strange data problems. Who cares about any of that? Data is in the database when you need it. How hard can it be to write a SQL query? He uses this time to catch up on group texts.
Jane thinks Joe's updates are trivial and silly. Who cares about the color of a button? You set that once and it's solved forever, obviously. She likes to use standup to read social media.
Alice finds standup incredibly useful because she needs to know when Jane or Joe might need her help. But she keeps getting lost in their detailed descriptions of how the work happened. Who cares how you got here? Tell us where you are.
They're off camera a lot so you can't see the eyerolls.
Code review is tough
The team practices code review. Every change needs 2 approvals before it can be merged into the main branch and pushed to production.
This is supposed to help with knowledge sharing, catch obvious mistakes, and keep the code decently uniform in style.
But getting any pull request merged is like pulling teeth. Review cycles are long and you have to practically beg others to please find time to look at your code.
When Joe makes a pull request, he sends off a message and buckles up for the pain. In about an hour, Jane will come in with a bunch of questions about what the code is doing. She doesn't understand client work, but she's great at spotting syntax tricks that make his JavaScript better. And she asks good questions that help Joe realize when he missed an edge case.
He fixes Jane's comments. It takes him all afternoon. Then he takes a deep breath and goes home. Tomorrow morning Alice will review his code over coffee and drop the big bombs. She always reviews code first thing in the morning.
It takes Alice a few hours to review Joe's code.
She carefully re-reads the story he's working on to make sure she understands the goal. Downloads his code to test locally and re-familiarizes herself with this part of the codebase. It's been a few weeks since she worked in these files.
"It's not great", she thinks.
Alice doesn't like Joe's approach to splitting components. She leaves a comment saying they're not reusable or self-contained enough. She also thinks his URL structure is bad and is going to cause problems. Plus he could've better organized his files. The structure doesn't make sense to her. Not to even mention the error handling and how he leaked null handling logic deep into his component tree. Again.
Joe's heart sinks. It's going to take all day to rewrite half his code. The feature was due yesterday. But Alice smashed the "Request Changes" button and now he can't merge until she approves.
3 days later, after more rounds of reviews, Joe's code makes it to the staging environment. The product owner immediately finds a bug. 🫠
What's wrong here
You may have worked on a team like this. I have.
Working alone or with this kind of non-team was all I knew for the first decade and a half of my career. The experience was so bad it almost turned me off working on large projects forever.
At one startup we even had an intern one summer who concluded their internship and said "You know, I don't think software engineering is for me". That crushed me. They were so excited at the start!
The problem is that Jane, Joe, and Alice are a team, but they're not working together. Every project turns into separate work streams, roughly organized by skill, with people working alone in a corner until their brilliant solution is ready for the world to see.
But when the code's finished is too late for deep feedback. Any pushback breeds resentment. What do you mean you don't like my beautiful baby!?
Everything’s a chore
And everyone resents having to give that feedback because it feels like a chore. You have to context switch away from the work you actually care about (your work), rejig your brain to what the other person was doing, think deeply, review the code, barely understand what's going on, leave comments, then reorient back to your own work. This takes a lot of effort.
When I mentored a young engineer in an environment like that, it felt like working on 2 projects at all times. I had to keep context on everything I'm doing and everything my mentee was doing or I wouldn't be able to help. Even then every question had to start with a 10 minute backstory to make sure we both understand the challenge.
That was exhausting and slow. No wonder people hate it.
If you’ve ever worked on a “team” like that, hit reply. I’d love to hear about your experience.
Cheers,
~Swizec
Continue reading about 5 soloists in a trench coat
Semantically similar articles hand-picked by GPT-4
- Approve with comment
- Why great engineers hack The Process
- Why senior engineers get nothing done
- Coordinating at the end is too late
- The answer to 5 soloists in a trench coat
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
The Senior Minset email crash course
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
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
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
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
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️