Manager: Alice, yeah, I know I said we'd carve out time this sprint for you to work on the long-term fix. But this other hot feature request came in, and there's potentially a lot of money riding on getting it done quickly. So can you put off the long-term fix, maybe a week? Two tops. You can just put the ticket.. yeah that one.. back on the backlog. There you go. Thanks so much!
> ... the idea that they could call, say, Microsoft and get their bug fixed is pretty much a fantasy.
I don't know why you think this is a fantasy. I could call Microsoft right now and get an engineer within 24 hours to discuss an issue... I think that's our SLA. Might be a shorter time period for initial triage response. But typically we're talking to an engineer within a day. And yes, sometimes these discussions result in bug fixes in upcoming patches.
This is what first-class business support means. Large businesses want to be able to get someone on the phone to fix an issue, and they will pay well for it.
> It sounds like your account team is really letting you down here. We meet with ours, including SAs, bi-weekly. Generally we can get answers to our questions/issues within a few business days, including feedback from product engineers.
Thanks. So I see that this is not normal, maybe I can escalate.
I'm really lazy: if I were on the receiving end of emails with error messages that included instructions about how to fix said error I'd automate Freshdesk (or whatever ticketing system I was using) to respond with instructions specific to that error message, in the first instance, along with a note to get in touch again if that didn't solve the problem. I'd also set the ticket to autoresolve after a set period of time.
> someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too.
I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now.
> I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets).
In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it.
But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.
>Hey Jane, I need your input on how to prioritize my current work. Can you provide guidance on where I should focus?
>Bug XYZ was assigned to me and it's taking longer to complete because we have a dependency on Vendor ABC completing a change to their web service. This is impacting the commitment to my team on Feature 123 because we are near the end of our sprint.
>Lemme know.
Pss, amateur. That's way too many words.
Hi Jane,
should I keep fixing bug XYZ or focus on feature 123? Vendor ABC is taking longer than we thought to fix their stuff.
Bill
And sometimes add a smiley so they know you're not made of circuits yourself too.
When you have computer issues in a corporate env, you make a ticket.
Of course it does not help to solve the problem, but at least makes you feel better that you did everything you could.
> As a manager, sometimes you need to say things like, "This bug needs to be fixed by EOD tomorrow" so that your team understands the urgency and your expectations.
I'm sorry but you can do that without sounding both clueless and unreasonable. You can put everything else on hold, stop the line, explain why it's important for this to be fixed, etc.. to get the point across.
"This bug needs to be fixed by EOD tomorrow" would chip away at the trust I have with management and depending on other factors would lead me to brush up my resume...
> I mean no. If there is an error you should figure out what the problem is first.
Figuring out what the problem is may take time. If a problem is impacting a customer’s experience, I’d rather recover faster and then pull metadata later to try and understand the issue.
> Because of that, people hate to see only a loading spinner with no indication of progress or time.
I hate to see the loading spinner at all. It gives you no indication if something is actually happening. (Actually, I feel much the same about progress bars that don't indicate what steps are being taken, as well.) These things will happily sit there spinning forever, possibly doing something, possibly just frozen. Who knows? I hate having to choose between being patient (and possibly a schmuck) or stopping something and trying to solve the problem.
These things give no indication of what went wrong, no starting point for where to look, and nothing useful to tell tech support if you call.
Caller: I clicked 'Update' and it shows me three pulsing dots. It's not doing anything.
Tech: The process can take up to X minutes.
Caller: It's been three hours.
Tech: Sometimes it can take that long.
Caller: ???
Versus
Caller: I clicked 'Update' and it's been on 'reticulating splines' for an hour.
Tech: That's weird. That part of the process should only take a minute. Do X... does that work?
Caller: That worked, thanks!
I'm sure lots and lots of UI research has determined that people don't want to see the guts of an application and want it to work by magic. But I find it completely asinine.
> Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.
Don’t be so sure. Just because you’ve identified the issue or a good fix doesn’t mean the ticket won’t go in the backlog to die a slow death before you’re allowed to fix it.
> Are the people in charge of fixing the underlying issues themselves on call?
Yes - although we're on call frequently enough, and tasked with other priorities when we're not - so progress is slow. I mentioned in another comment as well that the executive focus is to do pretty much whatever our customers want, so this generally results in lots of new problems by the time we fix older ones.
> How about the people producing the changes that cause new issues?
They are responsible for fixing the code, but they can do so more during regular 9-5 type hours. They don't feel the same level of pain. I realise this is a problem, but thanks for suggesting it.
> were due to the fact that the product was shipped too early.
Can you explain more about this? The mantra is generally ship early and iterate fast.
How come the tech team was spending 80% in a bugs rat race?
The earlier statement of "80% of the time was wasted supporting clients" seems perfect? i.e. what else should you be doing other than supporting clients who are willing to pay with features and bug fixes?
> After you make a heroic temporary fix, please, ensure the permanent fix is applied later!
I've known people who would, depending on exactly how bad the failure was, outright refuse to apply temporary fixes precisely because they didn't believe that the business would fix things properly if the issue wasn't forced. And having watched how that particular company handled things, I can't say that they were wrong.
> A couple of weeks later he comes back, and reverses the bug. He had told his manager about the bug fix, and was berated for fixing in. In order to fix that bug, it had to be reported correctly, go through software update meetings, go through budgets, and the whole nine yards.
What do you mean you went and just fixed it!?
We need all of middle management to charge for the fix!
reply