3 ms·

This article made a number of great points. > I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming ther

by rurp 6y ago

This article made a number of great points. > I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything. God, this behavior has annoyed me so much at times. I've worked with a few developers that were not bad overall, but would use the slightest excuse to punt on fixing an issue they were tasked with but didn't want to track down. Regularly weaseling out of tasks like this wastes the time of multiple people and either ends up back with the original dev or gets dumped on a more responsible worker. > Because I took the time to verify if there were other parts of the code that might be affected in similar ways. Not looking for other places in the code that are very likely to be affected by the same issue is bafflingly common, in my experience. Although I would say that managers are much more often to blame for this behavior than the devs. Any workplace that puts less weight on fixing an issue well than on artificial metrics like number of tickets closed is incentivizing exactly this type of behavior. Why bother getting criticized for spending all day fixing a simple bug the right way when you can fix 5 different iterations of that same bug and close 5 tickets in the same amount of time?

csharptwdec19 6y ago
Oddly, I've worked at places where they PREFERRED minimized changes to bugs. i.e. "You made a whole new method to deal with this problem, is there a smaller fix?" Thankfully most places I've been at -prefer- a smaller fix even if it takes a little longer to figure out.
flukus 6y ago
> Regularly weaseling out of tasks like this wastes the time of multiple people and either ends up back with the original dev or gets dumped on a more responsible worker. A lot of this depends on the environment and circumstances. If you're in the middle of working on feature X it's very annoying to have to drop it to look at a bug, sometimes it's necessary but usually it can wait. This is where having great user support comes in too, capturing what the user was doing, getting relevant logs and knowing how to reproduce are important and if you don't have a good support team that falls to the developers. The other big factor is external pressures, if you have management asking for frequent updates and putting pressure on to get through tickets quickly (especially common at consultancy type shops) then bug fixing is miserable high pressure work that I will avoid at all costs. An environment without those and bug fixing can be fun, give me the biggest most spaghetti like enterprise system and no time pressure and it feels like getting paid to solve a giant Sudoku puzzles all day. While we're all swapping war stories I'll share my most epic 2 line fix at a place were I was afforded the time. I was working on this huge mess of over abstracted, multi threaded, spaghetti enterprise OO, trying to track down a bug that happened maybe once a fortnight. I tried narrowing it down to reproduce but nothing was working, the stack trace was about 15 levels of indirection away from the trigger so the most I could narrow it down to was hundreds of thousands of lines of code. After a couple of weeks of trying things and getting nowhere I told the boss we'd probably never track this down but they insisted I keep trying. Eventually I wrote a script to copy all the logs locally where I could search and do some analysis on them, after grepping 18 months of logs I noticed that on 3 or 4 occasions the same error was happening within 5 seconds of each other. From there it was a matter of finding "Sleep(5000)" in the code to know exactly where the error was. Turns out that 15 levels of indirection was quite slow and getting a stale piece of data we already had anyway so the time wasted turned into a nice little improvement. The scripts for the logs become invaluable too. So many times we got "you incompetent idiots broke x with your last update" we could reply a minute later with "x has been happening since <time before any of us worked there>, you only just noticed".

by rurp 6y ago

csharptwdec19 6y ago

Oddly, I've worked at places where they PREFERRED minimized changes to bugs. i.e. "You made a whole new method to deal with this problem, is there a smaller fix?" Thankfully most places I've been at -prefer- a smaller fix even if it takes a little longer to figure out.

flukus 6y ago

> Regularly weaseling out of tasks like this wastes the time of multiple people and either ends up back with the original dev or gets dumped on a more responsible worker. A lot of this depends on the environment and circumstances. If you're in the middle of working on feature X it's very annoying to have to drop it to look at a bug, sometimes it's necessary but usually it can wait. This is where having great user support comes in too, capturing what the user was doing, getting relevant logs and knowing how to reproduce are important and if you don't have a good support team that falls to the developers. The other big factor is external pressures, if you have management asking for frequent updates and putting pressure on to get through tickets quickly (especially common at consultancy type shops) then bug fixing is miserable high pressure work that I will avoid at all costs. An environment without those and bug fixing can be fun, give me the biggest most spaghetti like enterprise system and no time pressure and it feels like getting paid to solve a giant Sudoku puzzles all day. While we're all swapping war stories I'll share my most epic 2 line fix at a place were I was afforded the time. I was working on this huge mess of over abstracted, multi threaded, spaghetti enterprise OO, trying to track down a bug that happened maybe once a fortnight. I tried narrowing it down to reproduce but nothing was working, the stack trace was about 15 levels of indirection away from the trigger so the most I could narrow it down to was hundreds of thousands of lines of code. After a couple of weeks of trying things and getting nowhere I told the boss we'd probably never track this down but they insisted I keep trying. Eventually I wrote a script to copy all the logs locally where I could search and do some analysis on them, after grepping 18 months of logs I noticed that on 3 or 4 occasions the same error was happening within 5 seconds of each other. From there it was a matter of finding "Sleep(5000)" in the code to know exactly where the error was. Turns out that 15 levels of indirection was quite slow and getting a stale piece of data we already had anyway so the time wasted turned into a nice little improvement. The scripts for the logs become invaluable too. So many times we got "you incompetent idiots broke x with your last update" we could reply a minute later with "x has been happening since <time before any of us worked there>, you only just noticed".