If You Feel Like Quitting Programming, Here is the Reason

The transfer of power nobody talks about

The Early Days:

When I entered the software industry, I was a lowly coder who was utterly unproductive. I spent 12 hours/day in the office delivering nothing.

Was I loitering in AOL/Yahoo chatrooms? Was I moonlighting for other companies/clients? Did I chat with colleagues from 9–6?

I wasn’t pretty excited about those options.

When the deadlines loomed, I (often, with some other devs) was singled out in team meetings. No insults were hurled. The team lead would condescendingly assign me an assistant (mostly the group lead), who would hold my hand until I delivered by the deadline.

The reason? Status quo

That group lead would steal a share of my annual appraisal rating, despite not having written 1% LOC.

When the delivery was over, I would beat myself to the question: What happened? The reality dawned: The feature release was slated in 2 weeks. I got a hold of my dependencies only 2 days before the deadline.

I didn’t have the guts to highlight it at the next feature assignment. The reason? Status quo: Only a group lead could plan the workflow, which went like this:

• Day 0: Feature/bug assignment to developer
• Day 1-N: The Developer clarifies the requirements with the group lead, who will become a channel between the client and the developer. No discussion about mocking the missing parts, because nobody, including the team lead, knew such a thing existed in software development.
• Day 1-N: If a developer, by intuition, figures out a mocking strategy, the mutating specs would invalidate it, and the client would be blamed (internally) for an abrupt requirement change.
• Deadline Day minus 2: All the dependencies are finally answered, and coding begins
• Deadline: Delivery, or a lapse

The group lead had designed the development workflow in such a way that the needle never moved without his presence.

This level of spoon-feeding + dependency hell was despicable. I hated myself for needing it. But I couldn’t change this workflow. I didn’t know it was my job to even think about changing it.

It existed because the business was structured around trivialities. My group lead, who took requirements from the client needed a padding to justify his 10 hrs/day billing. And because he was a responsible senior, the task had to look worth his salt, above all of us — his minions.

To make it work, he cunningly managed to weave an intricate dependency web and become the sole middleman agency for the most valuable deliverable — the code.

• Source control password? Make a request to him. He will obtain it for you in one or two days.
• Dev Database unique access (instead of a shared one that would max out frequently)? Inform him as soon as possible. He will consult the access manager (again, a seat-warming billing apparatus), decide on the necessity level, and assign it.
• Client-side bug tracking access? Wow, you gotta be visible to clients. Don’t forget: I granted the access!
• If a developer spots a mistake in the specs, she won’t be able to update it directly. She has to inform the group lead, and in private, to maintain his excellent stature in front of the team lead.
• Code? It’s all yours, kiddies! Did you make a mistake? Own it! That’s a leadership quality, and you are getting paid to earn your MBA, cheers!

It was a service company with technology being the farthest from the center of organization KRAs. If someone was technically proficient, it didn’t mean he would sit with a developer to troubleshoot or write a simple algorithm in a day. It only meant he/she was able to conduct PowerPoint seminars with red and blue boxes that held technical jargon. If someone asks about a programming/configuration problem, he/she would dodge the question, often belittling the asker (This session isn’t meant for low-level stuff!)

When I got assigned to a customer site in the USA, I got to meet my consulting counterparts from a competitor. At that time, I got to know how much resourceful and upfront a developer should be, and how much he can grow with that resourcefulness.

At the client site, if we ever received incomplete requirements, we could rebuff clients, and they would walk away with smiles, only to come back with V2. If we didn’t understand business, they would sit with us for hours, often trying to understand the programming structures we would employ.

None of it was competitive/acrimonious — it was plain curiosity, knowledge sharing, and above all, spotting competent and dedicated people.

It was then that I felt like quitting my job.

But it was difficult. As a lowly contractor in a client-driven service company, I had no control over my everyday affairs. And beyond a point, due to ridiculous American immigration laws, the client held no control over my destiny.

My service company boss did.

To the world, I was a programmer. But inside, I felt programming was a name given to a function only NASA scientists performed. Also, developers who created MS Office. Or Windows. Or Yahoo and AOL messengers. And yes, Hotmail.

I wanted to join their company. But I could see no clear path. Getting a degree seemed too daunting (I had no CS to begin with). It was costly. It also required rigorous preparation beyond 9-to-7 — my usual routine thanks to my service company’s unscrupulous bookkeeping.

During my long walks along my client’s lush green Illinois office, I kept reflecting on what I wanted to do with my career.

It was never the money. Yes, money was a driver, but only to the extent of preventing someone from taking hold of your career. Having a well-paying job increases your leverage over your ungrateful boss. Looking upward, though, there wasn’t too much money on the table for programmers, unless you were a flamboyant startup founder.

But above everything, it was the fascination to see the result of my work on the screen that had drawn me to this line of work. Yes, it was programming.

I wanted to quit my job, but not the programming.

I despised myself for being in the servicing industry.

I decided to question the all-pomp-and-no-work middleman. I wanted to act like my competitor consultants who could code a feature in 2 hours, past several days of requirement alterations, brainstorming, mind mapping, and mentally deconstructing/reconstructing object/function trees.

I wanted to know programming by heart, to justify my position above and beyond those sleazy middlemen.

I had an option: I could wait for my turn to become a senior-level group lead — the very role I despised. I could choose to be a better one.

