3 ms·

The OP was saying "don't just say what you did - say what the impact was!" (in so many words). Well... the impact was that this thing I delivered went way over

The OP was saying "don't just say what you did - say what the impact was!" (in so many words). Well... the impact was that this thing I delivered went way over budget, and the division shut down because we ran out of money. Or... what if the impact is "user subscriptions decreased, cancellations increased, revenue declined"? I was pointing out that "impact" isn't always positive - adding it to a resume might not be all that useful. This happened to me. Was told to convert a lot of stuff to an XML database, which... no one had any experience with. But the owner wanted to be in the XML space. They sold a deal which was based on the XML database tech, but it was so bad, and so slow, and didn't actually take customer needs in to account, that we burned over $1m over 6 months, and half the company was laid off. So, yes, I can put "XML database conversion" on a resume, but there's no positive outcomes to add to it. This is what the OP was being told to do - add positive outcomes. They don't always exist, and yes, it's outside your control.

avmich 3y ago
It's also often outside of your knowledge. You just too often don't have anything close to useful statistics which you can refer to. Say, replacing one message queue solution with another, because the first was considered - you may not know or agree with all the details - too slow or too unreliable. How does it help if you don't have enough knowledge about how often the previous one failed? The new one has better performance, but you don't have enough traffic to feel the difference - then what? All you see on the justification side is several logs where the error is present and maybe some obscure post on the Internet complaining about similar issues, and then you have a decision from above. And such situation could be quite typical.
- em-bee 3y ago
  this. in one job as developers we never got to see any data from production side. we were just told what features to implement or what bugs to fix, without any feedback on their impact.

avmich 3y ago

It's also often outside of your knowledge. You just too often don't have anything close to useful statistics which you can refer to. Say, replacing one message queue solution with another, because the first was considered - you may not know or agree with all the details - too slow or too unreliable. How does it help if you don't have enough knowledge about how often the previous one failed? The new one has better performance, but you don't have enough traffic to feel the difference - then what? All you see on the justification side is several logs where the error is present and maybe some obscure post on the Internet complaining about similar issues, and then you have a decision from above. And such situation could be quite typical.

em-bee 3y ago
this. in one job as developers we never got to see any data from production side. we were just told what features to implement or what bugs to fix, without any feedback on their impact.