3 ms·
You can always quit. Or force them to fire you for refusing to implement a non fix. In reality though I doubt this narrative even occurred. Some incompetent e
by admax88q 8y ago
You can always quit. Or force them to fire you for refusing to implement a non fix.
In reality though I doubt this narrative even occurred. Some incompetent engineer likely proposed this fix thinking that it was actually a fix.
Edit: I see I've been downvoted for this comment. If we were real engineers working on things like cars and bridges we'd actually be held accountable. Take some pride in your work people, this is one of the most in demand professions in today's economy.
- pjmlp 8y agoQuitting assumes the possibility of finding a job around the corner and not having people that depend on you.
- konstmonst 8y agoYou might be surprised, but if you move to Europe, it is actually so! Move to Berlin of Frankfurt. There is always work for Software Developer here, it is hard not to get one and you get spammed by recruiters all the time. You don't have to take shit from management, you can just go elsewhere. Everything is also very near.
- JustSomeNobody 8y ago> Quitting assumes the possibility of finding a job around the corner and not having people that depend on you. Quitting assumes the possibility of finding a job after spending 4 months doing leetcode 6 hours a day and not having people that depend on you.
- jodrellblank 8y agoYou suggest it was just one lone engineer being incompetent. Then you respond to downvotes with the non-sequitur "take some pride in your work" - are you suggesting pride is a fix for incompetence? What?
- admax88q 8y agoThere are two points. 1) Any engineer involved in implementing this "fix" is incompetent. 2) If you are not incompetent and management tries to force you to implement this "fix" then you should take pride in your work and refuse to do it, even if it means quitting your job (or forcing the company to fire you).
- kstenerud 8y agoIt's easy to opine and judge from on high when it's not your nuts in the vice.
- Blaiz0r 8y agoDoesn't mean the point isn't valid though.
- kstenerud 8y agoIt's a problem of someone coming from a very incomplete view of the situation, and then issuing judgments and advice without doing any research into the actual situation on the ground (armchair warriors), which is irresponsible. Yes, there is a possibility that they are in fact right, but they'll probably be right for the wrong reasons. It's far more likely that they'll just be plain wrong (and arrogantly so). Even a stopped clock is right twice a day.
- jodrellblank 8y ago1) is obviously false, since an engineer could be competent and evil. Or competent and under duress - needing to keep their job to keep their visa, family health insurance, etc. Or competent but misled - "Implement the suggested fix to show how easy it is to work around" "OK, here it is" "Now work on something else", while it ships. 2) Why should you? Unless you're willing to be homeless and leave society, you're not going to find a way to live in a capitalist society which is pure idealism and no compromises, and you can't effect change in a system from without, only from within. Quit, and someone else will implement this fix - you feel good, which is worthless, and the fix ships, which is bad, and Cisco doesn't change, which is bad. Pick your battles and you could use this result in future - to build other people's trust in your recommendations, to widen the review process before future fixes are agreed upon, to have a proven record of the cost of doing things twice.
- adrianN 8y agoIf there were actual accountability, software engineers would have a much better lever against management. For some software this is case. If you write safety critical software you can be held personally responsible for accidents. In those industries engineer pushback is much more effective.
- philpem 8y agoMy background is safety-critical and -- speaking from first-hand experience -- it was truly incredible how much push-back we'd get when raising safety issues. System tick timer rolled over after 2^32 1ms clock ticks (a little over seven weeks) and the software mishandled it by rebooting and losing control of the process. It wasn't until QA got involved (it turned out they saw it on a long-term test) that we were cleared to actually fix it. It was a two-character change in an inline function! In some places "cover it up, don't discuss it in email" is the natural response. It really depends on the management and the organisational culture. You can have management who support the engineering team, or you can have management who micromanage and overrule and end up turning a two-day hotfix cycle into ten months of "try soldering a resistor to every single pin on the PCB".
- madengr 8y agoHa ha, a resistor on every pin is a signal integrity hack.
- lr4444lr 8y agoI like your spirit, but there's another conclusion we can draw: very few of us outside of a few special areas in embedded are "engineers". We tinker with bits and bytes to make business systems. Sometimes we bump up against some general engineering fundamentals. But we're just technicians meeting business goals.
- kortilla 8y agoYep, and the same can be said for “real engineers”. Most EEs, civil engineers, etc work on boring stuff as well with negligible risk of doing any harm.
- voidifremoved 8y agoAt a large organisation I worked at years ago we used to call it Coder Shopping - when a manager would do the rounds trying to find someone who would say "yes" in a situation like this. Invariably there would be someone who would, and if you were the person who had initially refused you probably wouldn't even be aware that it had happened until the bug reports came in...