5 ms·

Do people actually do that? Finding bugs in virtually any piece of software isn’t difficult if you have access to the source. Merging in a bug only to fix it la

by dntrkv 2y ago

Do people actually do that? Finding bugs in virtually any piece of software isn’t difficult if you have access to the source. Merging in a bug only to fix it later honestly seems like more work. Most bugs are pretty easy to fix…

elzbardico 2y ago
> Finding bugs in virtually any piece of software isn’t difficult if you have access to the source. What???? Yeah, trivial bugs maybe. Even because most "hairy" bugs (and those are the one that count by the end of the day) manifest themselves not in obvious ways, but only under some hard to predict set of pre-conditions and input data. And let's not even get started on threaded/asynchronous code.
- dntrkv 2y ago
  Most bugs are trivial to identify and trivial to fix. At least that’s been my experience from 15 years as a SWE in start ups and FANG alike. Yes, I’ve worked on bugs that have taken weeks to fully resolve. But those are rare.
tikhonj 2y ago
A much more common story would be people knowingly cutting corners because of management pressure/demotivation/etc, then fixing the resulting bugs. It's easy for somebody doing that to look like a hard-working hero compared to the programmer who just avoided the problems in the first place.
- Vampiero 2y ago
  No, if A's PRs always bounce because the testers find bugs then A is going to look like an idiot. Then again you need to work at a place that actually employs testers. If B always submits PRs and they always go straight to merged in prod, then B knows what he's doing
  - imtringued 2y ago
    Actually the testers are glad there is someone giving them work to do. Self licking ice cream cone and the like. Republicans don't want to fix immigration, otherwise they have nothing to complain about.
  - einsteinx2 2y ago
    You guys have testers???
- tbrownaw 2y ago
  I've seen a lot of fairly explicit discussions around "this timeline will require cutting these corners and cost this much time to fix later or else it will cause these problems", and also some relatively internal discussions around "how strongly can we rely on promises that the project won't get dropped before all the cleanup is done, and how does that impact what options we can present".

by dntrkv 2y ago

elzbardico 2y ago

> Finding bugs in virtually any piece of software isn’t difficult if you have access to the source. What???? Yeah, trivial bugs maybe. Even because most "hairy" bugs (and those are the one that count by the end of the day) manifest themselves not in obvious ways, but only under some hard to predict set of pre-conditions and input data. And let's not even get started on threaded/asynchronous code.

dntrkv 2y ago
Most bugs are trivial to identify and trivial to fix. At least that’s been my experience from 15 years as a SWE in start ups and FANG alike. Yes, I’ve worked on bugs that have taken weeks to fully resolve. But those are rare.

tikhonj 2y ago

A much more common story would be people knowingly cutting corners because of management pressure/demotivation/etc, then fixing the resulting bugs. It's easy for somebody doing that to look like a hard-working hero compared to the programmer who just avoided the problems in the first place.

Vampiero 2y ago
No, if A's PRs always bounce because the testers find bugs then A is going to look like an idiot. Then again you need to work at a place that actually employs testers. If B always submits PRs and they always go straight to merged in prod, then B knows what he's doing
- imtringued 2y ago
  Actually the testers are glad there is someone giving them work to do. Self licking ice cream cone and the like. Republicans don't want to fix immigration, otherwise they have nothing to complain about.
- einsteinx2 2y ago
  You guys have testers???
tbrownaw 2y ago
I've seen a lot of fairly explicit discussions around "this timeline will require cutting these corners and cost this much time to fix later or else it will cause these problems", and also some relatively internal discussions around "how strongly can we rely on promises that the project won't get dropped before all the cleanup is done, and how does that impact what options we can present".