Hoarders
Working with Robmunds' code is like visiting a hoarder's house. You walk in and see massive amounts of trash ALL OVER THE PLACE. You want to clean it up and make it better, knowing that it's a massive job, but you immediately see places that would be very easy to get started improving the living conditions, like that pile of old soda cans. So you walk over and start picking them up off the floor, but then Robmunds runs over, panicked, "Stop! Don't move those! I put them there!"
Rob doesn't know how to design software. I know that sounds harsh and may cause confusion since he's the "chief architect", but his insight into the workings of the code is primarily due to the fact that he's the one that made the piles—he's the hoarder! He genuinely knows where nearly everything is just as in the hoarder's house if you ask them "Where's the Sports Illustrated December issue from 1977?" they could tell you "It's in the pile in the corner about 6 inches from the top". But the fact that he knows where everything is within the piles of code does not mean that the codebase has a proper organizational structure. A valid unit of organization for code is not the pile.
And the fact that Robmunds can't see the problems IS the problem. It means that when you try to pick up the trash from the floor, they don't like it—they think it's a good design the way it is and insist that you put the trash back where they had it or, if pressed, insist that we can't take time to clean up or some other excuse.
Robmunds' ineptitude is pervasive and affects all aspects of their work and approach to work. For me, the most telling is how they respond to new ideas, such as design patterns (setting aside the fact that such basics of software engineering are not part of the toolbox of a "principle engineer" and the "chief architect"). They will occasionally sprinkle some of those "highfalutin" words into their speech, but you can hear in their voice their simultaneously giddy desire to use such emblematic jargon, along with their self-conciousness over feeling judged for using it (and perhaps fear of their lack of actual understanding being revealed). They claim that it's all just philosophical, academic ivory tower nonsense and unnecessary for "getting things done", but they're simply and totally wrong.
In school, my focus was on theoretical computer science which is basically just applied math. Complexity, computability—those were the things I was interested in; I was an ivory tower snob. When I first encountered the concept of Design Patterns I looked down my nose at them. "Patterns are just cookie-cutter recipes for those that can't think for themselves." It wasn't until I got my first engineering job that I learned the importance of having a toolbox of well-defined and understood concepts that could be applied and used to communicate with other engineers (I think the communication of design and intent with other engineers may be even more important than the application of such patterns).
Rather than detached philosophical, academic trivia, these concepts are quintessentially practical, with such immediate applicability so as to be fundamental to engineering, but I bring them up here not as shibboleth, but as litmus test for the real shibboleth—how does one respond to new knowledge? When I got my first engineering job and saw the level of competence, both in-person and in-code, I thought "These guys really know what they're doing. I need to step up my game and learn this."
When confronted with new knowledge does one embrace it (as I did), or reject it (as they do)? When they dismiss, and indeed actively avoid learning, such concepts they don't come off as "old fashioned" like they tell themselves they do. They're simply outing themselves as amateur hacks, just fucking around instead of engineering.
Tags: work