Comment by iamleppert
1 month ago
Counterexample: Not everything needs to be a group activity or social. If a developer of average skill can't manage to deliver a feature without the constant help from a "Tim", it says something about your code, processes, team. I've worked at places where they used pairing as a signal the team was working well together, when the reality was the code was so brittle and full of hacks it took the combined help (usually moral support) of a Tim to help support through every little change.
Every team is different, but software development needs the time and space for individual work just as much as group work. A small team who needs a dedicated person for pairing, who also doesn't (or won't) do any IC work, is a huge red flag.
Don't forget about the type of software. Something really specialized or algorithm heavy (science or math heavy) might be harder to do solo than a CRUD app.
My experience is the opposite. Easy stuff is simpler to pair up. Really hard stuff is solo. E.g. I expect Ph.D. work to be mostly a solo project.
Not that it's impossible to do hard work collaboratively but I think a lot of heavy thinking is solo (Einstein, Newton e.g.) and it's hard to keep other people synchronized.
Most of us work in decade+ legacy code made from a lot of people who are no longer at the company. So most of the code is brittle by default. That's simply the trend that emerged from a workforce that stopped incetivizing retention.
As such, I'd argue that 80+% of your problem solving for the first few years (AKA the only years before you hop or get laid off) is in fact asking other people what the quirks of the code-base are. Maybe that is bad, but it doesn't seem like the retention culture is shifting anytime soon.