{"id":36212,"date":"2017-06-29T11:26:01","date_gmt":"2017-06-29T11:26:01","guid":{"rendered":"http:\/\/www.flubu.com\/blog\/?p=36212"},"modified":"2017-06-29T11:26:01","modified_gmt":"2017-06-29T11:26:01","slug":"empathy-for-the-coder","status":"publish","type":"post","link":"https:\/\/www.flubu.com\/blog\/2017\/06\/29\/empathy-for-the-coder\/","title":{"rendered":"Empathy for the coder"},"content":{"rendered":"

\"\"<\/a><\/p>\n

You read through the code. You read it again to make sure you understand what it\u2019s doing. Your left eye starts twitching. You read the code a third time.<\/p>\n

\u201cWTF was wrong with the person who wrote this?\u201d<\/p><\/blockquote>\n

I hate how often I react this way. It\u2019s a quick default that\u2019s hard to reset\u200a\u2014\u200aimmediate annoyance as if the developer or engineer responsible for writing whatever I\u2019ve come across was scattering landmines. It\u2019s easy to shit on the people who came before you. They\u2019re usually not around to defend themselves or provide context. It\u2019s much harder to calm down, and think things through. An initial reaction of \u201cWTF?!\u201d is entirely valid (You\u2019re gonna feel what you\u2019re gonna feel.), but getting stuck on the frustration and not going further is unfair to your predecessors and causes you to miss out on learning.<\/p>\n

\u201cHow\u201d a problem was solved\/band-aided\/kicked-down-the-road is usually the root of those frustrations, but the next step is thinking through the \u201cWhy\u201d of the solution, which is often the source of useful information.<\/p>\n

The code might be stupid, but there\u2019s usually a reason. Maybe:<\/p>\n