“As of this moment you’re no longer employed at [insert company name here].”

The five minute dead man walking down to the dungeonous lair of the Human Resources office had not prepared me for these words, uttered so plainly and unapologetically from my then manager of several years, despite the Employee Improvement Plan (EIP) I’d been on for the last three months. The “plan”, while couched in legalistic managerialese, was a death sentence that had been hanging over my head since the moment it had first been presented to me. Condensed, the two page memo translated as: “Thou shalt not make two mistakes in the next three months or thou shalt find thyself hitting the pavement.”

And hit the pavement I did. With full blown Lyme disease to boot. I wasn’t allowed to say goodbye to my coworkers, many of who I considered friends, or allowed to collect my belongings. I was literally escorted out of the building via suspiciously empty, rarely used hallways to the front entrance where my manager smiled, offered his hand, and said that with my highly sought after skills any employer would be, “lucky to have me.” Not being one to punch someone in the face—and being in absolute shock by the manner in which I was dumped by a company I had poured my heart and soul into—I accepted this grotesque gift then walked away in shock and silence.

Everything in me wanted to argue with the diagnosis. While an undergraduate in the University of Oregon’s Computer and Information Science program I had learned that every page of software code was likely to contain at least one bug regardless of the skill level of the engineer. I’d worked on the equivalent of a novelette in the last few months so despite being a perfectionist who quadruple checked everything and regularly sought review from peers I knew the chances of having introduced only two bugs was exponentially less likely than winning the lottery. I wanted to engage in a rational debate about the two “mistakes” I’d supposedly made, neither of them severe, and one being literally and demonstrably caused by another engineer, but I recognized the HR rep didn’t have the patience for any technical explanations and my manager didn’t care. I’d been fired long before I’d agreed to the EIP.

Ten plus years with that organization. I didn’t even get recognized with an award (usually a small desk clock) at the ten year mark, as everyone always did, at the last company wide meeting. I’d spent the last several years working fifty, sixty, and even seventy hour weeks, often online monitoring the build until two or three am, and rarely took a weekend off. Though I’d always worked long hours due to anxiety, insecurities, and my work-a-holic autistic nature, I’d more recently started to compensate for whatever unknown illness was slowly debilitating me. I was up all hours because my semi-technical manager did not seem to understand—nor did he demonstrate any desire to understand—two very fundamental things:

1. The company’s two products were built on hundreds of thousands (if not millions) of lines of monolithic legacy code that without a significant refactoring effort in the form of engineers, time, and money, would always take over seven hours to build unless we budgeted engineers, time, and money, or at the very least, invested tens of thousands of dollars on a more beefed up build server.
2. I could not, in any logical, rational, or remotely ethical way be held responsible for breaking the build which would ultimately result in there being no compiled product for QA to test the following day.

For those of you who aren’t in the field:

• Source code (or just “code”) is a human readable language humans use to program computers. There are thousands of different languages, examples including C#, Java, Perl, and Basic.
• Monolithic code refers to a significant amount of source code, often representing “separate” programs, that are so tightly linked that they can’t exist (or often be built) independently.
• Legacy code refers to source code that’s often old (in tech terms that can be as a few as a couple of years, but I usually use the term to refer to code a decade or older) and/or code that hasn’t been maintained, updated, or given much TLC (Tender Loving Care) in awhile.
• Refactoring code is the process by which a program is rewritten in part or completely in order to improve, modernize, simplify it, etc.
• To “build” or “compile” code refers to the process of converting source code from its human readable form to one a computer understands and can execute.
• A build server is a computer that’s responsible for compiling code.
• “Breaking the build” refers to the act of causing the build or compilation process to unexpectedly halt. Build breaks can be caused by any number of things, from the build machine crashing for some reason to a problematic Windows update on the build server causing incompatibilities in the code. Most breaks, however, are unintentionally caused by developers checking “breaking” code into Source Control.
• Oh yeah, and “Source Control” systems are software solutions that allow software engineers to collaborate on the same projects while maintaining a complete history of their work (think of Source Control as a library engineers check their code in and out of like books).
• QA = Quality Assurance, i.e. people whose primary purpose in life is to test software and make sure it all works the way it aught to.

Now that I’ve given you a taste of the vocational world I inhabit I’m going to get back to it.

Monolithic legacy code is often a necessary evil. It can constitute years of work by dozens or hundreds of people and millions of dollars in investments. One does not simply “refactor legacy code”; reinventing the wheel, something I’ve seen companies try and fail at many times over my career, is never cheap, trivial, or without risk. So companies have some very good reasons for keeping monolithic legacy code around but there’s a major down side when it comes to building and releasing software: legacy applications can take hours (or days) to build and when the build breaks, well, that’s a problem.

When I joined the company in question, their builds took weeks. There are a lot of reasons for it, but it comes down to manual, error prone processes due to differences in how siloed teams worked, which is all well and good until you want to modernize your builds. By standardizing and automating things I got the build down from two weeks to two days, then one day, then eventually twelve hours, and finally to six or seven, that is assuming nobody “broke the build.”

