How I learned thousands of ways to write bad code in just ten years

Maybe we should all go back to writing assembly?

Is it just me, or is there an overwhelming flood of articles with the same basic headline pattern:

How I {learned, mastered, etc.} {framework, library, command, fad technology, etc.} in just {number} {unit of time}

Ok, ok, ok. I totally get it! I mean, come on, here. I’m not blind! Of course I’m tired of the old, “X Ways to Improve Bla-bla-bla” and the trusty standby “Which {Harry Potter, Friends, Game of Thrones, etc.} character are you?” We definitely need a new trope to beat the life out of until we can’t hear it screaming for mercy anymore. That’s true. But does it have to be absurd right out of the gate? I mean, there’s definitely a race to the bottom on these. There’s no way, for example, that someone “mastered machine learning in ten minutes” or “hired five hundred employees in two weeks.” What’s next, “How I became a blockchain expert in ten seconds and had a baby that same day?”

Now, maybe I’m just jealous. FOMO infects us all from time to time. It’s entirely within the realm of possibility. But I’ve decided to pitch in with my own contribution, something I’m eminently qualified to discuss! Something I landed upon only a few moments ago!

My offering to the world: how I learned thousands of ways to write bad code in just ten years.

In the beginning…

I started just like anyone, with my CS degree in hand and a job doing some development for a mid-size corporation’s operations departments. I hacked on things like payroll systems, IT inventories, and intranets. I was the ultimate code-and-fix developer. There were no tests anywhere near my code. I google-copy-pasted practically everything and slopped up the biggest balls of mud around.

You want spaghetti code? I can do goto statements even in Java. That’s simple enough just by throwing a strategically placed exception.

Uh, what was I talking about again? Oh yes. On top of my own terrible code, I also absorbed a lot of others’ bad habits. There was the old “let’s use an interface to hold static constants” and the reliable “sort this collection by iterating through it and adding the items to a TreeSet, then read them back out again.” Hell, my manager at the time was just an exemplary role model for best practices since he had production SSH access and would edit, compile, and deploy code directly on the production servers if there was a problem. Of course this would be promptly forgotten until the next release when the original code, still in source control, would replace his fix and the bug would raise its demon head again.

In the middle…

At some point in there, probably after another 2am support escalation or a midnight deployment on the day a project was due, I was reduced to a babbling idiot lost in a miasma of fear and stress, and finally admitted: I hate my crappy code.

Me, once. What’s that? Ok, you got me…me, many times.

Yes, I suppose that the itch to write good code can catch up with even the best of us and I finally succumbed to its tantalizing pull. I soon quit to join a “real software company” and started voraciously reading books and watching videos. I debauched myself with Clean Code and Design Patterns, Code Complete and Programming Pearls. When I read Lean Software Development: An Agile Toolkit, I became a total addict to learning how to build great software that addressed customer needs.

Then I made the crucial mistake! I started talking to managers about it. What a dope! And, just as you might expect, like any management team at a dysfunctional software company should, they squashed my dreams of lean and continuous delivery like a bug, insisting that what we were already doing was agile. What, with quarterly releases of software and all.

Still in the middle . . .

Then the true nightmare began.

Customers were leaving. Employees were leaving. Most of the ones who stayed were arguing with me because they thought it was a waste of time to write automated tests. I was meeting with a new manager every other day to try and talk some sense into them and turn the company around. I brought studies and math (ah me, poor ignorant fool thinking that facts matter!) to support my ideas and each manager just kept getting bored and passing me off to another.

I even co-wrote a long paper for our management team about why we should release software more often than once per quarter. One of my former co-workers laughs at me still. It was written in a fancy MS Word template! It had a title page and endnotes! It had charts and references galore! Well, lucky for me, I look back and laugh at myself, too, a poor schmuck who thinks that good ideas just need a little logical rationale to float to the top. A goof who took seriously one manager’s urging that,

“if you believe in something, make the case for it.”

Still, still, still in the middle . . .

Things went a little better after that. I fled that sinking ship and joined another, a larger company this time. Waaay larger. Once I left, the previous company gradually went out of business through merger/acquisition and layoffs over the next few years. I smugly assumed I had left at just the right time. Meanwhile, I was pretty proud of myself being in this big company. They did domain-driven design and had their own hackathons and code retreats. I was naively happy, happy as a clam you might say, for some months on end. I was able to rewrite crucial code for my new company, using DDD principles, and it was a beautiful thing to be part of. And may I add, my new company released new code to production every week (can you believe it?)!

But, eventually, things went weird.

I was rotated onto a team right when multiple senior engineers were leaving. This team had only just recently implemented three or four services that processed important customer data, and they had done it fast! No, I mean faster than that. No…seriously. Faster than fast! The code was the definition of a mess! I’m sure most of it was churned out at 3am after the last vestiges of sanity had finally boiled away. This was so lucky for me! I quickly learned hundreds of new ways to create race conditions, hide cyclical dependencies in IoC containers, throw NullPointerExceptions from the farthest depths of the stack, screw up timestamps by relying on the system clock in clusters of machines with a mix of time zones, and more epic wonders!

Sometimes, untying knots is all that coding is.

For weeks I slogged through that code untangling knots. Then, right when I was finally getting the list of knots whittled down, the other shoe dropped. Someone somewhere high up the many-layered bureaucracy drank cloud Kool-Aid looong after “the cloud” hype had come and gone. Suddenly, since these services weren’t “in the cloud,” that was a big problem! We were tasked with making it happen “by Q2.” A bunch of us engineers pointed out that unless we wanted even bigger pain, we shouldn’t just put these services in the cloud “as is.” This kicked off a bunch of fighting between various diehard parties about what exactly we should do, from “move it as it is!” to “rewrite it all from scratch!”

This latter group might have been the most troubling. Once a whiff of “the cloud” had hit these engineers, they began running around with crazy eyes, yelling “reactive,” “serverless,” and “CQRS” like starving sailors. They had longed for, cried themselves to sleep over, and dreamt about the cloud.

How did I handle this? Well, remember that poor ignorant fool I mentioned who thought that facts matter? Yeah . . . I didn’t learn my lesson. I thought a compromise could be brokered. I was trying to talk some sense into these people, both engineers and managers, and get everyone on the same page. In my memory, I think of it as a similar experience to running my hand over a cheese grater over and over again, thinking that somehow this time it will be different.

But it wasn’t.

After the fit died down, the managers simply mandated “lift and shift” and I found another job.

The end? No! Still the middle…

So anyway. Here I am! The guy who has learned firsthand thousands of ways to do software wrong and will probably learn even more soon. Direct all your admiration toward me! I have lived a thousand lives! What is the biggest thing I’ve learned? Everyone is doing it wrong. Which I think will be the title of the book I’m writing about my experiences. I’m now a wisened old geezer in software years (and gee I’m not very old)–wisened enough to know not to think that things I am doing are the One True And Holy Right Way! Not only are all of you doing it wrong, but so am I.

And if you’d like to argue that, ok, please visit https://www.whitehouse.gov/contact and send in all your gripes. I’m sure someone important will read them and know just what to do.

Now, if you will, please visit all the fantastic short stories linked below that have more titles like “How I wrote the greatest traveling salesman algorithm five minutes after I started my CS degree” and “How I stood on my head juggling chainsaws on a unicycle while building the next billion dollar startup.” After all, we’re all in this together. A little escapist fantasy never hurt anyone.