OPP: Other People's Problems
I&#x27;ve not heard of Camille Fournier until now, but glad I found her, and this article is quite timely for me.<p>I&#x27;m dealing with several issues right now in trying to &quot;take ownership&quot; of things that aren&#x27;t mine.<p>With our EDI system, I only get called in when the &quot;real&quot; owners are too busy, but when I do, I find their entire architecture is a foot gun that makes development way harder and more error prone than it should be.<p>With our (customer facing) admin system, the entire thing has a UX that I think easily triples the work&#x2F;time&#x2F;number of clicks to do anything, and just begs for many routine things that bog users down to be automated.<p>The problem I <i>do</i> own, the mobile apps, is greatly hampered by the back-end that drives all of the other problems that I don&#x27;t own, so all problems including mine could benefit greatly from working on <i>that</i> problem as well.<p>But when I talk to other engineers, they (a) don&#x27;t see the problems being as impactful as I do, (b) don&#x27;t believe that I can solve the problems in the first place, and (c) ultimately don&#x27;t want to put any time or effort into learning about the problems or my proposed solutions, even though putting in a little effort now could save us from regularly having to stay late and fix fire drills like we do now.<p>I&#x27;ve even gone to the length of building prototypes to demonstrate both (a) and (b), and in some cases they relent somewhat on (a), but continue to talk as though solutions aren&#x27;t possible... even as they&#x27;re looking at a live, running prototype.<p>I&#x27;m at a point where I either need to let it all go and just &quot;do my job&quot; (even though I feel the quality of work I can do on my own stuff is being limited by OPP), OR mobilize the internal end users by showing them my prototypes and getting them on my side (to pressure the engineers) which somehow feels a bit sleazy, OR quit and find another job.