Programming

17364 readers

179 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 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

122

I Don't Trust My Own Code (lackofimagination.org)

submitted 5 months ago by Aijan@programming.dev to c/programming@programming.dev

37 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] JustBrian7872@feddit.de 16 points 5 months ago (4 children)

As a dev I've been on both sides to be honest. Especially when there is pressure to finish the next task. I think it needs good planning to create enough time for these things.

In the end bad devs will still shut you up about things they are not interested in fixing...

[–] jjjalljs@ttrpg.network 21 points 5 months ago (3 children)

I've done a lot of "then go get approval from the stakeholder to go ahead with this bug/problem".

If product wants it out now now now they can sign off on it not working on mobile, so when their boss has a fit about it I can point to the conversation where Ryan said it was fine.

I've mostly worked at smaller companies though.

[–] NotMyOldRedditName@lemmy.world 3 points 5 months ago (2 children)

I've caught problems in code review and had to do this even.

Often it's reading it and realizing there's a complicated edge case or they missed something entirely.

Sure we can make a different ticket for that to move this along, but we're getting product to agree first.

[–] abhibeckert@lemmy.world -2 points 5 months ago* (last edited 5 months ago) (1 children)

Sure we can make a different ticket for that to move this along, but we’re getting product to agree first.

Ooof, I'm glad I never worked there.

QA's job should be to make sure the bugs are known/documented/prioritised. It should never be a roadblock that interrupts work while several departments argue over what to do with a ticket.

Seriously who cares if the current ticket is left open with a "still need to do XYZ" or it gets closed and a new one is open "need to do XYZ". Both are perfectly valid, do whichever one you think is appropriate and don't waste anyone's time discussing it.

[–] NotMyOldRedditName@lemmy.world 1 points 5 months ago* (last edited 5 months ago)

No one cares if you leave a ticket open due to a bug or incomplete feature

Product sure as hell cares if you're going to ship a bug or incomplete feature.

Never worked at company that wasn't the case in over 15 years.

Product owns the work they ask us to do. We do their bidding.

And we certainly aren't allowed to just change the scope of tickets at our own discretion without checking in