3 ms·

"If my users are inconvenienced, it is my fault, always." Good quote. I had a customer become irate with me before over untracked sales in my digital delivery

by bryanh 15y ago

"If my users are inconvenienced, it is my fault, always." Good quote. I had a customer become irate with me before over untracked sales in my digital delivery product. I knew that the error stemmed from their web designer using their own button code and not our specially crafted button code, and I tried to help them fix it but only upset them more. Its hard to take responsibility for things seemingly outside your control, but in the end it is your responsibility.

sliverstorm 15y ago
Habitually taking responsibility for things outside your control is probably a bad thing though.
- patio11 15y ago
  This is very much not the cultural norm over in these parts. I'd be curious to hear your reason as to why you think that. (Genuinely curious, not passive-aggressive "curious.") Particularly with specific regards to engineering, even things which are theoretically not within our control (e.g. the server going down because a technician tripped over the cable) are often inside our ability to affect (by picking a better provider, investing in a redundant setup, etc). This is good: after we know that things are generally within our capabilities to address, we'll address them, rather than thinking that it is outside the scope of our responsibility, capability, or authority. (Semi-related sidenote: For hackers who enjoy theology there is a doctrine in Catholicism called subsidiarity which, as a quick gloss, states that responsibility for solving a problem begins immediately local to the problem and then bubbles up to the lowest level of societal organization which is capable of resolving that problem. That level is obligated to solve the problem rather than passing the buck up, where it will not receive sufficient attention, or down, where it will not receive sufficient resources. I always thought, aside from being a good idea, this was virtually tailor made for programmers. It's like there is a papal encyclical on the canonical right way to do exception handling.)
  - scott_s 15y ago
    The bad kinds of stress - the kinds that wear on a person and cause burnout - are often caused by people worrying about things they can't control.
    - chernevik 15y ago
      "It's all personal, every bit of business. . . . If a bolt of lightning his a friend of his the old man would take it personal. . . . That's what makes him great. The Great Don. He takes everything personal. Like God. He know every feather that falls from the tail of a sparrow or however the hell it goes. Right? And you know something? Accidents don't happen to people who take accidents as a personal insult." -- Michael Corleone
  - gburt 15y ago
    I can respond to his comment from my own perspective. With my own customers, I have a policy of accepting blame for everything and always working to fix pretty much anything. This, semi-regularly, results in customers who notice this policy and take advantage of it. You end up in a situation where you either have to piss off a customer or do mountains of work that have nothing to do with the scope of your product simply because the customer is convinced its your fault (or he's a dink that knows if he pretends its your fault, he'll get something out of you). My biggest falling is that. And unfortunately, I feel that the customers who are like that, are also the ones who make the biggest noise. I'm in a relatively sensitive industry where my customers tend to be doing a lot of research before picking my product, so I can't afford to have any bad noise floating around. Just an anecdote/personal vent very related to the discussion.
    - powertower 15y ago
      GBScripts? Now we know where to go to get more then we pay for!
      - gburt 15y ago
        No, that isn't the business I was referring to. Those are usually pretty open and shut projects -- and I don't do many of them anymore. Thanks for the Internet sleuthing though.
- prawn 15y ago
  I think there are two factors. Clients want solutions, not excuses and they can often do without explanations. So, taking responsibility to solve a problem will (generally speaking, on average, etc) work in your favour if you have remotely appreciative clients. However, beating yourself up over it is best avoided.
bartl 15y ago
Perhaps you should have constructed an API, and tell them "This is what your code should abide to", instead of just giving them code for the button. That is: abstract the spec away from the actual code. If closer inspection shows that their code isn't following the spec, you've earned the right for some serious fingerpointing.
- bryanh 15y ago
  This is a good point. In my case, it was as simple as a PayPal button with an extra variable to track a product ID... pretty mundane. However, a feature to "check" (scrape) their button and ensure it is proper is probably in order.

by bryanh 15y ago

sliverstorm 15y ago

Habitually taking responsibility for things outside your control is probably a bad thing though.

patio11 15y ago
This is very much not the cultural norm over in these parts. I'd be curious to hear your reason as to why you think that. (Genuinely curious, not passive-aggressive "curious.") Particularly with specific regards to engineering, even things which are theoretically not within our control (e.g. the server going down because a technician tripped over the cable) are often inside our ability to affect (by picking a better provider, investing in a redundant setup, etc). This is good: after we know that things are generally within our capabilities to address, we'll address them, rather than thinking that it is outside the scope of our responsibility, capability, or authority. (Semi-related sidenote: For hackers who enjoy theology there is a doctrine in Catholicism called subsidiarity which, as a quick gloss, states that responsibility for solving a problem begins immediately local to the problem and then bubbles up to the lowest level of societal organization which is capable of resolving that problem. That level is obligated to solve the problem rather than passing the buck up, where it will not receive sufficient attention, or down, where it will not receive sufficient resources. I always thought, aside from being a good idea, this was virtually tailor made for programmers. It's like there is a papal encyclical on the canonical right way to do exception handling.)
- scott_s 15y ago
  The bad kinds of stress - the kinds that wear on a person and cause burnout - are often caused by people worrying about things they can't control.
  - chernevik 15y ago
    "It's all personal, every bit of business. . . . If a bolt of lightning his a friend of his the old man would take it personal. . . . That's what makes him great. The Great Don. He takes everything personal. Like God. He know every feather that falls from the tail of a sparrow or however the hell it goes. Right? And you know something? Accidents don't happen to people who take accidents as a personal insult." -- Michael Corleone
- gburt 15y ago
  I can respond to his comment from my own perspective. With my own customers, I have a policy of accepting blame for everything and always working to fix pretty much anything. This, semi-regularly, results in customers who notice this policy and take advantage of it. You end up in a situation where you either have to piss off a customer or do mountains of work that have nothing to do with the scope of your product simply because the customer is convinced its your fault (or he's a dink that knows if he pretends its your fault, he'll get something out of you). My biggest falling is that. And unfortunately, I feel that the customers who are like that, are also the ones who make the biggest noise. I'm in a relatively sensitive industry where my customers tend to be doing a lot of research before picking my product, so I can't afford to have any bad noise floating around. Just an anecdote/personal vent very related to the discussion.
  - powertower 15y ago
    GBScripts? Now we know where to go to get more then we pay for!
    - gburt 15y ago
      No, that isn't the business I was referring to. Those are usually pretty open and shut projects -- and I don't do many of them anymore. Thanks for the Internet sleuthing though.
prawn 15y ago
I think there are two factors. Clients want solutions, not excuses and they can often do without explanations. So, taking responsibility to solve a problem will (generally speaking, on average, etc) work in your favour if you have remotely appreciative clients. However, beating yourself up over it is best avoided.

bartl 15y ago

Perhaps you should have constructed an API, and tell them "This is what your code should abide to", instead of just giving them code for the button. That is: abstract the spec away from the actual code. If closer inspection shows that their code isn't following the spec, you've earned the right for some serious fingerpointing.

bryanh 15y ago
This is a good point. In my case, it was as simple as a PayPal button with an extra variable to track a product ID... pretty mundane. However, a feature to "check" (scrape) their button and ensure it is proper is probably in order.