How we read

We don’t read the way we used to. We read a lot, but not the way we used to.

I watch youngsters — including the young officers in my company — read their mobile phone screens. They are constantly reading. They are constantly writing too. Facebook, WhatsApp, SMS, and sometimes, emails. It all feels very nice — you say a silent hosanna to these wondrous new technologies. But this evaporates when you see them trying to solve a new problem or study a new software library or software system.

You then realise that they’ve forgotten how to study. In fact, I begin to wonder whether they’d ever learned it.

Watch them solve an unfamiliar problem. They see a new system error, and start searching on Google. Yes, that’s the first thing they do. When a programmer in my team encounters a permissions violation in his Linux file system for the first time, he does not ask “What can I read to learn about concepts, the authorisation model, the basic constructs?” He first Googles for

linux file permission denied

He then Googles for

linux file permissions

In each case, he never clicks beyond the first page of hits. And if he can’t find the precise solution to his problem after three search attempts, he comes back to us saying “It seems to be a strange problem. Can’t figure it out.” In other words, he feels he’s done more than can be expected from a talented and knowledgeable engineer to try to solve the problem — now the ball is squarely in his team lead’s court.

If he is lucky (I consider it supremely unlucky) he encounters a forum or discussion group where some smart chap has said “I had this problem. All you have to do is run

$ chmod 777 .

from the shell prompt and you will be able to read and write all files.” My programmer colleague runs this command, sees it work, and feels supremely satisfied. He feels he has grown technically, learned something new today. And in this entire episode, or even a year later, my colleague has not looked up man chmod (the manual page for the chmod command). The thought never struck him.

Take this case of a young officer who had more than three years experience, was working in Java programming and professed boredom. This must have been 2002 or 2003. He came up to his division head one day and said he wanted to learn something more, something about systems and OS and networking. We were thrilled. We asked him to start reading a few books, including W Richard Stevens’ “Advanced Programmer’s Guide to Unix“, Comer’s “Internetworking with TCP/IP part 1“, Kernighan and Pike, and so on. After a couple weeks, we had a chat to see how things were going. They were evidently going nowhere — the guy seemed to have hit a wall. He was not able to understand what he was reading. We decided to give him fine-grained guidance. We asked him to read just two sections of Stevens’ “Advanced Programmer’s Guide to Unix”, where the author describes file permissions in brief. We asked him to just read 2-3 pages, and meet us for discussions. After a couple of days, we met again. We were stunned by his response.

I can’t do all this reading and stuff. When I read, my brain gets into a choked state — I can’t think. I don’t want to do this sort of work — I want to do some new programming in some new areas, not read books.

He was hoping to get the pleasure which comes from new knowledge — without going through the learning process. We shifted him back to some other project, more Java programming. And we did not stand in his way when he looked for a position in another company. (Needless to say, he got a job in a larger organisation with a higher salary, but then that’s the greatness of the Indian IT industry.)

Cut to 2013. We recruited a bright young officer in the system and server support area. She had worked in a large Internet data centre for a couple years, and had experience in keeping Linux systems, email servers, web servers and other digital daemons in good health. Once she joined, we wanted to encourage her grasp of shellscript programming, because we feel that there’s no point in working with Unix (or its popular current avatar, Linux) unless you know how to use the command line. We asked her to write a simple shellscript. One of her seniors wrote the full pseudo-code out for her, and also listed out the required shell commands like find, sed, etc. for her to study. He pointed out the manpages to her, and encouraged her to play with the tools.

After two weeks of reviews and more assistance, she was unable to write a basic shellscript to do even part of the task we had given her. We did a larger review of her performance, and asked her to find another job. She wanted to know where she had failed. We told her, with detailed examples. She was furious. She said:

This is crazy! You are asking me to read books? Do you know that I have a bachelor’s degree in engineering, and in all my four years of college education, my teachers have never asked me to read and learn so much from books and documentation? Do you think I am a fool? Are you trying to tell me that all this education which I have is a lie?

As you can guess, that exit interview was a bruising experience. Shocking, too.

