Team Member Constantly Over Engineers and Over Complicates Everything Resulting In Hard To Understand Code
Posted by Software_Engineer09@reddit | ExperiencedDevs | View on Reddit | 112 comments
We’ve got a member of the team that’s been with the company the longest, they’ve got a good head on their shoulders and are very bright when it comes to coding. However, this individual over engineers and over complicates every single codebase they touch. We will call them “Bob”.
We are a smaller team of 8 devs and I’m not exaggerating when I say that the ENTIRE team has expressed dissatisfaction when having to deal with any of Bob’s codebases. It also seems that every time Bob goes on vacation, something inevitably breaks with something of his and it can take the team a painstakingly long time just to trudge through one of his codebases trying to track down the source of the problem. Things that should be straightforward, simple database calls are decoupled to the point where you have to jump through 3 classes, 2 interfaces, and dynamic functions just to even see where something is done.
I’ve brought this up to management in the past and even showed concrete examples of how difficult this individuals code is to navigate and understand, they didn’t do anything. If you try talking to Bob about it he of course gets very defensive and just acts like we are all stupid for not being able to understand his code.
Anyone else have a team member like this? Any tips?
Chemical_Claim2107@reddit
As others have said this is a political problem not a technical one. I have experienced this first hand fought it hard and was laid off. I would post in engineeringmangement or it managers. All I can say is just document and keep bringing up how bad it is to your management. You will have to be patient if you want to stay there. your best hope is for "bob" to get assigned projects that you don't have to support:)
Inside_Dimension5308@reddit
I don't think the situation can be controlled by discussion. Since he has been given freehand in writing code, he can really justify anything he produces.
Only if someone from authority can understand your POV and then compel him to maintain the same standards of code, can thi situation be diffused.
xXxdethl0rdxXx@reddit
How is this not addressed in code review? Once it’s merged, the entire team is accountable. If you aren’t creating a permission structure to push back as a lead, please consider doing so.
Software_Engineer09@reddit (OP)
Well that’s part of the problem, since Bob is an IC that doesn’t report to me, he often writes entire codebases without any peer review and then puts them out into the wild. Then 6+ months go by and all of sudden something happens and no myself and the team is responsible for it. We don’t currently have any say so over how the initial codebase is written or structured.
In the past I have made mention to them about how complex a codebase is and if it was really necessary and they will arrogantly go off on a tangent of how they follow best practices, its done by the book, look at this MSDN link, etc. etc. They basically act like they are always in the right and that’s if none of the other team members can easily understand it’s our own fault.
xXxdethl0rdxXx@reddit
Then Bob is not a problem, he is a symptom! This is a really dangerous way to work. It would be great if your team of 8 could all work on the honor system of how you want to individually write and architect code, but that's not realistic or scaleable.
This is a process issue. Leads can often influence addressing it, but it may need to be escalated to a manager or even director. The good news for you is that it's generally much safer and externally appealing to champion a process win for your reputation, rather than pointing fingers.
Software_Engineer09@reddit (OP)
Appreciate all the feedback and I do agree having them be an apart of the code review process would be beneficial.
But here’s the rub, how do we deal with the combativeness when a teammate says “This is hard to follow, can we simplify it” and Bob states that he is following best practices and knows right and that they are just inferior developers for not understanding his code?
catom3@reddit
For starters, you should emphasise to both Bob and management, that it's a team's effort. And that it would benefit you all if every team member was able to feel confident about the code they read, extend and maintain. If it's a person you can reason with, you might try preparing some alternative versions of the code they're writing where you would try to achive some middle ground. If they're sensible enough and could take a look at the team and common goals from different angles, they could be more understanding.
You mentioned, they're an IC and they have a seprate workflow from the rest of the team. That might also be an issue. They may act defensive, because they know they can be let go any moment, because they constantly have to prove themselves or just because they feel there are actuallt 2 separate, somewhat competing, teams - me vs. them.
Or they might be narcissistic and too ignorant of their surroundings, and simply don't care.
I was lucky enough to get along with almost everyone in my career so far. Sometimes we weren't best friends or even acquaintances, but we would at least try not to step on each other's toes and respect each ofher's time and effort. If you can understand a person and their reasons, it might definitely be easier to gain their trust and try changing their mind or attitude. You probably won't win all the battles, but you can at least try.
xXxdethl0rdxXx@reddit
On the one hand, it's a separate, but serious issue if that's how Bob solicits review. But on the other hand, you'll be amazed at how polite people like that can be once an actual approval is required from someone else on the team.
Sometimes, people without good social skills respond better to a power dynamic, and if Bob the senior engineer can't convince Petunia the junior engineer well enough to give her approval on a pull request, then better luck next time.
Software_Engineer09@reddit (OP)
Yes paraphrasing that statement :)
I like the idea of requiring someone else on the team no matter their level to sign off on his code. I do just worry it will lead to him trying to play the superiority complex as he has in the past stating that his way is right, and everyone else is wrong for not understanding.
IAmADev_NoReallyIAm@reddit
Don't just make someone else review his work... if he's that confident in his work, make him EXPLAIN it to the others ... that's how we've done our reviews on my last two teams and how we'll do them on my current team... not out of arrogance, but because it's also a great learning tool. That's how I got my front end and back end developers to cross-pollenate and learn about "the other side"
So we do group code reviews, the person who created the PR presents their code, walks through the code, explains the code, what does, if needed why what decisions were made, any gotchas that might exists any problems that were encountered, etc. Along the way any one can ask questions, make comments, etc.
The other side of that is only certain people can actually do merges, that prevents rubber stamping of code. So if you're worried that Bob will just pressure Steve to approve his PR and then merge it, you can setup restrictions around it so that it's limited to only certain people can actually do the merging.
xXxdethl0rdxXx@reddit
Yeah, I think every PR requiring at least one approval is pretty standard.
In addition to promoting team accountability, it’s going to do one of two things for Bob: teach him some humility to get things over the finish line, or he will escalate his poor attitude. It’s a win-win for you; because if he raises a stink about this fairly benign review process, it’s an incredibly bad look for him. He’ll quit or blow up in some ease-to-fire way, but at the end of the day, the team is better off and you are now fully accountable for the code your team ships. Everybody wins—hopefully Bob will, too.
Potato-Engineer@reddit
If you have the leverage: don't approve his PR, he needs to address comments.
If you don't have the leverage: appeal to his brilliance. "Yes, Bob, it's very clever, but the problem is that nobody but you can maintain it. We need to fix bugs when you're on vacation, and that means the code needs to be readable to someone who's not familiar with your codebase."
Readability and maintainability are the two things that Bob is completely failing at. Don't let him hide behind Best Practices, tell him that his code takes too long to read.
Headpuncher@reddit
Readability and maintainability are best practices too. They're mentioned in every programming book I've ever read.
SnakeSeer@reddit
Asking why they made the choices they did so it's more of a conversation can sometimes soften things, although not always. Approach it from a collaborative "I'm trying to learn what you know about this process so I can better understand the choices you made".
Is he following best practices? Whose? Sometimes business realities override pie-in-the-sky best practices.
ninseicowboy@reddit
Yeah this is the root of the issue, you should be doing design reviews early and code reviews throughout implementation. I get occasionally having to open huge PRs given the nature of certain problems but huge PRs require huge reviews too.
Hot-Profession4091@reddit
Wait. Do you literally mean with the
dynamickeyword?mq2thez@reddit
You have a people problem, not an engineering problem.
An 8 person team having someone going completely buckwild like this is really weird, and you need to rein that in.
commonsearchterm@reddit
You need code review for everyone.
The find some best practice links to back up that commits need to be small to be reviewed
me_again@reddit
What is your code review process? Ideally you should be having the conversations with Bob at or before the time the code is merged, not when debugging a production outage.
If each change is peer-reviewed (not just Bob's, everybody's) then you have the opportunity to debate complexity before it is too late.
As a minor wording suggestion during reviews to reduce defensiveness, try "is there a simpler approach?" over "this is over-engineered". This suggests you are collectively searching for an even better solution rather than complaining about Bob's preferred approach.
TransCapybara@reddit
Code review is an engineering culture, and highly recommended.
wrex1816@reddit
It slightly irks me that this is practically the copypasta top comment when someone mentions issues over code standards.
I've met "Bob" multiple times over my own career and the truth is, the problem is cultural, political and runs very deep... It's not a matter of "agree on a linter".
OP mentions Bob being there the longest, having strong preferences, forcing them on others, having an attribute about anyone recommending another approach and that basically Bob knows he can get away with this because no matter how many complaints are made to management, he has them over a barrell.... "Fire me and everything will break, the rest of your team is stupid". OP complained to management, they protect Bob....That's your answer.
When I hear people gloss over all of this and say "Do you have a linter?" Or "Did you ask Bob this in code review? Surely he took all of your feedback kindly and make all the requested changes", I honestly have to wonder what utopia some of you work in or have you all really not actually experienced anything outside of little startup teams where consequences don't exist?
temp1211241@reddit
Often it’s more indifference than protection in these cases. Bob ships but if but becomes an issue he’s often less pivotal than one might think unless he’s got a close personal out of work relationship with someone above him.
temp1211241@reddit
Most of the time it’s more that that’s not their problem than that they’re protecting the Bob
me_again@reddit
I work at Microsoft, I've experienced politics once or twice :-)
Given OP's other comments, I'd agree that the root issues here are political and personal rather than technical.
To OP: if you are the team lead of a project, and you have people who don't report to you committing code, and you have no power to veto the code, you're not really empowered to be team lead. Much of this depends on what kind of organizational dysfunction is going on, but claiming that power may be an important step. If Bob is physically unable to check in code without your approval, that may help force the management reckoning that needs to happen. Or it could be a clusterfuck. Best of luck!
Devboe@reddit
This only works if everyone is against Bob’s complexity and Bob doesn’t have a go to code reviewer that approves his shenanigans.
kaumaron@reddit
Code Owners can help with this (provided they aren't the issue as well). We require two reviews but one has to be a code owner.
MerlinTheFail@reddit
And if the code owner is on vacation or leaves the company? If all code owners take holiday during an outage? This is a perfect way to create bottlenecks in your system. Everyone should ideally be able to jump and own any part of the code and system. There can be experts, of course, but one shouldn't rely on them to ensure code is merged, debugged, and improved upon.
kaumaron@reddit
We have like 5-8 owners
0vl223@reddit
Then someone on the team lead, staff or management level has the necessary rights to fill in as code owner.
wrex1816@reddit
Cool, but how do you enforce that when Bob is the gatekeeper and not willing to change his process?
subma-fuckin-rine@reddit
this is definitely not a simple "just do code reviews" problem. its a people and culture problem. if bob has clout he can push back freely and wont make any changes based on your review
jenkinsleroi@reddit
Ideally, yes, but I feel like there's more to this story than OP is telling. Like there's something dysfunctional about the organization or Bob has some special position of privilege.
The other thing that can happen is Bob tries to flood the zone by waiting to submit code for review until it's a huge unreviewable PR. Then claims that other people are blocking him.
Or maybe, but probably not, Bob is actually right.
PastaSaladOverdose@reddit
I've been a developer for a long time and it's amazing to me how many companies are pushing code to production first and bug testing second.
It's usually the first thing I try to join about any organization I join, because most of them aren't doing it, and if they are, they aren't doing it properly.
IAmADev_NoReallyIAm@reddit
Yeah, that happens all too often It's because too many are metrics based... how many tickets/points did you get closed out this sprint? I was at a place like that once. They were more concerned with that damned burned down chart than anything else.
Now I'm in charge of my own ship. Instead of being told where to go and how, I'm being asked, where too Capt? And it starts with linters/style/quality first (that's where it starts), demo second (no sense in reviewing it if you can't get the damn thing to work) in front of the whole class, including QA, then we review the PR, again in front of the whole class as a group. Then and only then once all questions, comments, and concerns have been addressed, does it get merged and officially handed off to QA for formal testing, and eventually cut into a release for UAT.
Zestyclose_Humor3362@reddit
Bob's a classic case of "brilliant but misaligned." His defensive response when confronted tells you everything - he values being the smartest person in the room over team productivity.
Since management won't act, start documenting the real business impact. Track time spent debugging his code vs others, deployment failures, vacation coverage costs. Make it about numbers not personalities.
At HireAligned we see this pattern constantly - high performers who don't fit the collaborative culture they're supposed to work in. Sometimes the most talented individual contributor is actually holding back the entire team's output.
Consider having the whole team log "Bob incidents" for a month. When management sees 7 devs spending 40% of their time untangling one person's code, the ROI conversation becomes pretty clear.
Xsiah@reddit
Sometimes I find that I'm my own Bob.
"Why did you do this, Bob?" I say to myself as I refactor something that seemed like a really elegant solution 3 years ago.
Active-Reference-927@reddit
Same
Software_Engineer09@reddit (OP)
Ha, we’ve all been there :)
Junior-Procedure1429@reddit
Many coders do this to hold their employer hostage. If nobody is watching it’s very effective.
perum@reddit
No offense, but it sounds like he's just a much higher level engineer. Ask him to add comments to dumb down complicated patterns
Software_Engineer09@reddit (OP)
No offense taken, but I do disagree, slightly. I won’t argue he is a very knowledgeable engineer, more so than our more junior members of the team. I think he’s just not very good at writing human readable and understandable code. Not only are there needlessly complex hoops to jump through, but variables are named poorly, every object is a var (C# quickhand instead of typing out type), it also feels like a lot of times he will just try incorporating the entire catalog of patterns into an app when they aren’t needed.
ZunoJ@reddit
A database call that takes three hops from frontend logic to actual ORM doesn't seem a lot at all. The only thing concerning is that there are only two interfaces involved. How do you mock the third class for tests?
Software_Engineer09@reddit (OP)
It was just an off the cuff arbitrary example lol. I’ve had instances where I had to jump through 10 classes to get to a simple db call.
ZunoJ@reddit
Sure, you came up with a totally valid thing as an example for the over engineered code. But maybe the code is not over engineered, instead you don't understand the value of abstraction and decoupling
Software_Engineer09@reddit (OP)
Is your real name Bob? Lol
I’m aware of the values of abstraction and decoupling, but I’m also cognizant of the KISS principal. I would understand if it was just me, or maybe 2 of the team, but when the entire team has problems navigating through, it’s a problem.
ZunoJ@reddit
It absolutely looks like it, I'm just saying ***maybe*** the problem isn't Bob but the rest of the team. Give us a complete example. Maybe as code, maybe as a diagram, whatever
Software_Engineer09@reddit (OP)
Get a list of songs
Getting from User pushing button to DB Query
All of this...to literally have a person click a button to load a list of songs. It's all technically "by the book", but holy hell is it overly complicated and over engineered. It should be as simple as ViewModel runs a function from the service layer >> service layer makes a call to the repo >> repo runs a query and returns results.
remiusz@reddit
Sounds like at least 3 separate abstractions where you really ought to worry about 1 - half of those points are likely just hidden under task sendout call and debugging through it redundant (I mean no one often debugs through ORM callstacks (well meaybe except deviants like Bob - I'm kinda a Bob too)).
Question is why the task name or params don't clearly identify the repository method / or particular service implementation that will handle that command. It's usually done like that - at least I'm thinkin around CQRS approach.
Another one is why isn't this documented and isolated as a lib, so people don't confuse it with implementation layer. And if it's not intended to be like that then that's a huge problem.
Material-Smile7398@reddit
Steps 3-6 seem like overkill, the rest seems sensible
CoroteDeMelancia@reddit
This reminds me of a sarcastic quote I'll try to recall as precisely as possible:
gilmore606@reddit
I've also heard this said (more sympathetically perhaps) as: "To solve a problem, create a DSL in which the entire class of problems could be solved. Then solve the problem in it."
Far-Consideration939@reddit
Idk you have several distinct layers here and handoffs from the ui to backend code which has services wrapping underlying db primitives
I wouldn’t just have the ui talk to the db…
Software_Engineer09@reddit (OP)
I wouldn’t either, that’s what the service layer is for :)
ZunoJ@reddit
Ok lol. Without any other information this does look ridiculously overengineered. What other purpose does the generic serve? The unit of work instance is retrieved from the IOC container but why is it not injected where it is needed? The get instance function sounds like a wrapper around the exact same framework functionality, just worse. What kind of repo does the factory create? How is it secured against the user just clicking 100 times and opening 100 sql connections? Why is there no orm mapper that is injected?
TurbulentSocks@reddit
In most languages you don't need an interface to mock.
ZunoJ@reddit
And still i need to mock the dependencies otherwise the test is too watered down
temp1211241@reddit
So lean into it. Dumb dev need code they can maintain. Smart dev always on call otherwise.
isarockalso@reddit
I have a bob.. their great lots to learn from with real patterns instead of quick n dirty apps. 3 classes and 2 interfaces for a database isn’t a lot…
Interfaces for functions start end dates lotsa common properties.
Are you saying no interfaces? It sounds like he’s using patterns. Repo has a few off the bat.
Huge-Leek844@reddit
You complain when code are coupled and spaghetti, you complain when the code is clean and decoupled.
benjimawoo@reddit
I’ve worked with devs like that. I probably was one once upon a time. Try reframing the problem - you can’t optimise for everything. So optimise for reading/debugging. Rather than ‘this is great but it’s overengineered and unreadable’, frame it as ‘this is great, I can see that it’s optimised for performance and pattern use, but it needs to be optimised for supportability. See how much you can optimise it for supportability?’
Might take a while, but currently their personal metric for ‘good’ might be ‘implements the most best practice design patterns’. Whereas the more effective metric for ‘good’ could be ‘can be picked up and understood by someone at an earlier and earlier career stage’
csgirl1997@reddit
I was Bob once. Then I wound up on a new team and had to help people learn my code… never again
MorningAppropriate69@reddit
If the code works, it's only galfway done. Cleanup, simplification, tests, and documentation are the other 80 percent.
This should be explained to Bob. If he doesn't accept this from coworkers, ask a manager to step in. Add it to the definition of done, and don't approve pull requests unless it's up to the needed quality.
For inspiration, watch "Postcards from the peak of complexity" by Brian Goetz.
beeskneecaps@reddit
Eslint rules to enforce max cyclomatic complexity, prevent nested ternaries, too function many arguments, etc the rest of the sins! Agree on them as a team and implement the autofixes! It’s the only civil way
Kolt56@reddit
good engineering isn’t about how slick your code is it’s about how clear it is to the next person. If he doesn’t want to work on a team, maybe he shouldn’t be on one.
Have the team shift to a functional paradigm, make him statically type the ins and outs. Ban Record, any, and extending BS. He should have many interfaces, zero classes, and zero dynamics functions eww.
Sounds like he’s trying to increase his bus factor for job security.
AnhQuanTrl@reddit
Lol I’ve met this type of guys so many times in my career now. At first I thought I was the over-complicator, but then I meet these clean architecture - DDD - Uncle Bob fanatics and realize that I favor simplicity above all else.
astromanos@reddit
Why would you have to go through 2 interfaces if they don’t hold any implementation?
Poopieplatter@reddit
Worked with a Bob before. Arrogant and difficult. He saw himself out after 10 months.
sciencewarrior@reddit
I had a Bob two, a couple of times. Then the next few months were mostly taken by a "Kill Bob's code" epic.
Poopieplatter@reddit
I'm telling ya! The obsession with making code as abstract and unreadable as possible baffled me. He was so callous on PR comments. Like, bro, we're a team here. Chill and be nice. Uplift your teammates, don't stomp on em.
jl2352@reddit
This is the classic lone wolf IC. They’ve been at the company for a long time. They got shit done. They get on with management.
So management reward them with doing whatever the fuck they want.
Your solutions are: * get management to take this very seriously and try to change their behaviour * you start to creep in standards changes. Bring in code coverage reports, and PRs cannot be merged without it going up. Some of your customers might require all code is reviewed; bring that in. Have meetings with others where you build standards together. Make it that the entire team is working to a higher standard, and whenever Bob interacts, he gets judged by it. If Bob complains, you’re just using standards. * work with Bob to improve his behaviour — this depends on how well Bob gets on with others on a personal level * sandbox Bob. Bob has his playground, you have yours, and you just don’t interact. You avoid his work at all costs. * Bulldoze over Bob’s work. Get invested in it. Learn how it works. Chat with the rest of the team … and then start refactoring. Bring in tests. He goes on holiday … perfect! Take ownership and force your ways over his.
^ I’ve seen various mixes of the above work.
The problem with your strategy is they just see you complaining about code style, and they don’t get it. Meanwhile they see Bob delivering. Why would they change that?
Calm_Masterpiece3322@reddit
I'm guessing he is or was a Java developer?
Careful_Ad_9077@reddit
1) what's up with cod reviews?
2) I worked with Bob and I understand. The thing is that less savvy people ,(including bob) , will think that that kind of code is good code. He might even be getting his dopamine from creating clever code. Sadly I did not manage to fix bob back then, they would usually quit for a better job because they are oh so much more clever than the rest of the team.
3) I was bob too, I got my dopamine from creating good, clever code.thankfuly I met an ex bob, he created good code that was easy to maintain and understand even for complex business requirements. He got his dopamine from applying his skills to create good code that was easy to understand and maintain, so that new requirements had a fat turnaround time. So I learned from him , to out my skills there.
The less experienced your bob is, the more effective it should be to change his pov on this. I actually have had a harder time with the guys who want their code to just work actually.Unless your bob is just out of school, ofc that coupled with a bad attitude is just unworkable, as they have no idea of a maintenance cycle.
Material-Smile7398@reddit
NoleMercy05@reddit
You've always got one
Alarmed_Inflation196@reddit
Perhaps start documenting technical standards and principles for your team. Then you can keep it neutral: it's not about Bob, it's about the PR not adhering to the standards.
Can you get some kind of (AI) analysis tool enabled that scores code complexity? Get something/someone outside the team to also call it overly complex.
Complex code is often harder to test - make sure to include test coverage in those standards.
It's hard because once it's in the code base, it's suddenly everyone's code. It has to be prevented.
> It also seems that every time Bob goes on vacation, something inevitably breaks with something of his and it can take the team a painstakingly long time just to trudge through one of his codebases trying to track down the source of the problem.
Does this never come up when he's around? What happens? Does he take delight in being the person to fix his own code? I
karma-md@reddit
Are you sure he isn't just better than the rest of you? Good code can appear bad and overcomplicated to people who don't understand architecture and design patterns. Try asking why he designed it like he did.
tikhonjelvis@reddit
I worked with somebody like this. I tried pushing back pretty hard, talking to management... nothing worked until he left the team. But, as a bonus, I got a lot of trust after that once everyone realized just how painful his old code was to work with now that he was gone :P
At the end of the day, it's a matter of taste. There is absolutely such a thing as good taste and bad taste, but it's hard for most organizations to acknowledge good taste, much less actively support it. I've seen it happen when teams grew with good taste and strong technical leadership from the beginning, but I still have absolutely no idea of how to inculcate good taste at an existing team that lacks it.
The_Axolot@reddit
I named him "Steve" in my satire articles. He's amassing power.
graph-crawler@reddit
Here goes Bob's so called job security.
PothosEchoNiner@reddit
This is always a liability when you have services or code that belong to one person. There should be no Bob’s code, only the team’s code.
OldeFortran77@reddit
There are some "Bob"s in the thread. Instead of picking up the main point (the entire rest of the team has trouble following Bob's code) they want to nitpick the general description of the problem and tell you why the OP is wrong.
graph-crawler@reddit
Enforce a policy, maintain the shit that you wrote.
Far-Consideration939@reddit
It’s either your fault for allowing it or a skills issue if the complexity warrants it.
_ncko@reddit
I have somebody like this on our team who has a PhD in Computer Science and has been working at the company for a long time so he is very well respected. It has affected the culture of the engineering team so that everything is way way way over abstracted.
KaleRevolutionary795@reddit
Do you not have clear policies on what coding standards, paradigms, patterns, architecture to use? And do you not have approved naming conventions, code structure and what libraries are allowed/dissalowed?
It's possible he's actually using clean architecture recommendation (hexagonal) but he's mixing it in with the rest of the project when that's going against what is already there. And he shouldn't be allowed to do it.
How to get out of this: Setup a team for coding standards and guidelines. Produce recommendations and set the new policy. Then when he tries to get something through code review ENDLESSLY enforce the policy until its right. Don't let him merge, put a block on direct merges to main and let it be possible only through review. (2 approvers is standard)
Now. If you're brave: put him on that recommendation team and let him state his case. If there's a real reason behind it maybe you can all learn from it.
bombaytrader@reddit
time to fire him. I have worked with such ppl. They think they are doing a smart thing like writing a difficult to understand one liner in ruby / python. Management thought they are smart and they were dont get me wrong. Had raw talent and motivation but difficult to work with. Ended up leaving in a year.
ZukowskiHardware@reddit
Good software developers are good at writing “dumb” code. You are 50% stupider when you go back to maintain even your own code, so I always write stuff at 50% of my intelligence. Being able to write simple things that can be used in series is truly elegant.
ZunoJ@reddit
Sometimes code seems very complicated until you understand the paradigm. Once you got that it becomes simple to understand, maintain and extend. But if you don't make an effort to understand the overall pattern it is just a complicated mess
irespectwomenlol@reddit
Is Bob the team leader or not? Or are you just a team of 8 equal engineers?
Software_Engineer09@reddit (OP)
Bob is an IC, I’m the team lead. Bob is “part” of the team, but he doesn’t report to me, if that makes sense.
marvdl93@reddit
Huh no this doesn't make any sense? How is Bob's technical supervisor? This technical supervisor should have a talk with Bob regularly and express the concerns. This doesn't sound like a Bob problem but an organizational problem.
fobos78@reddit
Who approves PR ? Can Bob push code without any approbation ?
Bicykwow@reddit
Any chance you work at Figma? lol
Software_Engineer09@reddit (OP)
Lol glad others have experienced the same thing and I’m not alone!
Bicykwow@reddit
I just used to work with someone who's a "lead" at Figma now, and holy fuck-- the biggest overcomplicator I could have ever imagined. 2nd only to a guy who works for, unsurprisingly, Atlassian.
rashnull@reddit
Propose the refactor to simplify the code base. Get it reviewed. Then push it. If Bob pushes back, get them to explain “why” in writing.
matthra@reddit
Make him document his code, if it's easy for him to understand it should be easy for him to document. Blame it on getting ready for new hires, and pip him if he refuses. Having worked with a few such "Rockstar" devs they inevitably do more harm than good, especially if allowed to ignore best practices.
Moonskaraos@reddit
Sounds like Bob drank a little too much of ol’ Uncle Bob’s kool-aid.
powdertaker@reddit
I worked with this same type of person. Extra Points: He'll tell you how it's Best Practices and easier to understand.
Software_Engineer09@reddit (OP)
Lol oh my you really have worked with a “Bob”!
Illustrious_Stop7537@reddit
I've got some experience with over engineering too! But seriously, I think it's great that you're thinking about how to make our code more robust, just maybe try to balance that with being maintainable, right? Maybe we can work together on creating a 'good enough' version and then revisit the over engineered parts once we've got a better feel for what works?
horizon_games@reddit
Stop with the AI response slop
TalesfromCryptKeeper@reddit
I'm shocked at how easy it's become to identify generated replies like this. It's almost....condescendingly saccharine mixed with an eager to please puppy
matthra@reddit
Survivorship bias, you just spot the low effort ones.
TalesfromCryptKeeper@reddit
Yeah, good point.
horizon_games@reddit
Yeah like a human being friendly at least is still different enough than the fake platitudes of AI
im-a-guy-like-me@reddit
A db call going through a couple classes and interfaces isn't over-engineered, it's just the repo pattern. 🤔
Software_Engineer09@reddit (OP)
It was just an off the cuff example lol, it’s usually way worse than just jumping from front end to service layer to repo to make a call. I had one not long ago that I had to skip through 10 classes to get to the actual line of code where a simple query was ran.
cellularcone@reddit
Hey I know Bob! He’s my coworker too.
f1datamesh@reddit
Hi!
First question. Is he close to the management, since he's been there the longest and also because mgmt doesn't seem to do anything about it? Knowing that dynamic is very important to how you can proceed.
Mirage-Mirage-Mirage@reddit
Ask Bob to explain or justify his design decisions. Present alternative implementations and discuss the tradeoffs. This should be happening as part of the SDLC. Bob shouldn't be off by himself writing and deploying code completely alone.
Antique-Stand-4920@reddit
Have you tried presenting the problem to management in terms of hours or money lost or opportunity cost? Telling a manager that you have to look at 5 extra classes to get something done isn't as impactful as saying that a production system was down 2 extra hours because it was difficult for X number of people to understand the code.