Learning, software services style

Today’s programmers in the software industry make me seriously concerned. What will be their career trajectory?

It is understood that software development is a highly technical subject. It requires specialised knowledge, and the half-life of this knowledge is shrinking by the year. Java 11 is quite different from Java 8, the gap is just four years. The Android SDK spec changes every year, and you cannot publish an app which uses a 3-year-old SDK. New major releases of Angular/Ionic are released more than once a year; some are breaking releases. In other words, knowledge comes with a short expiry date.

So, if constant learning is a foundation for a sustained career here, how do they learn? As some of you know, I’ve been in the enterprise software development industry for about 30 years, so I get to see how this world works, and it’s not a good feeling.

To try to understand my observations a bit better, I tried to categorise the learning attempts I see among developers.

1. Read a tutorial page. These pages are all over the Internet, and tell you how to install MySQL on your laptop or how to decode a base64 string in Javascript. They are just single pages, perhaps half a dozen Linux commands or ten lines of source. People just copy-paste commands or lines of code without thinking or understanding. If it works, hallelujah!
2. Watch a tutorial video. This is what I see people doing most often to learn how to use a piece of software, or how to configure something. Tutorial videos are a bit longer than a single-page text, but are not conceptual – they are trying to teach you to get up and running with something with the least possible time and effort. A beginner with Visual Studio Code or Postgres will watch a 20-minute video to get started.
3. Learn by doing. Senior engineers who have spent a couple of years with a tech stack have learned a lot this way. They have tried various workarounds, solved various problems, and have a body of experiential knowledge. They become “experienced” in using async/await or promises in Javascript, for instance, purely by pattern-mapping. They are in essence churning out code which is similar to code they’ve tried before, but without any conceptual understanding of concurrency in Javascript. Try talking to them about the Javascript event model.
4. Studying by reading. Here I mean something longer than 20 pages, something which includes conceptual explanations. I do not mean 20 separate pages on 20 websites – I mean one single document of 20+ pages, written by one author. Like a book.

And I have seen young officers around me using just methods 1 and 2, and more experienced developers using method 3. Almost no one can read a book any more. I’m surrounded by officers who have undergraduate degrees in some flavour of computer science or a Masters in Computer Applications (MCA). And they cannot read a book. (I am aware that I’m saying “cannot read”, not “do not read”.) Some confidently say in job interviews that they “do not read books” because they learn from videos, shrugging off the issue as unimportant.

Therefore, they remain technicians, not engineers, whatever be their paper degree. They are doers who do without any conceptual understanding. And in case you think this is an Indian phenomenon, I’m assured by my overseas friends that it most certainly is global.

The beauty of the software services industry worldwide is that they have grown to this huge size by employing technicians in such large numbers, delivering value to enterprise clients. But I worry about the young officers around me because I do not know what their career graphs will be after, say, age 35. Let’s look at their options as age advances.

After 10 years as a hands-on developer, a software engineer has three career choices. One: become a senior techie, dive deeper into architecture, performance optimisation, system reliability, etc. Two: become a manager of people, delivering projects on time. Or three: get into client account management and business development.

Most hands-on developers I see will not become good at managing people or getting new business: these things require hard work and a temperament very different from that of technician-developers. Most developers neither have good soft skills, tact and communication needed to be a manager of people, nor the outgoing, high-intensity, three-meetings-a-day profile of business development leads. The senior techie role is the only role left, and that requires conceptual clarity and reading of books. In theory, it’s possible to learn from detailed conceptual videos too, where good teachers explain concepts like books do. But I suspect that studying from such videos is as hard as studying from books. In fact, I feel that studying from a detailed conceptual video is harder than reading a book, but that’s a topic for another day.

Therefore I worry. I do not see any technical growth path for an engineer after 10-12 years of work experience, unless he or she studies by reading books. And no one can read books any more.