I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
Re:How to Build Toxic Software Teams
by nineplay on Wednesday July 26, 2023 @04:35PM
(#36884585)
I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.
[ Parent
| on HN ]
Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more.