One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phras...
One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phrase "it works for me" from your vocabulary. The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Who knows? You, as an engineer, should always always always assume that something is broken until proven otherwise. You must assume that there is a bug, until you can prove that there is not. Once you have ruled out a code error, then you can step into assuming the user is wrong. "OK, I did it the right way and was unable to reproduce it. Therefore, the user must have done something incorrectly." Now you either try a bunch of different ways to accomplish it, or you go back to the user and say "I'm unable to reproduce this. Can you elaborate on the sequence of actions you took to cause this error?" But what you should never, ever do is just dismiss the customer's complaint as invalid because you were unable to recreate it. If you can't recreate it, then you need to figure out why. Was the bug fixed by something else? Was the user mistaken? Does it only happen on Tuesdays at 3pm? I'll say it again because it bears repeating: Remove the phrase "it works for me" from your vocabulary. From a reputation standpoint, it's bad news. The customer isn't always right, and you don't have to blindly believe them, but customers don't report things unless something isn't working for them. Trust that.
Posted by Jemaclus on May 1, 2015, 9:57 PM
Tags
Related issues
- You obviously did this for fun, I don’t want to throw any shade on it and have no criticism, I also make fun things just because.¹ So ta...
- Many devs love to shit on the guy from the 'I just want the exe.
- Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
- Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
- I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
- Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
Raise real-world problems, find people facing the same issue, and discuss solutions.7,000 issues0 comments
reliability (SaaS)
You obviously did this for fun, I don’t want to throw any shade on it and have no criticism, I also make fun things just because.¹ So ta...
NewMany devs love to shit on the guy from the 'I just want the exe.
Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
App broken with Mosquitto broker 7.0.0
One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phras...
One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phrase "it works for me" from your vocabulary. The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Who knows? You, as an engineer, should always always always assume that something is broken until proven otherwise. You must assume that there is a bug, until you can prove that there is not. Once you have ruled out a code error, then you can step into assuming the user is wrong. "OK, I did it the right way and was unable to reproduce it. Therefore, the user must have done something incorrectly." Now you either try a bunch of different ways to accomplish it, or you go back to the user and say "I'm unable to reproduce this. Can you elaborate on the sequence of actions you took to cause this error?" But what you should never, ever do is just dismiss the customer's complaint as invalid because you were unable to recreate it. If you can't recreate it, then you need to figure out why. Was the bug fixed by something else? Was the user mistaken? Does it only happen on Tuesdays at 3pm? I'll say it again because it bears repeating: Remove the phrase "it works for me" from your vocabulary. From a reputation standpoint, it's bad news. The customer isn't always right, and you don't have to blindly believe them, but customers don't report things unless something isn't working for them. Trust that.
Comments (0)
No comments yet. Start the discussion.