> My early mindset revolved around trying to fight processes and replace them with some kind of technical solution or automation. I now try to favor communicati

> My early mindset revolved around trying to fight processes and replace them with some kind of technical solution or automation. I now try to favor communication and investigation to reveal the underlying problem that the process was trying to solve. And sometimes, a broken process may still be better than a broken program. Because human communication is a complex issue that cannot always be fully encapsulated in a rational specification. This is key. As the old quote goes “Automating a mess means you get an automated mess”. I’ve seen too many managers use process, and too many developers use code, to avoid digging into a mess. A mess involves ugly human emotions and motivations; understanding why the mess is there is scary work. Ignoring that work and focusing on the "technical" leads to weird requirements that then leads to bad software. It's a real pain to maintain a prematurely automated solution to a social problem. It makes the mess worse.