Programming

26392 readers

181 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

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

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

143

Your Engineers Aren't Lazy, Your Codebase Is Punishing Them (piechowski.io)

submitted 5 days ago by codeinabox@programming.dev to c/programming@programming.dev

61 comments fedilink hide all child comments

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

[–] grueling_spool@sh.itjust.works 15 points 5 days ago (3 children)

I'm fully talking out of my ass here, but I feel like a quick "five whys" exercise at any given company would reveal that the real issue is neither engineers nor code, but rather something systemic.

[–] red_tomato@lemmy.world 14 points 5 days ago* (last edited 5 days ago) (2 children)

It’s usually because the engineers were rushed to deliver completely new features because the sales department over promised again.

[–] tatterdemalion@programming.dev 3 points 5 days ago

It is almost always that.

[–] bestboyfriendintheworld@sh.itjust.works 2 points 5 days ago

Dysfunctional engineering teams, that have no empathy for end users is an issue as well.

[–] jtrek@startrek.website 4 points 5 days ago (1 children)

We used to do retrospectives at one of my old jobs, because everywhere loves cargo-culting agile and scrum stuff.

I quickly realized that a lot of the problems were largely outside the team's control. It was shit like "The CEO doesn't believe in designers or UX, so he won't hire one, so we spend a lot of time doing that work badly ourselves." Or, "management is making us spend all this time in 'planning meetings' so we don't get anything done"

Stuff that has easy solutions, but we can't do because some idiot or powerful cry-baby is in the way.

[–] Kissaki@programming.dev 1 points 3 days ago

Retrospectives are great for finding and sharing a consensus on these kinds of issues. The team can weigh their options. Known limitations are much better than unknown ones. And often, some bandaids and workarounds are possible to diminish negative effects, at least to a degree.

I've definitely had things we had to wait for, or are still waiting for. At least we don't usually get outright rejections.

[–] cymor@midwest.social 3 points 5 days ago

Conway's Law