3 ms·

As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Un

As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Uncle Bob and I can heap on them.

Silhouette 9y ago
That's fine if you're in a regulated profession like engineering or medicine or law, where management need appropriate professional sign-offs before going ahead, and it's a matter of professional ethics. Unfortunately, in a field like software that isn't regulated (and IMHO isn't ready to be), you can say "no" up to a point, but if you continue to do that once management has determined that the answer should be "yes", you may simply get yourself fired and replaced by someone else who will give the desired answer. Unless it's a matter of moral judgement and you are willing to give up your job because you don't want to make what the boss wants you to make, software developers saying "no" rarely achieves much if management aren't listening.
- EdSharkey 9y ago
  Your rationale-fu is strong! Look, by whatever accident of history, programmers are currently in demand. If your shop is suicidal/trigger-happy on firing their valuable programmers, then just leave that place before that happens and find happier digs. Job #1 for any professional programmer should be to sleep well at night and not work overtime. Stop making excuses for sloppy, rushed programming. Use your power to enforce good practices. Ah, but you say, "all that is relative, no one agrees on what the practices should be." More rationalizing; no more weak excuses! Every team can write unambiguous house rules that form the social contract over what definitions and expectations are regarding ready-ness, quality, done-ness, etc. Until the whole rest of the enterprise is behind you and aligned with you, all that matters is your team. A right attitude is key. You, the programmer: do the simplest thing possible and use the scientific method when writing code through rigorous testing. Meaningful, working tests are proof. After your team learns to hustle, then you have power to hold your product owner's feet to the fire! Question every bit of the requirements they set. Your designs should sell the work, embody those requirements, and draw out all the questions you have to the business - when you do a great job, they will ask and then answer all your questions and more for you. Sloppy, imprecise, crooked requirements must burn and be tested in the crucible of your design. You have the power to talk and argue and you have the power to say 'no'. Reject any slow or unproductive tools, libraries, practices. Put tremendous, outsized, decadent effort into automating the hell out of everything mundane or annoying in your sphere. Always protect your brand/product/team: all vanity or pet tools/patterns/languages/CQRS-ES must eventually be jettisoned out the airlock whenever team productivity is being impacted.
  - fogetti 9y ago
    Such big words. In other words: non-sense. I worked in 6 different companies in 4 different countries across 3 different continents during my 10 years in IT. And no-one gives a shit about delivering bug-free code or good practices. There is such a thing called peer-pressure, probably you have never heard about it, it works like this: while you are fiddling with your scientific method to test everything properly, the guy sitting right next to you will get the same feature done when by going home and putting in a lot of overtime to make it look like he was working extremely fast and he pulled it off in matter of days and much faster than you. He will also give a shiny presentation and show off his working demo application while you are still writing tests in your scientific method. So after a few days your manager comes over to your desk and asks the guy sitting next to you if he could do the same thing, but now in a much more important project, where the deadline is super important. "Of course" - he replies, and he gets into a very interesting project and gets appraisals both verbally and also on his linked-in profile. He also gets a salary raise, since he is such a reliable guy who outperforms everyone. While you are still writing tests and wondering why nobody cares about your scientific method. I hope it's clearer now.
    - pdimitar 9y ago
      Everything you described can be summarized pretty briefly: toxic work atmosphere. Look, I get it -- I was working in such organizations in the past. There are quite a few of lazy bums in there but they specialized in a few important aspects: (1) take credit for somebody else's work, (2) always have a pre-baked excuse or shifting the responsibility to somebody else if something in their job is not okay, and (3) have more years in there than you. There's a lot of internal politics and intrigue in these places. If you try to beat this system, eventually you'll become a part of the problem -- you'll spend most of your time making sure nobody takes credit for your work, that you're blame-free etc. There is no point. What you described does exist out there, yes. But I can bet my balls that the programmers I work with are times better than the parasites you describe. Plus, don't forget burnout. That guy you described can only maintain that rhythm for no more than 2 years, 3-4 if he's a real masochist. But it eventually comes to an end. The solutions these toxic places opt for are always short-term (clarification: that works pretty well for many of them by the way; they are perfectly aware of what are they doing and they just replace the burned out yongsters with fresh youngsters, and the cycle resets).

As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Uncle Bob and I can heap on them.

Silhouette 9y ago

That's fine if you're in a regulated profession like engineering or medicine or law, where management need appropriate professional sign-offs before going ahead, and it's a matter of professional ethics. Unfortunately, in a field like software that isn't regulated (and IMHO isn't ready to be), you can say "no" up to a point, but if you continue to do that once management has determined that the answer should be "yes", you may simply get yourself fired and replaced by someone else who will give the desired answer. Unless it's a matter of moral judgement and you are willing to give up your job because you don't want to make what the boss wants you to make, software developers saying "no" rarely achieves much if management aren't listening.

EdSharkey 9y ago
Your rationale-fu is strong! Look, by whatever accident of history, programmers are currently in demand. If your shop is suicidal/trigger-happy on firing their valuable programmers, then just leave that place before that happens and find happier digs. Job #1 for any professional programmer should be to sleep well at night and not work overtime. Stop making excuses for sloppy, rushed programming. Use your power to enforce good practices. Ah, but you say, "all that is relative, no one agrees on what the practices should be." More rationalizing; no more weak excuses! Every team can write unambiguous house rules that form the social contract over what definitions and expectations are regarding ready-ness, quality, done-ness, etc. Until the whole rest of the enterprise is behind you and aligned with you, all that matters is your team. A right attitude is key. You, the programmer: do the simplest thing possible and use the scientific method when writing code through rigorous testing. Meaningful, working tests are proof. After your team learns to hustle, then you have power to hold your product owner's feet to the fire! Question every bit of the requirements they set. Your designs should sell the work, embody those requirements, and draw out all the questions you have to the business - when you do a great job, they will ask and then answer all your questions and more for you. Sloppy, imprecise, crooked requirements must burn and be tested in the crucible of your design. You have the power to talk and argue and you have the power to say 'no'. Reject any slow or unproductive tools, libraries, practices. Put tremendous, outsized, decadent effort into automating the hell out of everything mundane or annoying in your sphere. Always protect your brand/product/team: all vanity or pet tools/patterns/languages/CQRS-ES must eventually be jettisoned out the airlock whenever team productivity is being impacted.
- fogetti 9y ago
  Such big words. In other words: non-sense. I worked in 6 different companies in 4 different countries across 3 different continents during my 10 years in IT. And no-one gives a shit about delivering bug-free code or good practices. There is such a thing called peer-pressure, probably you have never heard about it, it works like this: while you are fiddling with your scientific method to test everything properly, the guy sitting right next to you will get the same feature done when by going home and putting in a lot of overtime to make it look like he was working extremely fast and he pulled it off in matter of days and much faster than you. He will also give a shiny presentation and show off his working demo application while you are still writing tests in your scientific method. So after a few days your manager comes over to your desk and asks the guy sitting next to you if he could do the same thing, but now in a much more important project, where the deadline is super important. "Of course" - he replies, and he gets into a very interesting project and gets appraisals both verbally and also on his linked-in profile. He also gets a salary raise, since he is such a reliable guy who outperforms everyone. While you are still writing tests and wondering why nobody cares about your scientific method. I hope it's clearer now.
  - pdimitar 9y ago
    Everything you described can be summarized pretty briefly: toxic work atmosphere. Look, I get it -- I was working in such organizations in the past. There are quite a few of lazy bums in there but they specialized in a few important aspects: (1) take credit for somebody else's work, (2) always have a pre-baked excuse or shifting the responsibility to somebody else if something in their job is not okay, and (3) have more years in there than you. There's a lot of internal politics and intrigue in these places. If you try to beat this system, eventually you'll become a part of the problem -- you'll spend most of your time making sure nobody takes credit for your work, that you're blame-free etc. There is no point. What you described does exist out there, yes. But I can bet my balls that the programmers I work with are times better than the parasites you describe. Plus, don't forget burnout. That guy you described can only maintain that rhythm for no more than 2 years, 3-4 if he's a real masochist. But it eventually comes to an end. The solutions these toxic places opt for are always short-term (clarification: that works pretty well for many of them by the way; they are perfectly aware of what are they doing and they just replace the burned out yongsters with fresh youngsters, and the cycle resets).