People on devRant: "it took me 1/2/3 hours to fix that bug, omg, what a time waste!!"

Me: *wrestles some bugs for 1/2/3 DAYS*

I'm confused, how is fixing a bug within hours a ranting material...?

  • 5
    Depends on the bug ;). But I had one we hunted for months.

    It was intermittent and was triggered by aggregated actions and we never actually found out the exact tigger mechanism.

    After multiple fixes where we found theoretical possible cause we got it down to two or three times per year over all customers together.

    But it still happened the last year I worked there.

    We did have a plan that should eliminate the possibility but it required a complete redesign of the database storage and was a more long term change that was still in the to do list.
  • 1
    @Voxera THAT I understand. That's something annoying and makes one rant away.

    But I don't think I've ever seen you rant along the lines of "oh my, I've just spent 1 hour to fix this bug, omg, that's the time I'm never getting back"
  • 0
    There's a lot of bragging that goes on. I've sometimes considered asking particularly immodest posters if they they think this is 'DevBoast'...
  • 3
    One hour can feel long already if the bug is in the code you just wrote and should be obvious but you just can't see it.
  • 2
    The level of bug,complexity is an indicator of the team ability, the product maturity, and managment.. "involvment".
    1-3 hour bug fix can be at the level of NPE, OOB, center a fuckin div, stupid logic error, unhandled exception, simple optimizations, etc.

    1-3 Days is a memory leak, data migration, IO insanity, more optimizations, "lets slap a memcache on it", etc.

    A 5+ days bugs, is arch releated, a hiesenbug, deep performance problems, 3rd party module, an elusive memory leak, etc.

    If the company is at the first level - that means two of the following: new codebase, idiot devs who wrote the thing, and "fuck it all, lets ship" managers.

    Second type is the same, but with tests, and lots of manual QA.

    Third is a mature codebase with areas marked as "don't touch. why? bc Moron dev who no longer works here said not to touch, 6 y ago!", lots of tests that take 22
    hours to run, 6 levels of managment approvals for code changes, and burned out devs analysing 6TB of logs daily.
  • 1
    @magicMirror I feel personally attacked by your comment on TBs of logs 😂
  • 0
    @netikras no, a bug you fixin an hour is not really a problem.

    And besides, if I would count them I would never get to the finish :P
  • 1
    @magicMirror I find all three exist in any decently sized code base.

    But my months/years old bug was most likely my own doing since I designed the database schema originally :P and never imagined the scale it would grow to.

    And we did not have many of the problems, tests ran in about 5 minutes, new code deployed at least twice a week with very rare rollbacks.

    Most bugs that made it past testing was fixed within one or a few hours after being discovered.

    But the code base was just over 16 years old having been ported from vbscript to c# and net framework.

    And most of it had been rewritten more than once i er the years.

    All decisions and approvals for new code or deployment was done by the dev team, and we all shared a big room so most decisions took a few minutes or at most an hour if we have many options to evaluate.

    Anything more complex was made into a task to gather more info before being discussed.

    But with so much code over so much time there had been growing some undocumented and unexpected behaviors and most likely race or multi threading problems.
  • 0
    @Earu At least it was not coming in from 100m android devices for you to analyse...

    @Voxera Thats sounds very nice. Eng managers/founders?
  • 1
    i've seen people fixing 20 bugs per work day

    i've seen people fixing bug in under 15 seconds, with commit and push
  • 1
    @magicMirror not really, single owner that was more focused on the personnel than maximizing profit’s.

    He had no family after a bad divorce so threw him self into the company.

    Not all good but it gave us devs much freedom to work as we thought was best for the product and customers without shareholders breathing down our necks.

    It did however put some limit on the growth since he was scared to expand so, I ended up leaving for a bigger company after many years.
Add Comment