Programming is not an easy skill to learn. This is evidently clear when you try to teach absolute beginners how to program. It requires a tremendous amount of underlying knowledge and training just to get them started with it. More advanced topics such as algorithmic analysis, hardware specific optimization, or distributed concurrent programming, take even more time and dedication to learn. It is no wonder that technical skills are so highly regarded among programmers.

Ironically, however, the truly difficult part of programming lies not in acquisition of technical skills, but in figuring out what to program, which has little to do with technical skills. It is important to remember that software is a means to an end, created to serve a certain purpose. Although technical skills have inherent academic value, their practical value is nonexistent unless they are used to build a software that solves a real world problem.

In terms of writing, learning technical skills is equivalent to studying grammar in depth, understanding effects of different sentence structures, and improving diction. More advanced topics in programming would be equivalent to literary devices like foreshadowing, symbolism, or poetic meters. Like programming skills, these writing skills gain their value only when they are used to write something that can affect and impact people.

Unfortunately, programmers are notoriously liable to get absorbed in solving technical subproblems, substituting the initial problem they were trying to solve with technical ones and happily forgetting about it. We often get so fixated on the trees that we fail to see the forest.

I am guilty of this tendency myself. During the past several months, I’ve been voraciously studying programming. I finished several books and online courses, watched scores of conference videos, and listened to hundreds of hours of podcast. It was thrilling to gain so much new knowledge. But a few days ago I realized that I got so intoxicated by the joy of learning that I failed to keep in mind that the ultimate purpose of programming is to create a real value. I think this is an undeniable evidence that I am still a junior developer.

I believe that being able to understand and maintain a clear focus on the real problem that he or she is trying to solve is one of the key qualities required from a senior developer. This is much easier said than done. I think this deceptively simple quality demands mastery of at least two widely distinct sets of abilities.

First is the ability to thoroughly comprehend the problem you’re trying to solve. It’d be impossible to keep concentrating on something that you barely understand yourself. Comprehending such a problem requires both business acumen, because real world problems always have practical business requirements, and communication skill, because you need to understand those business requirements as conveyed by the client.

Second is the ability to maintain broad perspective over the project despite unexpected challenges arising in the process. This requires a mastery of technical skills extensive enough to understand new challenges at a glance. Otherwise, spending energy on those problems to figure them out would inevitably force you to take a narrower perspective. Another necessary component is the ability to keep composure. This ability can only be gained by years of experience and no amount of study, however rigorous, can teach it.

Of course, a senior developer would require other skills too. For example, being able to design the architecture of software and choose correct algorithms would be one. Being able to appropriately balance short-term corner cutting with long-term accrual of technical debt would be another. Is my standard for a senior developer too high? Or is it too low? I don’t know. All I know is that I am still far, far away from being one.