Avoiding too many cooks in the kitchen (opinionated senior folks) 👩‍🍳

According to the Collins dictionary: “Too many cooks in the kitchen” means that something may not be successful if too many people try to do it simultaneously.

As part of our “Tips & Tools” series, we recently published an interview with Valentina, a lead software engineer at ThoughtWorks. Valentina gave us some valuable tips on enhancing developer productivity working in highly distributed environments.

One of her suggested tips for increasing developer productivity caught my attention: “Avoid the too many cooks in the kitchen syndrome with lots of opinionated senior folks.” I personally tend to agree with Valentina that juniors can bring fresh thoughts and cohesion to modern development teams.

However, still, I wanted to get some controversy from the Redditors on the programming sub and asked if they agreed or disagreed. What’s a day on Reddit without a bit of controversy? 

So this is my post:

I was amazed to find 95 super insightful comments in the Reddit thread, reflecting the developer community’s strong and conflicting opinions about the issue.

An interesting discussion had started, so  I decided to share the most upvoted comments that were super insightful. It took me about an hour to read all the comments and realized that there were three types of responses:

• Folks who agree
• Folks who disagree 
• Folks who neither agree nor disagree

Let’s get baking👩‍🍳

Neither/ Or Folks

This Redditor shared his personal experience at his workplace and suggested that:

“The problem we run into is that we basically have three categories of developers:

• First, inexperienced junior people need to be taught and brought up to a higher level, but then they leave to get more money and work from home once they are good since my organization offers none of that.

• Burnt-out experienced senior developers who are comfortable enough to not look and do some amazing work but get too bogged down between training up new people and working on stuff haphazardly based on a lack of definitive requirements and fixing bugs that others have left.

• New hires are former retirees because they are the only ones willing to work on-site five days a week for what we pay. They bring all the baggage with them and outdated development philosophy that served them well back in the COBOL days.

Suffice it to say; my team specifically has nobody with less than 20 years of software development experience. I’m the manager (promoted in 2020 and still have to code because I can’t find anyone who wants to work here within the constraints corporate leadership places on us) and the youngest person on my team.”

And this Redditor had written a whole hiring strategy:

“In my dream org that I get to run from start to finish, here’s how I’d do it:

• Startups need 100% experienced engineers who know when to switch from angel-funded “throw spaghetti at the wall as fast as possible” code to series A “we found our product market fit, let’s lay the groundwork for the future” code. Juniors can’t do this work. They don’t even know what they don’t know.

• Small to midsize companies, up until series C or so, should hire nothing but Bootcamp developers under those founding engineers. Some of them will turn out to be awesome; promote those when your seniors inevitably start to trickle away because the org is getting too big and constraining for them. Don’t bother trying to hire mid-level engineers at this point; their experience is with other people’s code; right now, what you want is people following the standards and structure of your code. Only hire a senior if there’s a specific new specialized niche you need to fill and they’re a clear fit to drive it — this is your DevOps or ML or API or database or build-tooling experts, whatever your org needs specifically.

• By your series D, you’ll have a handful of seniors left driving the boat (don’t screw up and promote them into management! Hire people managers instead, and fewer of them than you think you need; with rare exceptions, your best seniors should stay as staff engineers and manage code instead of people), a fair number of mid-levels for whom you’re their entire career experience so far, and a bunch of cogs handling the grunt work. At this point, you have an established codebase, and its direction and style are pretty well set. Scale and coordination become your main problem, so you start hiring mid-levels along with your juniors. 

• Never hire a senior engineer just because you think you need X number of senior engineers. Hire into specific positions with a clear idea of what you want that individual to drive; otherwise, promote from within.”

I loved how this Redditor also referred to the different needs of different orgs depending on size and maturity level:

“I suggest:

• Start-ups don’t need 100% senior engineers. It’s easy enough for senior engineers to draft a design, review it with other seniors, then break it up and send work to Jrs.

• Midsized orgs need all skill levels of engineers. Senior developers start getting bogged down, decreasing the ops overhead while doing the ops & critical scaling work. Junior devs can continue to grind out tickets. Intermediate devs can support Jr devs and take on initiatives that aren’t mission critical but will lead to process or product improvement that will reduce the likelihood of seniors burning out while holding up the whole house of cards.

• People managers are a waste of time and resources. Senior engineers can stay with the code if they want. But there’s zero point in hiring “people managers” that don’t understand the tech and, therefore, cannot contribute meaningfully to discussions that compare & contrast incoming feature work against regressions, bug fixes and tech debt repayment. People managers don’t scale and barely do any real work.

