3 ms·
Thanks for sharing the story. Looking back, I realize that I had noticed bugs filed months prior. I don't even know what they are about because I subconsciousl
by songzme 9y ago
Thanks for sharing the story.
Looking back, I realize that I had noticed bugs filed months prior. I don't even know what they are about because I subconsciously avoid them. (perhaps out of fear?) Assuming that these are valid tickets (and not outdated), I subconsciously avoided tickets that are months old. Probably because:
1. Bugs that are months old are probably super complicated and will take up a good chunk of time to solve.
2. Since the bug is so old, its not on anybody's priority list. Picking it up just translates to me sacrificing time from my family and hobbies.
3. Even if I go out of my way to sacrifice my time to fix a bug for a customer, there is rarely any gratitude (especially since the issue is months old). Typically, a follow up response would be (rightfully) along these lines: "It took you guys 6 months to fix my problem. Can I get refunded for the past 6 months?"
Knowing how much stress and pain this bug (probably very unique) has caused the author, I will make it a point to always understand old tickets and prioritize it with management to make sure they get resolved promptly.
Is it okay for an engineer to take responsibility for a client and reach out to them directly instead of through an middle man support? Say I was an engineer working on google drive, could anything go wrong if I tweeted author and told him I would personally look into his issue and work with him on it?
- scarmig 9y agoDepends on company culture. I would expect that a Googler would get into some trouble (at the very least step on some toes, though that might be warranted in this situation) if they basically cut out the team this particular bug was triaged to. Probably better to escalate internally and have the engineers actually responsible for fixing the bug have it made a higher priority.
- Nition 9y agoAnd yet for the customer, it's so much better if the engineer contacts you and tells you they're actually working on your problem. This is why people love dealing with small businesses who don't have those layers of bureaucracy. "Wow, I'm actually talking to someone in a real conversation like a normal human being."
- scarmig 9y agoThat is part of the trade off between going big and enterprisey versus small and human. I think sometimes it makes sense to go one way, other times it makes sense to go the other.
- myelin 9y agoI work at Google, and get pull requests from people on other teams fairly frequently. It's usually stuff like "I found this particular pattern results in a memory leak, and fixed it Google-wide", but sometimes it's "hey, I used your code, and fixed a bug". It's a bit like how things work in the open source world; it depends on the situation and the individuals, but patches are usually welcome. The only case where I can imagine someone getting into trouble would be if they spent a ton of time fixing a random bug when they're meant to be working on something else, and it resulted in something important getting held up.
- martinpw 9y ago> Is it okay for an engineer to take responsibility for a client and reach out to them directly instead of through an middle man support? The problem with this is that the client now has your direct contact information. If you help them out, then you can bet the next time they have an issue they are coming straight to you rather than going through official channels. If they work at large customer your contact may get passed around within their company and you run the risk of being overwhelmed or having to start directly turning down requests for help. You really don't want to be in that situation.
- dx034 9y agoYou can still handle it via the ticketing system so that the user writes to some generated email address, not the direct email address. Would probably have to happen anyway to ensure the conversation is logged properly.