Scale-up feels sluggish. Am I missing something here?
Posted by Lonely-Leg7969@reddit | ExperiencedDevs | View on Reddit | 23 comments
Joined scale-up recently.
Pros: 1. Engineers are senior and above 2. Mature dev tooling
Cons:
-
Devs sort of work in silos - not much communication / collaboration. I’m used to working on a team where we hash out the feature including the tasks we need to achieve before starting work. This helps pick up ambiguity that Product can then clarify. Brought it up but it seems team is sort of hesitant to apply it.
-
Feels like the team lacks drive to deliver unlike smaller startups where it’s deliver or die. Sure, they’ve hit regional scale but it feels almost corporate. Kinda feels like we’re running at 25% of our potential instead of 70%. And yeah, I’ve definitely pushed and implemented some process improvements within the first month of joining (with limited scope).
I have my own biases and I admit I have been struggling a little with the new domain knowledge - the code is very coupled with the business logic to the point where you need to do a moderate amount of reading outside of work for the first month or so. Think of it as needing to know how to calculate insurance liability instead of having an engine that can do the calculations with input from a user who is a domain expert that can craft the logic.
So yeah, feeling fairly useless and sluggish overall.
Certain_Victory_1928@reddit
It sounds like you’ve stepped into a half-awake giant of a company, strong bones, sleepy muscles, and you’re grinding through dense domain fog while trying to gently spark a culture shift, so feeling slow and underpowered is understandable, not a verdict on your worth.
CtrlAltSysRq@reddit
I can't possibly imagine why!!
Also - 6mo tenure in a codebase 6+ years old? You have a lot of work to do both rebuilding miracle and rebuilding that brain drain.
You mentioned elsewhere runway and belt tightening. Are you scaling up or are you fighting for survival?
ThlintoRatscar@reddit
A few observations/questions...
Devs have less experience than the age of the code. By definition, it's legacy code.
What business forces wiped out the previous dev organisation? What business forces are trying to scale out 6m after doing that?
Who is driving technical hiring and driving the teams forward? What is their experience, character, approach, and goals?
What are the middle term goals/milestones that people get out of bed for? What is ownership trying to fix in the world and how does software help do that? Is that a meaningful purpose?
Lonely-Leg7969@reddit (OP)
blackize@reddit
6 months. The avg amount of time you say devs have been on the project.
IndependentProject26@reddit
Drive and speed are for dopamine addicts, not engineers.
Dziadzios@reddit
It's a con, not a pro. Juniors may not be experienced, but they are more energetic. It's healthier to have a sort of balance between seniors, mids and juniors, so seniors can be offloaded to higher impact stuff. Mids are also are necessary as they should also be good for less impactful stuff while being self-sufficient. Using only seniors is a waste of money, energy and burnout-inducing.
dashingThroughSnow12@reddit
There are tasks I’ve done super fast because I know if I don’t do it right, the juniour is going to do it wrong. There are also tasks where I’ve thought that these are perfect tasks for the juniour. High velocity, low difficulty.
I’m not proud of either of these. But I don’t think I’m alone.
Lonely-Leg7969@reddit (OP)
Not sure I agree with this. Some places don’t hire juniors because it takes them a longer time to ramp up and there’s a perceived gap in competency so they probably can’t deliver full features in a timely manner.
Aware_Magazine_2042@reddit
I think it actually takes longer to onboard a senior than a junior tbh.
Juniors are a blank slate. They don’t have experience, they just do what they’re told. You can give them a simple task on day one and they’ll do it.
Senior+ has all of these preconceived notions and experiences. They have worked on similar problems before in different contexts and they have to map those contexts to the current context in which they are now operating in. Give them a simple task and before they even start, they need to understand The Who, what, and the why. They’ll ask questions about structure, history, what tools are being used and why. They have to understand how they tools compare to tools they’ve used in the past, and what the current change management process is.
I think the more experience you have, the longer your onboarding period will be. I think one of the biggest mistakes people make is rushing their onboarding because they think they’re too senior and rush into fights they’re not prepared for, or solve problems that aren’t that big of a deal. One of my favorite books on this too is the first 90 days
trwolfe13@reddit
Respectfully, I disagree. From a business perspective, I agree it’s a better use of resources, but as a human being, only ever working on The Most Important Thing is exhausting. It might just be me, but I can’t work at maximum brain capacity 40+ hours a week, and getting to deliver on some simpler features every now and then actually helps me burn out slower.
I realise that complexity and impact don’t always correlate, but those kinds of quick wins usually dry up pretty quickly.
coworker@reddit
Seniors work on the easy stuff by reviewing those PRs. Your comment implies you're only considering your specific IC work and not the majority of your role's responsibilities which is to be a force multiplier
theonlyname4me@reddit
If you think reviewing code is easy; you do a bad job at it.
Reviewing code well is far harder than creating code. Another reason vibe coding is absolutely idiotic; but I digress.
coworker@reddit
If you think reviewing code is hard, you are not doing enough upfront design to split problems into manageable chunks.
It does not matter if AI or human when the problem is too big
theonlyname4me@reddit
Just say you do a bad job and move on. Most people do a bad job; it’s not a sin.
coworker@reddit
Sigh another "senior" who doesn't know how to do their job
theonlyname4me@reddit
Writing code is easier than reviewing and understanding it; which everyone knows…
It doesn’t matter if it is writing/reviewing 10 or 1000 lines; reviewing is harder. Also splitting it up into the appropriate chunks is also harder than coding 🤷♂️.
Coding is the easy part of the job.
In short you are a confidently incorrect. The worst kind.
Good luck; try some acceptance therapy, good luck!
coworker@reddit
You're obviously in the wrong sub junior
eternal_3294@reddit
ok, i've diagnosed you as a 50 year old unemployed male virgin who lives with his parents and makes a living off arguing on reddit. had a good laugh at your expense. bye.
Justin_Passing_7465@reddit
Senior devs probably don't need to hash out an approach with someone else. It might help junior devs if every feature becomes a collaboration, but senior devs usually just grab stories and deliver them. Having highly-productive seniors deliver in parallel is probably a lot more efficient than all of them talking about a single story.
Lonely-Leg7969@reddit (OP)
Fair point and I’m not expecting to be spoon-fed, but it does save a lot of discovery time especially when no one is really familiar with legacy code.
My counter-argument is that you can parallelise a feature development if you break it down into tasks that others can chip in and move things forward ? The slowdown is not technical but more on familiarity with codebase and side-effects of changes
Justin_Passing_7465@reddit
Putting many devs on a single story increases the number of merge conflicts and amount of rework where each dev gets their tests to work, but not when multiple devs work interferes. It is more efficient for different devs to work in different parts of the codebase.
Pair programming is different, and has some benefits without the downsides of merge conflicts and incompatible fixes, because the pair is working on one copy of the code not their own conflicting copies of the code.
Justin_Passing_7465@reddit
If you only have one story to deliver, parallelize the tasks (or breakdown the story, depending). If you have multiple stories, ideally touching different parts of the codebase, you can deliver more features faster in parallel.