this post was submitted on 31 Mar 2026
169 points (99.4% liked)

Programming

26304 readers
1077 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

A client’s team spent a full week adding a CSV export to their admin panel. Two engineers, clear requirements, maybe a day of actual work. The rest of the time went to understanding existing code well enough to change it safely. That’s what I call codebase drag: when the codebase makes every task take longer than it should. It doesn’t show up in any dashboard or sprint report.

you are viewing a single comment's thread
view the rest of the comments
[–] bestboyfriendintheworld@sh.itjust.works 5 points 1 day ago* (last edited 1 day ago) (2 children)

A good alternative is code presentations.

You present your changes to a group of engineers. Then discuss it.

argue

Yes, it happens too often. That’s a failure of leadership or a social problem.

Techies often try and fix human and social issues with technology, but that doesn’t always work.

Code review helps spread knowledge about the code base through the team. Without it, you easily end up with disjointed fiefdoms ruled by petty code lords that don’t share information.

[–] the_radness@lemmy.world 7 points 1 day ago (1 children)

Spreading knowledge and context sharing are exactly why I like code reviews. It should also be something done by more than one person so that information is better disseminated throughout the team.

Code presentations are great for that.

One or two people present their code before the merge. Others watch, ask questions, etc. Small changes and improvements can be done immediately. Ideally the change is merged after the presentation. It can speed up things immensely and more people feel ownership. If a simple ticket stays in review for a week, it can be very detrimental.

[–] resipsaloquitur@lemmy.world 5 points 1 day ago* (last edited 18 hours ago) (1 children)

I mean, what we have now is a clique of ideologically-aligned people who insta-approve each other’s bad PRs outside their domain and ignore or jam-up the PRs of people outside their clique.

You can say it’s a failure of management, but this is the primary tool used by the ideologues. And I’ve seen it used so at various places.

What I haven’t seen is a real dissemination of knowledge about the code via review. At least not above and beyond what can be achieved by looking at the code and using blame to see the changesets and looking at the associated issues.

[–] bestboyfriendintheworld@sh.itjust.works 3 points 1 day ago (1 children)

This kind of social behavior is corporate politics and a failure of management of course.

[–] resipsaloquitur@lemmy.world 1 points 23 hours ago (1 children)

Okay, I’ll go tell management they’ve failed. 🙄

No, you tell about management the problem and how only their amazing social and people skills will be able to do something about it.