Forgetting Why You Build

Pablo was a programmer. Or at least that's what he told people when they asked "What do you do for a living?" Most people would simply respond with "Oh cool!" or "My nephew wants to be a programmer!" But every once and a while he'd get a deeper response. "What does a programmer do?" Pablo would pause, thoughtfully consider the technicality of his question asker, then respond. "I tell computers how to solve problems by writing 'code', which is essentially a language that computers can understand." At last, his prodding questioner would accept his response and say "Oh cool!" or "My nephew wants to do something like that!" But Pablo's response was dishonest. That's not what he does. That might be what he wished he did, or what he would expect a programmer to do, or what the programmers in a recent biography that he read, "Coders at work", did. But Pablo's day-to-day looked nothing like that.

His title was "Software engineer", even though he actually had a degree in Computer Science. He worked for a Big Company with a ton of different products, all of which were household names. His Mom would brag to all her friends about her son, Pablo, who worked at {Big Company}, subtly implying that their products were somehow the result of Pablo's "programming". Even Pablo himself would get lost in the fantasy from time to time. Introducing himself as "Pablo, a software engineer at {Big Company}". Fantasizing about the positive perceptions his newfound acquaintance must have of him. Why else would he feel the need to identify with his employer?

But deep down, Pablo couldn't help but feel that the whole thing was fake. That he didn't actually deserve the giant salary he was getting paid. That he didn't actually build anything. That he was just a cog in a rusty, old, molasses-filled machine, that somehow managed to print money like the federal reserve. But he didn't like to think about these things, so whenever such thoughts entered his mind, he'd reassure himself of his merit and value. His interview for {Big Company} was very difficult, he'd solved hundreds of leet code questions in preparation and read every chapter of "Cracking the coding interview". He'd spent countless evenings on side projects to pad his resume and fill his Github. He was a smart, hard-working guy, he told himself.

Pablo's first experience with programming was magical. It was in his high-school computer science class. Up until that point, he'd never given much thought as to how computers actually worked. How images were drawn to the screen, how messages were sent, or how files were saved. In the first class, the students were shown how to write javascript code that would print shapes to the screen. And the first shape Pablo drew was a red square. He recalls feeling a sense of wonder and empowerment when reflecting on that first red square. From just a few keystrokes, he was able to create something out of nothing. By the end of the week, he had his red square moving from left to right across the screen and teleporting back to its starting position when it reached the end. By the end of the semester, he'd built a full-blown 2d-game. The player controlled a spaceship equipped with rockets that could blow up enemy spaceships. There was a scoreboard, exploding animations, and even special extra-strength enemies that appeared at random intervals. He'd decided then and there that he was going to become a programmer.

Fast forward three years of high school, four years of college, and five years of working full-time. Pablo was starting to realize that he wasn't really a programmer or a "Software engineer". Especially if the definition of either of those terms is someone who "...instructs computers to solve problems by writing 'code'." Somewhere between that first red square and five years of working at {Big Company}, Pablo had completely lost sight of why he was writing code in the first place. Pablo no longer wrote code to solve problems or build things. He wrote code for the sake of writing code. He was obsessed with the process. The outcome was an unimportant side effect, one that he was too disconnected from to see. He'd heard tales from designers and customer support about the product he produced, and how it sometimes wasn't quite right or didn't do what they expected. But what did they know. The code was clean, and that's what mattered.

Reminiscing about his earlier self, before landing a job at {Big Company}, he didn't care about writing clean code. He didn't know about modularity, or readability, or unit tests. He'd never even heard of code reviews. All he cared about was building things. What a fool he was.

Now he doesn't build anything. Or if he did, he's too many layers removed to know what. Instead, he reads and writes code. He obsesses over technology trends and "best practices". He duels with his fellow engineers in the intellectual battleground known as the Code Review. Equipped with a myriad of programming principles he picked up from Uncle Bob and Martin Fowler, he throws out principles and nit-picks during code reviews as if they were Yugioh cards. "YAGNI!" he comments. "DRY!" he suggests. "I counter your default parameter suggestion with the Single Responsibility Principle!" he responds.

And when he's not debating code quality or attempting to predict future use cases in code reviews, Pablo can be found in meetings. He's an expert at going into extreme levels of technical detail, which goes over the heads of non-technical stakeholders, in order to appear smarter than he actually is. He relies on his non-technical stakeholders conflating the fact that he knows things that they don't, with him being intelligent. His answers to yes or no questions are the length of Shakespearean novellas, making the person who asked the question forget their original inquiry. "Pablo, can we add reset password functionality to the website this sprint?" "Well you see, the Kubernetes cluster was just upgraded...and then we discovered Python 2 can't handle Unicode strings properly...But the S3 bucket policy isn't secure...so we re-wrote the service in Go...serverless scales so much better than Kubernetes...cold start times were worse than we expected...Functions should be self-documenting...Have you tried turning it on and off again?"

Pablo is deep in the forest but he doesn't know it. He's rewarded for discussing the patterns on the bark, even though the company is in the business of selling lumber. But because the lumber business is booming, they can afford to reward Pablo to theorize about the patterns on the bark. He doesn't even notice that his theorizing has no effect on how much lumber they sell or the quality of that lumber. He lost sight of the forest around the same time he stopped caring about building things. And now all he sees are trees.

A weird thing happens in complex domains where there are lots of steps between your inputs and the final product. You forget the original purpose of the craft. You become incessantly focused on the process, while completely disregarding the outputs. Instead of being concerned with telling a good story, you obsess over punctuation, grammar, and structure. Instead of caring about the beauty of the picture you draw, you focus solely on the technique you used. You care more about writing clean code with high test coverage than making a product that's delightful to use. You forget why you build.