Bad advice. If you're thinking this way and you don't think people will listen is it really better to just shut up? How about starting small and implementing fixes or starting with small refactors in the direction of a better code base? I have absolute autonomy at my current employer so it's a different world, I mostly ask for forgiveness rather than permission, but to just shut up? Weak.
Stop talking
61–66 of 66 posts
Re: Stop talking
#62Bad advice. If you're thinking this way and you don't think people will listen is it really better to just shut up? How about starting small and implementing fixes or starting with small refactors in the direction of a better code base? I have absolute autonomy at my current employer so it's a different world, I mostly ask for forgiveness rather than permission, but to just shut up? Weak.
So exactly how do you just implement small fixes and get them through your hopefully peer reviewed pull requests? What if you cause a regression?
Usually the push back from making changes is larger structural changes you need to get buy in for - not minor bug fixes.
Does it take away from your assigned work?
I’m putting myself in the position of a journeyman “pull tickers from Jira board mid level developer”. Not my real position over the last decade of having a more strategic position. But I still know which way the wind is blowing and know when to shut up.
Re: Stop talking
#63In a technical environment the first step is probably to write your ideas down. Sleep on it, review, and then share with a few people you trust for candid feedback. From there you can share more widely, fine tune and adjust, or realize that you mis-assessed.
Re: Stop talking
#64In a technical environment the first step is probably to write your ideas down. Sleep on it, review, and then share with a few people you trust for candid feedback. From there you can share more widely, fine tune and adjust, or realize that you mis-assessed.
It’s called “pre-wiring” https://medium.com/@unwrittenbusinessguide/pre-wiring-the-ar... https://www.manager-tools.com/2007/11/how-to-prewire-a-meeti... https://candidcio.com/2008/05/09/the-value-of-the-pre-wire/
I think in the early stages, the intent is self-rescue: prevent yourself from going off half-cocked. I see it as a way to gather feedback from trusted peers who have knowledge of the problem area. If it proves out, then they can help you sell it, but my primary intent was to encourage a "measure twice, cut once" approach instead of running with an idea without adequate preparation. If you cannot find at least three things that might go wrong with your approach, you probably have not thought it through. The intermediate step between soliciting feedback and "pre-wiring" is a pre-mortem, where you actively solicit potential failure modes and stumbling blocks.
Re: Stop talking
#65If ever someone should take their own terrible advice, it’s the author of this sad post. Because one reason to shut up is if you what you are saying is BS.
There are times and places and reasons to hold your tongue, of course. None of which are covered by the author.
Re: Stop talking
#66Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills. If I'm not going to change something, I'd rather not talk or give opinions. Related: https://strangestloop.io/essays/things-that-arent-doing-the-...
You can’t know if you are going to change something. So, just talk and let there be a chance of being heard.