Most young officers I meet today have not acquired the ability to read and understand concepts. This is true even for college educated officers working in what we think are highly technical areas. The Indian engineering college strengthens the student’s self-esteem by giving him a degree without challenging his ability to think. And the Indian IT industry laps him up and pays him higher than his father or uncles had ever earned, because there are dollar revenues to be earned for routine software maintenance jobs.

And to compensate for their inability to learn, the industry leaders have learned how to provide months of training to each new recruit to make up for what the college education should have done. This training is almost purely about coding, coding standards, and the like. You never hear about algorithms or data structures, let alone bigger abstract concepts. No one talks about tree-traversal algorithms here. Then, once trained, these officers are put into roles where every bit of thinking is done by seniors and all specifications are spoon-fed to them to let them code. (Remember the shellscript-writing story above, where the senior officer wrote pseudo-code for the new officer to translate into a shellscript?) The joke among my more technically literate friends is that the Indian IT industry takes 5-10 employees to do what a smart and experienced programmer in the US or Singapore would have done alone.

Why don’t they read?

The core reason is that they feel that their primary deliverable is to make their code work. They do not associate with their work at the level of understanding — they associate at the level of getting the job done.

Think of a cabbie trying to take his fare to an unfamiliar street. Some cabbies when faced with this prospect will drive a little slower, look for landmarks, try to recollect data about street names they’ve never visited, and create a fresh mental map where they build associations between new landmarks and their memory of familiar streets. Other cabbies will simply ask passers-by, ask their fare for directions, and drive blindly till they reach the destination, without attempting to remember any unfamiliar sights or “figure out” anything about the new destination.

The former class of cabbie will keep adding new knowledge to their mental map. The latter class of cabbie will just get the job done and move to the next fare. Our young programmers seem to be largely in the second category.

Why don’t they try to “figure out” new techniques, new problems and solutions? Why do they have this “let’s get it over with” approach? My theories are as good as the next guy’s. This is where the conjectures start.

Possibility 1: they are scared: Maybe the technologies they work with scare them. It is very possible that poor educational backgrounds of many of them make them so insecure and ill-equipped to try to understand what they see that they simply don’t try. It may seem really strange that I am suggesting that a professional is scared of the technological foundation of his profession, but it falls into place when you realise that most young men and women in this profession chose it because of employment opportunities and financial security, not because they feel any affinity to this profession.

Possibility 2: they are bored: Perhaps they are not interested in their day jobs. It’s possible that they don’t have any motivation to want to gain new technical insights. To put it bluntly: maybe they find software and computers boring. For them it’s just a job. I have seen a lot of this attitude in young programmers. In most such cases, I have seen that they do not appear to have any strong passion for anything. It is as if they do not have much capacity to be fascinated by any subject.

Possibility 3: they are tired: It’s possible that the rigours of a career in the Indian IT industry kill all vitality. The Indian IT industry has acquired some very persistent cultural traits. Everyone works long hours. Every project is over-stretched for time. Every team is under-staffed. In most cases, the customer dictates technology choices, software architecture, platform choices, etc. There is no scope to let a curious mind experiment with anything, try new choices, do the unsafe thing. The young engineer is evaluated for finishing his work on time. Quite often, clean code structure or a scalable architecture is not even noticed — freedom from bugs is the only yardstick to evaluate code. In such situations, it’s possible that the desire to engage with technology itself fades, even assuming that it was there when the officer was a fresh graduate.

Possibility 4: they are discouraged: Young engineers with the spark of curiosity and the energy to read on their own often ask questions, or ask for technical opportunity of their managers. They are usually brushed off with platitudes — the manager has his eye on his delivery deadline, and he believes that young team members can be replaced if they resign. It is either, “Yes, we will see when we can put you in a project of the type you want”, or “But you know, we must accept the technology choices and platforms our clients specify — we want their business.” These responses are non-responses, and finally make the young officer impatient. He changes jobs, then changes it again. He finally learns that all companies (who are willing to pay hefty salaries from their dollar earnings) are the same. After three years of trying, he gives up and settles down with the steady salary and meaningless work.

I have seen all of these cases. The Indian IT industry is a collection of millions of such young technical professionals, who do not read, who do not profess any genuine interest in any technical concept. Yet they work in this field for 200 hours a month. It is heart-breaking.