Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
SnafuAI6974yFor me the answer is no.
I always refused to do something that I found wrong/stupid/un-proffesional/etc. Sometimes the fallout from such a refusal was quite serious (escalation to management, warnings) but I would rather go job hunting than producing something that I could consider defendable.
@smb26 I only ever see two versions of blame. One is where people solve problems and don't point fingers. Nobody blames anyone. The other is where blame is assigned to a scapegoat. You'd think there would be some sort of middle ground.
At one place I worked a new developer had to make changes to an app where all of the source branches had meaningless names and none of them was "master." No one knew which one was in production. It was a mess.
I helped the developer sort out which code to work in even though I was not assigned anywhere near that task. It was a lot of work. Then he used the wrong code anyway. I had emails showing it.
They blamed him because he was new. Then they blamed me because... they couldn't say. I explained that I spent hours helping him sort it out, and then he made a mistake. The reply, verbatim: "You could have done more." That's it.
If you're going to blame, what about the folks who made the mess or the manager who put the new guy in that position?
@smb26 - Since I'm trying to get other peoples' thoughts I should have refrained from commenting myself. The question itself is probably too long already.
Maer18314yYes, I experienced this scenario. Over the course of university I have paid for everything myself, without any financial backbone or parental help, merely by havind a dev job while studying. Thus I did not see myself in a position to push back too hard towards management, because the pay and especially flexibility with respect to when do I do my work was not something I would get elsewhere.
There was no such thing as telling me to implement bad things, only deadlines were impossible to meet, the company kept ignoring technical debt as well as the dev team telling management that this would happen and the more this went on, the more I was putting out fires insead of developing new things.
An extreme example of technical debt creation: Once I was asked to implement a feature in the morning, to be shown to a customer by midday and then go live in production (!) in the afternoon. No testing whatsoever.
Maer18314yA colleague spent two nights in the office, was then still treated badly ("what, you are still not done?" at 10am after he still did not go gome) and I caught him crying in the bathroom. So I decided at that point to take the leap and left, informed some colleagues I trusted prior (but not so prior that it may result in bad consequences for myself) and ultimately took 4 people with me, which is a lot for a company of 12 people, where two were interns and some did not belong to development at all.
Getting away from there as fast as possible has done wonders for my health, because I was extremely mentally stressed in that time, due to pressure from management and no acknowledgement or thankfulness.
To finally answer the initial question, yes and no. I did feel responsible for my work, but I too did realize that the fault lies not with myself, as objections to those practices were raised frequently by myself and colleagues. It *is* still your code, however.
When Do You Stop Taking Responsibility?
Let me clarify by describing four scenarios in which you are tasked with some software development. It could be a large or small task. The fourth scenario is the one I'm interested in. The first three are just for contrast.
1. You either decide how to implement the requirements, or you're given directions or constraints you agree with. (If you hadn't been given those specific directions you probably would have done the same thing anyway.) **You feel accountable for the outcome**, such as whether it works correctly or is delivered on time. And, of course, the team feels collectively accountable. (We could call this the "happy path.")
2. You would prefer to do the work one way, but you're instructed to do it a different way, either by a manager, team lead, or team consensus. You disagree with the approach, but you're not a stubborn know-it-all. You understand that their way is valid, or you don't fully understand it but you trust that someone else does. You're probably going to learn something. **You feel accountable for the outcome** in a normal, non-blaming sort of way.
3. You're instructed to do something so horribly wrong that it's guaranteed to fail badly. You're in a position to refuse or push back, and you do.
4. You're given instructions that you know are bad, you raise your objections, and then you follow them anyway. It could be a really awful technical approach, use of copy-pasted code, the wrong tools, wrong library, no unit testing, or anything similar. The negative consequences you expect could include technical failure, technical debt, or significant delays. **You do not feel accountable for the outcome.** If it doesn't work, takes too long, or the users hate it, you expect the individual(s) who gave you instructions to take full responsibility. It's not that you want to point fingers, but you will if it comes to that.
That fourth scenario could provoke all sorts of reactions. I'm interested in it for what you might call research purposes.
The final outcome is irrelevant. If it failed, whether someone else ultimately took responsibility or you were blamed is irrelevant. That it is the opposite of team accountability is obvious and also irrelevant.
Here is the question (finally!)
Have you experienced scenario number four, in which you develop software (big as an application, small as a class or method) in a way you believe to be so incorrect that it will have consequences, because someone required you to do so, and you complied *with the expectation that they, not you, would be accountable for the outcome?*
Emphasis is not on the outcome or who was held accountable, but on whether you *felt* accountable when you developed the software.
If you just want to answer yes or no, or "yes, several times," that's great. If you'd like to describe the scenario with any amount of detail, that's great too. If it's something you'd rather not share publicly you can contact me privately - my profile name at gmail.com.
The point is not judgment. I'll go first. My answer is yes, I have experienced scenario #4. For example, I've been told to copy/paste/edit code which I know will be incomprehensible, unmaintainable, buggy, and give future developers nightmares. I've had to build features I know users will hate. Sometimes I've been wrong. I usually raised objections or shared concerns with the team. Sometimes the environment made that impractical. If the problems persisted I looked for other work. But the point is that sometimes I did what I was told, and I felt that if it went horribly wrong I could say, "Yes, I understand, but this was not my decision." *I did not feel accountable.*.
I plan on writing more about this, but I'd like to start by gathering some perspective and understanding beyond just my own experience.