Now, no software engineer intends to break the build any more than a semi-truck driver means to jack knife his big rig causing a million dollar ten car pile up followed by a six hour traffic jam. It’s the same with software engineers. By “checking in” a piece of “breaking” code, software engineers can unintentionally cause a build to “break”—and for code that take hours (or worse, days) to compile successfully, build breaks result in a lot of people sitting around twiddling their thumbs. The impact is time, money, and sometimes stern looks from irritated colleagues. Nobody in my world wants to break the build, especially when doing so means there will be no updated product to test the following work day. No updated product means nothing to test and nothing to test means QA engineers will be sitting on their laurels all day and QA sitting on their laurels means developers won’t know if the changes they made the day before worked or not. It’s a no win scenario for everyone and an often unrewarding responsibility for most build engineers who are, as I have often been, frequently the target of misplaced agitation.

One day, during the three month window of my “Employee Improvement Plan”, a developer, I’ll call him Bob, checked in a piece of breaking code. That afternoon, just after 6pm, the build system, of which I created and maintained, automatically kicked off, checked out the latest code of a dozen or so developers who had been hard at work that day—including Bob—and started to compile the code—including Bob’s late great breaking code. I arrived home that afternoon and monitored that build visually and via e-mail (notifications would be sent in the case of failures) until one or two am, when I decided it might be a good idea to get some sleep. Not long after I hit the sack Bob’s breaking changes brought the built to a screeching halt and when everyone got in the next morning there was nothing to test. The broken code had to be fixed, tested, checked back into source control, and the build had to be started from scratch. It wouldn’t be until five or six pm (i.e. EOB or “End of Business” day) when the checked-in fix would result in the next day’s “good build”.

As alluded to above, I’d built e-mail notifications into the build system so on the rare occasion someone did check in a breaking change (it happens!) they’d receive a notification with instructions on how to get things moving along again. And I’d provided every engineer as much hands on training as they required to feel confident in the process. So why was I up watching the paint dry well after Bob was fast asleep?

Rewind two years. My health issues had come to significantly impact my life, in-so-much that after my typical work day I didn’t have the energy to do much beside turn on the tv and fall into bed. I was actively seeking medical care in-so-much that I was seeing my primary once a month, going to a pain management clinic, seeing a physical therapist, talking to a psychologist, and following the experts’ advice to the letter. And I was still fulfilling my responsibilities at work. And then some.

According to the ADA, or American with Disabilities Act, someone in my shoes has the legal right to request “reasonable accommodations” from an employer (I put quotes around it because that’s the literal text in the law). For example, this might mean a ramp for an employee in a wheel chair or a standing desk for someone with back problems. A “reasonable accommodation” is anything the employer can reasonably do (even if it costs a little $$$) to help someone with a disability fulfill their job responsibilities.

For me there were only a couple of things I needed. The first couple were the result of the advice of an occupational therapist, employed by said employer, who had reviewed my workstation and suggested minor changes: raise the desk, raise the monitors, provide a higher office chair. The cost was minimal so easily fell under the category of a reasonable accommodation and my employer made those adjustments without skipping a beat.

The other request?

Previously I had been coming into the office at or before 9am. I had never been a morning person, but my health issues were making both falling to sleep and getting enough sleep, and getting in by 9am, increasingly difficult. For those who haven’t gotten to enjoy chronic health issues: less sleep always means worse symptoms. So I had a note from my primary doctor instructing my employer that maintaining some semblance of health required that I come in a little later, leave a little earlier, and work part time from home. After a short discussion with HR and my previous manager this translated into me coming into the office at 10am, leaving around 4pm, then working a couple of hours in the evening from my home computer. Note: This was well before COVID caused employers, especially in the tech industry, to realize “work from home” could be a good thing, but I was getting my job done and my employer had no complaints so everything was copacetic.

New manager enters stage right. Decides my doctor doesn’t know what’s reasonable and changes my hours. Decides they’re going to stand at my desk in the morning and tap on their wrist watch if I’m even one minute late (yes, this literally happened a number of times) and ignored my health requirements regarding when I can (and often should) head home. Result? My sleep’s impacted therefore my health is impacted therefore my quality of work is impacted and so I eventually end up in the Emergency Room. Next day I’m back at work. Manager doesn’t say a thing. And so it went for two years.

For those of you saying, “Then get another job!”—please, please do try that. Get a mystery chronic illness then, when you have no friends or support systems, when you need a roof on your head, food on the table, and medical insurance, just go out there and just “get another job”. This, IMHO, is a uniquely arrogant and ignorant American attitude and is not one one encounters in most other first world countries where there are laws protecting people who find themselves in that boat.

Moving on…

