4 ms·
A bit late to this thread, and this is coming from someone who used to code, but does not anymore, atleast not actively. Avoid what is known as 'Somebody Else'
by ankit219 8y ago
A bit late to this thread, and this is coming from someone who used to code, but does not anymore, atleast not actively.
Avoid what is known as 'Somebody Else's Problem Field' behavior. (Here is the link: https://en.wikipedia.org/wiki/Somebody_else%27s_problem https://en.wikipedia.org/wiki/Somebody_else%27s_problem)
What I mean to say is, a lot of times developers have an attitude which says "I'm done with my work, now if its not working, it's somebody else's task" or variants of that dialogue. As a developer, I understand and concur with your position that you might have done all the things right, but as a team, you are not helping matters by saying that. Volunteer to check your code, do more, and try to figure out where the problem is, like what input you are getting, what is the output, where is the code failing. the more you help in these cases, the faster the things get done.
This is also a common behavior, when someone asks you for a data or a piece of code, and you send her a straight forward export/import in the raw format. Occasionally, that might need the other person to do a lot of clean up and other operations, (with a bit less context), and would have been easy for you to do in the first place. As a developer I did that a lot. On the receiving end, this is one of the most frustrating things, since I need to account for it in my tasks beforehand. (Example would be a simple dataset, given to me at SKU level - cos requires a straightforward query - while if extracted aggregated, would have taken 5-10 more minutes for the developer, but now the asker is expected to spend sometime cleaning up and aggregating that data set. Might not always be this, but I hope you get the point.).
my 2 cents.