But without knowing the fuller extent of what forms a better programmer, I would only be fighting the justification battles. I had lost all that courage in the servicing environment.

After 7 useful years (that only taught me what I didn’t want to do) in the servicing industry, I decided to pursue the product path.

Product Path — Fast Forward To The Agile Time:

The first product company had its fair share of bad politics. It sucked, but the best part of the job still stood out: The code was high-quality, multi-layered, well-decoupled, and highly configurable with external tools.

The best part was that I got unlimited time on it. This allowed me to spot design patterns, create object relationships, and implement systems thinking for a scaleable design.

When I quit that company due to bad politics, my blood still held a lot of love for coding.

I became a full-time freelancer, followed by a series of roles in Nordic product companies. Initially, everything went well. Developers ruled.

But soon the river of money dried off. Companies got acquired or lost clients. Turned out, none of them had adopted cost-effective measures to stay relevant in the market.

None of them followed Agile.

As soon as I joined the great Agile-driven product company, I was overwhelmed with meetings: JIRA tickets, daily meetings, sprint planning, sprint retro, and PI (Program Increment) events.

It felt good. Agile manifesto proudly claimed developers called the shots. I felt important.

There were no middlemen, only developers vs product owners.

Yes, there were bad Agile orgs that offered devs nothing, and devs were responsible for everything.

Yet, the good Agile orgs armed their developers with sufficient material: Design inputs, carefully crafted specs, sprints planned with developers’ agreement — what more one could ask?

I was fortunate to be part of a good Agile org.

As developers, we got exciting stuff to work on. A widget here, a chart there. An expandable list in the child screen, a reversal of it because enough customers failed to click it.

Yet, something was amiss. The features that we were saddled with lacked any coherence. Often, we found ourselves helping analysts correct things, which added to our toils because analysts couldn’t reciprocate any help via coding.

Yes, we could ask for more time, but it had its limits. If the web platform team delivered it in 3 months (because they could find an open source component), mobile platform teams (both native, hence separate) were compelled to match that timeline, or the entire time-to-market metrics would suffer.

The analytics module, an orphan piece of code whose developers had left long since had huge gaps. The result? Every team delivered exciting stuff every quarter, but business analysts couldn’t measure it.

Nobody wanted to fix it. Because analytics was a non-functional requirement, and nobody owned it.

The role segregation of product vs implementation was set in stone. The product suffered from this rigidity, despite programmers being capable.

Product owners were too creative to spot such simple bottlenecks. They kept coming up with feature ideas our competitors stole and were somehow making a huge buck. They rarely thought that user acquisition and engagement — the basic tenets of any product success in today’s era — often held zero monetary rewards due to low conversion coupled with core business.

To truly know why a feature worked/failed to work required in-depth + honest user surveys — something no company could measure with any metric whatsoever. Reviews only scratched the surface.

In their naive minds, POs thought developers were the masters of the Agile universe and were sufficiently armed to do their job. If a developer thought that a feature was complex, he/she could earn an expanded deadline. A developer can always control how he/she would deliver X. But he could not say that it would be imperative to deliver Y and Z instead of X, considering that A, B, and C had been delivered in the past. The role segregation of product vs implementation was set in stone. The product suffered from this rigidity, despite programmers being capable.

As a result, despite intensely robust business layer modules and a wide range of original UI components, the product failed to create an awesome impact on customers.

As developers, we often dreamt about our novel components being featured in some popular dev blogs — but we rarely got time to commit to that sort of community work. Even if we did, tech evangelism was absent, and leadership was least concerned about it.

The only figures we kept hearing every quarter were the number of users acquired, and the number of user-hours spent on our web/mobile platforms.

Good developers kept quitting for lower-pay jobs while POs kept making huge compensation.

Conclusion:

Agile has taken the power from the middleman, and handed it to the product org, bypassing the developers.

Having validated myself as a programmer despite having no CS background, I feel I want to quit programming before I retire financially.

I am not afraid of GenAI because it could get me fired.

In a good organization like mine, the leaders will not fire developers because of some copilot product.

I feel powerless.

Agile has taken the power from the middleman/team lead, and handed it to the product org, bypassing the developers.

I feel threatened by the cave of triviality developers have found themselves in — already before GenAI. Bad Agile orgs have crumpled developers with the managerial fist. In good Agile orgs, developers have turned into switches that product owners keep flipping.

With GenAI, this cave will always grow deeper, pushing the most creative devs to the farthest end of the darkness.

I worry for them, for they are too frail (and most likely, older too) to start their side projects and make a statement about their tech/product prowess. Nobody would fund them because they, in theory, can’t compete with / be acquired by tech behemoths — the same behemoths that are driven by certified product owners, who keep playing with investor money and coders’ talents.

I just pray that they don’t get fired. Because when it’s a human vs machine battle, chances of hiring a 50-year-old coder are rarer than fixing having an honest, service-company middleman.

That’s a situation I see myself soon. And that’s why I want to quit programming.

Before it quits on me.

Want to write for Medium, and read every story on it?

Want to get an email every time Pen Magnet publishes? Click here to join his subscriber list.

Pen Magnet is the author of the popular senior developer interview eBook:

Comprehensive Approach to Senior Developer Interview (40+ example questions)