Passion is both the reason and the reward
I entered the software industry about 2 decades ago. I was an engineering graduate, but I didn’t have a computer degree.
It was OK, not only because I knew the basics of software making (I was an Electronics engineer), but also because my country was witnessing an unprecedented boom in software outsourcing from the developed Western world.
Knowing to code wasn’t a requirement then. SAT-like analytical skills (multiple choice questions) + basic English (interview) were enough to get one into the IT servicing industry.
I did well on the test. I also managed to pass the interview despite English neither being my native language nor my major language of instruction.
I became part of the then-big-ticket software industry. The annual salary was $4500 (yes, it’s annual, calculated on the exchange rate of the year 2000). But it was more than a graduate could expect, especially in a country ridden by abundant unemployment.
I had no idea how much value I was generating for:
- My employer — who took outsourced software work from offshore (mostly American) clients.
- My client — who entrusted my faceless profile with his code worth billions in business.
More importantly, I had no idea how those two things were distinct, and often, diagonally opposite.
The Insignificant Work:
My first project consisted of a tech hotchpotch:
- Crystal reports and Meeting Matrix templates that produced live reports/diagrams in response to SQL queries fired by the desktop client. The only time it required a programmer was when a new field was added as part of an upstream feature enhancement when we had to meddle with the SQL queries.
- Business/UI layer written in a proprietary interpreted scripting language. This was akin to a ViewModel in today’s architecture. By design, most of the work we did belonged in this layer, because the client wanted his non-tech staff to add/change screens at will.
- Core: Written in Microsoft Visual C++ (replete with COM interface callouts to remote objects) that consisted of the script interpreter (mentioned just above) + some more business logic.
I quickly identified that the last part was the meat of the project, yet I barely got my hands on it. Because I was not a computer engineer, I was tasked with the former two bullets, only to keep me far from the “critical” part of something that wasn’t broken.
As service company employees, we were entitled to ask for trainings to upskill ourselves under the (often valid) assumption that the IT industry was constantly under changes. A consulting instructor hurried us through C++, COM, and MFC in a 2-day crash course, followed by a small test wherein we were required to build a COM component and call it from the client process. When I scored the highest among my 20-strong team, I earned the right to work on the critical C++ module.
This was after my first 18 months in my first job, and I was among the only 2 programmers out of 20 who got to work on it.
The not-so-important programming skills:
When I shared my excitement to work in the C++ module among my peers, they questioned my enthusiasm:
How do you capitalize on your programming skills? Now that you are experienced, you should aim at leading the teams. That way you move up the salary ladder faster.
I retorted:
If those skills weren’t that important, why was I prevented from working on those modules beforehand?
A senior dev whom I respected advised me to monetize it better by switching the company.
This company won’t give you a better raise just because you work on cutting-edge stuff. Attend some interviews, and get your well-deserved hike.
I was puzzled. After all, if a skill is only to be gained to ace an interview and never to utilize, what was the use? I could join a better-paying company, but what will I deliver on my C++ knowledge promise? I felt that his heart was in the right place. Yet, I could do nothing about it.
As for money, I believed that the increased cognitive load that programmers embrace must have fair payors. If not where I worked, somewhere else.
But my naivete lacked the conviction to convince my peers.
I decided to pursue executing my skillset. I truly enjoyed working on the most complex software I knew, even though the changes I made were mere bug fixes or tiny enhancement requests.
In my free time, I started learning OOP (from scratch, only to reinforce my understanding after having applied it in COM) with Thinking in C++ by Bruce Eckel. I enjoyed running tiny code snippets on my office workstation past 9–5.
I read and re-read things like inheritance, polymorphism, VTable mechanism, and standard template library. I enjoyed holding group mock interviews around topics such as how runtime polymorphism and late binding worked, and why a derived class needs a virtual destructor.
Outside my awareness, the reading was solidifying my previously learned Java language skill as well, because of the OOP common base. It lead me to read Thinking in Java by the same author, and I thoroughly enjoyed it.
My colleagues were climbing the promotional ladder. Some of them nailed attractive hikes in other companies. They praised my enthusiasm with tongue-in-cheek sarcasm.
The Verbose Programmer:
A few months into my comfort zone, I was nudged by the IT resource managers.
There was a pressing requirement for Java devs in a different company location. When I say pressing, it means that the client manager was a big shot in our company, and could gather as much headcount as possible.
I was transferred with a meager relocation allowance.
Since I only claimed theoretical knowledge of Java, I was once again rushed through a 2-day instructor-led crash course in it. After that, I was deemed ready to deliver. The project involved a simple Java back-office utility performing some Oracle DB operations.
The task didn’t challenge me enough in my newly gained OOP theoretical knowledge. At the same time, being a senior dev, I was now laden with a side task involving mockup data insertion using batch/java program. There was no Google to help; everything had to be written from scratch + tested.
I ended up spending my Saturdays in the office because 10 hrs/weekday wasn’t enough to reach the deadline.
In a different team, I would have a junior dev do the boring tasks for me. But here, despite having a senior label, I was the junior-most. Since my lead always kept an eye on my work, I couldn’t muster the courage to explore out-of-the-box solutions.
It was at that time that I realized how important it was to climb the leadership ladder and have someone follow your orders.
• • •
One day, an assistant to my team lead (whom I later identified as a douchebag) asked me: Why do you spend so much time in the office?
“Even the lead stays as much as myself. Aren’t the deadlines obvious to you?”
“And they always will be, can’t you see that? This is a bloody service company, and the deadlines will always be there. That rarely means you have to work days and nights.”
“What do you mean by rarely?” I was really puzzled.
“I mean visibility.”
What’s that? My quizzical eyes made him look at me like I was coming from a tribal area.
“I mean if you have things going on for you. Like the project is turnkey, all eyes are on you, and the boss has a promotion letter already typed. I don’t see that here.”
“But I won’t be learning any technology if I don’t work.” Besides, how can an employee avoid tasks assigned to him?
“OK, let’s test how much you already know. Do you know Java?”
I nodded.
“OK, do you know Spring? Do you know JDBC? Do you know Struts?”
I replied yes to JDBC, but the rest 2 terms I had never heard of. When he looked at my puzzled face, he gave me a look full of disgust and suddenly looked away.
“Those are the hottest skills in the market. I thought you knew.”
Past that, he threw some more Java terms that were unknown to me, without any reference to their meanings. I felt extremely nervous. In my tech career (mostly unaided by Google so far) , learning was my only driving force.
It turned out, I was far out of the league. I wasn’t able to name even 5 technical terms. How would I even learn them?
After that, he never spoke to me again. Only then I was able to observe that despite being my lead’s assistant, he was rarely in his seat for an hour. Most of his time was spent elsewhere. What was he doing? No one had any idea.
Then he vanished.
At the end of the project, I came to know that he got reassigned to a flagship project, and his promotion was assured. I was yet to witness a single commit made by him.
When I asked the lead about him, he said dismissively, “He was an empty drum. Such people rarely deliver anything.”
Moral of the story: In tech (especially in servicing industry), you often must know your CV bullets by heart, and nothing more.
Conclusion:
For the most part of my time in the servicing industry, I kept working with my head in the sand, in the standard waterfall SDLC.
Because I saw no alternatives.
Those who know how to build stuff have to make presentations and train others to prove their metal. If they succeeded, they get rewarded with a slightly above-average raise.
The work in itself is never enough, despite being self-evident. Any ambition to train and grow is met with cold shoulders: It’s about us, not you.
An improved programming skillset is rarely considered a door-opener for new business opportunities.
Passion is both the reason and reward for those who want to build. There are no extra rewards. I am yet to hear of a programmer who earned stocks based on his/her proven, differentiated performance.
Those who know how to piggyback on others’ work rarely even spoke to clients in concrete terms. Yet, they managed to have hearty laughs in managerial meetings.
And they clinched staggering raises and promotions.
One could say that the nature of the IT servicing industry weighs heavily on my experience. But that’s not true. Product organizations nowadays perfectly mirror the servicing culture — more on it on some other day.
The incentive structure in software is heavily skewed against the very people who build it.
That’s what drives talent away from work worth doing. A programmer’s average programming career span is ever-decreasing at an alarming rate. Worse, with AI, they are rendering themselves obsolete, at a much speedier rate.
They say that AI will completely obliterate programmers. But looking at the way how things stand today, that’s not going to happen.
The better ones have already left. We are seeing the fruits of the below-average lot. That’s why we are witnessing so many products being rewritten frequently, and product org prevailing upon development, even in the developer-centric Agile era.
The curtain isn’t going down anytime soon.