The Reality of Working in Tech: We're Not Hired to Write Code

"So, is everyone losing their minds yet?" My ex-coworker asked me over yahoo messenger. He quit after getting enraged by new work policies that specifically targeted him. I looked up from my screen, and saw that the team of developers who used to work alongside my ex-coworker were now silently working on their respective machines in the row next to me. His old monitor had been taken away. His tower was sitting on the now open office desk, collecting its first coat of dust.

"Yes. It's complete chaos." I replied. Well, I lied. It wasn't chaos. They weren't happy either. The reality was that his old team was indifferent. They missed him of course, he was a great guy. I missed him, he was a true friend in this chaotic world of technology. But the fact that he was the only .Net developer in the entire company went unnoticed.

By himself, he maintained multiple money making websites. They all ran on a brittle .Net infrastructure. He knew all there was to know about them, and would respond in seconds whenever they experienced an issue. There was no realistic way to replace my ex-coworker, the .Net developer, and there were no plans in place to address this issue. He was hired to write code, so the best way to get back at a company who didn't value him, was to stop writing code. So he quit.

"lol the website is down," he wrote to me the next day. I checked and he was right, the website was down. I looked in the next row and it was complete silence. A whole hour passed and I was getting nervous. Not a single person in his old team was talking about it. I sent a message to one of them. "Hey I think your website is down."

"Oh, you are right." She answered. "I'll investigate."

After lunch, The QA guy in Mexico sent me a message on AIM, asking if I knew the credentials to the server. I shared the credentials. Then he said "Is SSH disabled on this server? It just times out."

"It's a windows server," I answered. "You have to use RDP to connect."

"Oh boy! I never used a Windows server before."

I helped him access the server and went on my way. Before the day was over, the website was back up. He was later promoted and became the new .Net guy. The QA guy in Mexico resolved the issue by simply restarting the machine.

My old friend, once a crucial part of the organization, was no longer needed. They built a new UI written in PHP and plugged the same database. Not only was he replaced, but now his position had been phased out. .Net was no longer a thing in the company. The promoted employee in Mexico was soon let go.

---

I thought I had been hired for my ability to write code as well. I posed as the JavaScript guru. Everyone consulted with me before deploying any code. In 2011, you needed an expert to guarantee your code would run on the plethora of broken browsers. We wouldn't dream of the tools available today. I was that expert. Yet when I left, my team moved on.

Despite my skills as a JavaScript developer, my position had been gradually diluted into a larger team of developers who were capable of handling the job just fine.

I was once proud of my self-developed methods for testing my scripts across various browsers and effectively implementing feature detection. However, the company eventually switched to using jQuery instead of my custom-built methods. Similarly, my custom tools were replaced with a third-party vendor's offering. While I was previously the go-to person for building new features, I was unable to contribute to the implementation of Angular due to my lack of experience with it.

I was proudest of an A/B testing suite I built for the company. It rivaled Google's Web Optimizer, and it was customizable. It ran both on the server side and the client side. It was the result of years of internal feedback and fine tuning. I even made a fun little logo for it. One day, a new manager came in and said we should use VWO as an alternative to Google's. And that was it. My work was tossed away without a second thought.

If they hired me to write code. If my old friend was hired to maintain what was exotic code, then why was it so easy to discard it?

I later realized that in the fast-paced tech industry, companies prioritize delivering products and features above all else. Managers are responsible for delivering results to higher-ups. As such, it is crucial for developers to work on building and maintaining the company's products and features, regardless of their coding specializations.

My experiences as a consultant further highlighted the importance of delivering visual results to clients and stakeholders. I often spent night and day fixing bugs and performance issues only for the company to ask me if I did any work. But when I produced "A Subscription Model" or "An Architecture" or "A build system" these were highly praised. Even though they came in as a PowerPoint instead of working code. They would hand it over to a team to write the code later, if ever.

Does it mean that we shouldn't write code or shouldn't try to get better at it? Not at all. When working in a team, what matters most is that the weakest developer be at the very least competent. The rest is to try to build and maintain the company's product and features.

Not as fun or inspiring as we make the programming world to be. But the reality is we are not hired to write code. That's only incidental.

---