Поиск  
Always will be ready notify the world about expectations as easy as possible: job change page
Oct 24, 2023

Why we are stuck with so many incompetent programmers

Автор:
Источник:
Просмотров:
2527

Passion is both the reason and the reward

Dont waste your talent

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.

Похожее
Nov 1
Indeed, when an individual decides to build a career in the Software Development field, there is one thing that always comes to his mind – How the career will progress, and what will be future opportunities? However, there are various...
Oct 3
Author: IT Illuminated
In the world of modern software development, the ability to perform multiple tasks simultaneously is important for building responsive and efficient applications. Have you ever wondered how your favorite apps handle multiple operations at once without slowing down? Or how...
Mar 29
Author: Josh Fruhlinger
Generative AI has seized the popular imagination and started a new tech gold rush. While much attention has been focused on AI tools that produce natural language prose and visual art, in tech circles AI is gaining increased interest for...
Jan 12
Author: Serokell Serokell
As we step into 2024, the landscape of software development continues to evolve exponentially, driven by technological innovations and changing market needs. For businesses and developers alike, staying abreast of these trends is not just beneficial-it’s essential for remaining competitive...
Написать сообщение
Тип
Почта
Имя
*Сообщение
RSS
Если вам понравился этот сайт и вы хотите меня поддержать, вы можете
Выгорание эволюционирует. Что такое «тихий уход» — новый тренд среди офисных сотрудников
Soft skills: 18 самых важных навыков, которыми должен владеть каждый работник
Что должен уметь Frontend разработчик в 2023 году (+Roadmap)
Чем CRM отличается от ERP
Функции и хранимые процедуры в PostgreSQL: зачем нужны и как применять в реальных примерах
Микросервисы: как определить, подойдут ли они вашему проекту
Как лучше проводить one-to-one со своими сотрудниками: 5 лайфхаков из личного опыта
10 не самых очевидных причин, чтобы уволиться
9 главных трендов в разработке фронтенда в 2024 году
Разработка игр на Unity: с нуля до профессионала
LinkedIn: Sergey Drozdov
Boosty
Donate to support the project
GitHub account
GitHub profile