According to this developer:

“There’s another type of developer: The 9to5 zombie developer. Checking in, sinking into their IDE to code a day without talking to someone, pushing to PROD and leaving a trail of destruction behind for others to handle when they happily leave at five without even realizing it was their change that put everything on fire. When asked for help, they are not responsible for QA, Ops, or writing the requirements. They just blindly implemented it without thinking twice.”

This Redditor summed it up nicely:

“That’s the thing; just because you’re older doesn’t mean you’re a bad developer. It also doesn’t mean you’re a good one, either. That’s the whole point of ageism: it doesn’t mean shit. Age doesn’t matter in this industry as you have people with 30 years of the same year and people with five years of continuous improvement.”

Folks who agreed  

• “I agree. I’ve worked for ten years in a group of ~40 devs working on a client product with hundreds of millions of users. A good 50% of them had > 10y experience, with around ten engineers with 20y of experience. This was absolutely the best environment to be an engineer in. (when I say engineer in this context, I mean people who write code. Not managers, etc.).”

• “In the NL, we call it “having two captains on the ship”… Basically “seniors” who can’t cooperate with each other. I’ve found out it is the most unproductive situation you can have. That is because: either you are equal and opinions are about their merit, or there is an upper and lower echelon. The latter has been proven to reduce critical thinking (e.g., flying).”

• You get a monoculture of the existing opinions. In a market where innovation is really important.

• With too many seniors on one team, you get a toxic setting where being right is not enough. It stimulates people to get their way in other ways (political, violent, technical bugs). You need people to be relaxed if you want them to perform. You also want coders that can code (and not focus on the other skill sets).” 

• “Ageism can definitely be a factor. Imagine a coworker that lectures everyone else like the cartoon character Foghorn Leghorn — they have a lot to say but mostly just want to brag about how much they accomplished in the past while contributing little to no value in their current role.”

• “I’ll confess that I learned COBOL in my high school programming courses, and to give you an idea of my age we also learned QuickBasic and C in the same classes. But, unfortunately, a lot of the people my employer is finding are people who are the age of my parents that I suspect didn’t save up enough for retirement and probably got laid off from their last job.”

• “Well, let me just say that I am 100% ageist. I’ve been downvoted to shit for this before, but who cares. Many devs in their 50s and 60s just straight-up fucking suck. Trash tier, for sure. “I’ve always done it like this” or “I’m used to this” is not an excuse to write shit code that I now have to rewrite because it is an unmaintainable mess with hardcoded crap everywhere. This is obviously biased since it’s based on my experiences, but man, people in that age group that are still hanging around seem to be bottom-of-the-barrel devs. Anyone good has already moved on to mgmt positions or something else where they don’t actually code any longer.  But I could actually look past all of that, if they took the provided input, used it, and started producing better code, but they don’t. Maybe because I am younger than them while being their boss. I have no fucking idea. I’ve yet to find consistency in it. But, like, if everything is selected*, you are going to get bad PR reviews. The best devs I know are in their 30s and 40s, but that’s because they are continuously improving, not hopping on a bandwagon like microservices and such without applying critical thought.”

Folks who disagreed  

• “Too many cooks in the kitchen? At one of my first jobs, the seniors taught me that alignment was more valuable than perfection. And even without being said explicitly, that’s been the attitude for most of the projects I’ve been on. “

• “Disagreeing productively is a skill. If you’re having clashes among senior developers that negatively affect the product or the team dynamic, then you might have mid-level devs with an inflated title. Or you’re working at an unsustainable pace and the wheels are falling off.”

• “Really? I’ve been coding for about 20 years and I already feel like I’m losing touch with the shit young people do. A fair bit of stuff people post here I think “what the fuck is wrong with you doing it like that” and I figure people older than me would be the same only 10x worse.”

• “There’s no way I’d work on a team full of kids who code in the style I’m seeing more and more of these days, and I figure they probably wouldn’t want me either.”

• “Anecdote: The best coders I know, the majority are over 40.”

• “I disagree with you – startups should only hire experienced people. It’s easy enough for senior engineers to draft a design, review it with other seniors, then break it up and send work to Jrs.

• “I’d wager that too many seniors would be better than too many juniors.”

Sprkl can help junior devs with their onboarding process. Try it for free! 

Stay hungry🍕