Said manager didn’t care if I was staying up, often until 3 or 4am, to fix other people’s breaks. No thanks, no applause, no recognition. They didn’t care about the real reason something broke, only that “it” broke and I was the one that laid the asphalt the trucker jack knifed on while attempting to avoid an animal running across the interstate. Hell, they’d even ask me why I couldn’t make an improved highway that would prevent animals from running on to it then, if and when I put up a fence to keep the animals at bay, he’d pull me in his office for another “friendly” little talk. “Make it faster,” he’d demand, “but don’t change anything!” Damned if I did. Damned if I didn’t. Eight years of constant improvement stopped dead in its tracks by one out-of-touch micro-manager with delusions that the only successful worker was an extroverted worker. And did I mention the ER visits?

That last day he walked me out of the building like I was a common criminal before looking directly into my eyes, smiling, and shaking my hand as he fired me. Worst of all he lied, both to me and to the company. He impugned my work ethic, my abilities, my track record, and my integrity. I didn’t break the goddamn mother fucking build—and if I had, so what? It’s such a regular occurrence at software companies it might as well be in the kitchen next to the shitty free coffee makers (there’s even a saying in the industry, “Fail fast, fail often!”). It didn’t matter to him that I could literally pop open a computer and unambiguously demonstrate to him that Bob did it, when Bob did it (down to the second), and explain why Bob’s change was a breaking change. Didn’t matter to him. No how, no way. But Bob got to keep his job. I didn’t.

I’ve never experienced such a lack of professional respect, before or since.

Oh yeah, that other mistake?

One day I sent a request to the IT guy to swap a hard drive out from the build server and replace it with our newest, fastest, state of the art hard drive, but instead of asking him to replace drive ’s’ I accidentally typed ’t’ and hit send before quadruple checking my work. A few hours later I realized I’d requested the wrong drive and sent him a quick cease and desist e-mail after which I immediately marched down to his office to verbally ensure he wasn’t going to wipe the drive’s data. No harm, no foul. I’d made an honest mistake, did my due diligence, and got there in time. Even if he had reformatted that drive, I could have rebuilt the data on it by the end of the day. Hell, even if I hadn’t made the request and a meteor shot down from the proverbial heavens smashing our build servers to smithereens, I’d built redundancy into the system and would have had it up and chugging along by dinner time.

What did I cost the company in making that mistake?

Nothing.

Risk to the company?

Nothing.

What did it say about me, having designed and implemented a system with disaster recovery built in but still admitting to making a mistake that I could have theoretically swept under the carpet but instead immediately choose to accept responsibility for and ensure got rectified?

Everything!

Over the course of the following weeks I learned I wasn’t the only one working their proverbial tails off to reach unrealistic or ridiculous goals outlined in a three month Employee “Improvement” Program. I was the first to be escorted out of the building—the company had done their best to keep that hush-hush—but it was only a matter of time before many of my trusted colleagues and friends watched helplessly as a complete stranger tossed my belongings into a cardboard box. As other co-workers began to similarly pop out of existence the survivors experienced that shared, tribal “WTF?” moment all too many of us in the industry have had at one point or another which quickly translated into an “Oh shit! It’s a mass lay off!” light bulb moment followed by said company doing the bullshit corporate damage control dance of “No, no, everybody just take a deep, calming breath, we’re only letting ‘underperforming’ employees go,” which naturally resulted in the ubiquitous uncomfortable silence of, “Oh shit! If they’re considered underperformers then what about me?” This is corporate America’s version of, “Look busy, Jesus is Watching!” and, “The beatings will continue until moral improves.” And it works. Because people are scared. And sometimes I think that’s exactly how some companies want us to be.

So here are some follow ups to my tale which I’ve indicated, via previous posts, is at the core of a lot of my personal moments of PTSD:

Many others who were laid off had pre-existing medical conditions they’d been open with HR about.

I later learned that corporate had, around six months earlier, instructed managers to choose a designated number of people on their teams to can, fabricating, if necessary, reasons to do so in order to get out of any legal obligations they might have otherwise have had.

Because we were labeled as somehow incompetent it didn’t need to be reported to the media or, to my knowledge, the shareholders.

When I initially filed for unemployment the unemployment department initially denied it because on paper I’d been fired for “gross incompetence.” The following conversation with my unemployment agent went roughly like this: “Well, what a co-ink-ee-dink?!” I says, dumbfounded, “Seems like a lot of folk at that same place have been coming down with the gross incompetence too!” Said agent made a few calls, got back to me, and agreed: I received my hard earned checks from an unemployment system I’d been paying into for decades and though meager they kept a roof over my head until I the next big thing.

One final comment: having worked there for such a long stint my then colleagues were my professional references. Only after my dismissal did I discover that corporate policy prevented them from being professional references because the me they knew and (most) were all too eager to speak up for was not the me the “corporate overlords” had decided to chisel into my gravestone. So I again want to thank all of my previous colleagues who knew my worth, took a risk, and did the right thing. Thank you, folks, I love you!

Been a long time, but that’s finally off my chest. No integrity, that manager. In his shoes I would have found another way or I would have quit. Actually, I was put in that position by an employer who hired me on false pretenses once; fortunately, we found another way.

Thank you for listening and take care,

..asm…

P.S. There’s a reason that “no blame” shops have better moral, harder workers, and less turnover. More companies need to adopt that mentality.