A secret key to 'Senior' level programming

When I first started in DP ('data processing', we called it then) 20 years ago, I was working for a company that acted as an outsourcer for banks. I started with the company as a trainee, then graduated to the first programmer 'rank' of Junior programmer. Internally, this title carried the cryptic title 'E07'.

I soon found out my company ranked programmers in this way:
Junior programmer = E07
Programmer = E08
Senior Programmer = E09
Superhero = E10 (a very rare breed)

Payscales, of course, were tightly coupled to these ranks, much the same way they are today.

Like all junior programmers, I hoped to spend my required year or two in the E07 ranks, then move up. One thing I was lacking, though, was an understanding of what made the difference between the programmers that went to the very highest ranks and those who stayed in the lower levels.

One day I was working on a project with a kind-hearted E10 named James. We were having a friendly conversation about the kinds of tasks we had ahead of us when James made a profound statement. He said "The work is all the same, whether you're an E07 or an E10".

I was dumbfounded. Not until that moment had I realized that the work I was doing was just as important to the success of the project as the task James was working on. I was doing analysis and coding, James was doing analysis and coding. Even though he worked at the stratospheric E10 level, he used the exact same compiler I used, he worked on the exact same data I worked on, and he used the exact same development environment I used. A failure on his part would embarrass the shop, and a failure on my part would embarrass the shop. In the context of this project, we were peers!

Now, don't get me wrong. Junior programmers are most certainly NOT worth the same money senior programmers are. Today, I depend heavily on widespread recognition of this fact. But at that time, I gave this matter a little thought and came up with an observation that has benefited me immeasurably, to this day.

I looked to my friend the E10 and asked myself what the difference was between his skill set and mine. I drew the conclusion there were at least 2 areas in which he was superior: breadth and depth.

Breadth meant that he had a much wider array of tools at his disposal. At that time, I possessed a moderate amount of knowledge about batch COBOL programming. My friend was knowledgeable about batch COBOL, online COBOL, assembler, JCL, system skills, and more. In today's world, this would equate to something like a Java guy standing next to a Java guy that also knows C++, C#, Ruby, Python, Erlang and a good number of frameworks for each. If the project du jour is just plain Java, those two are on equal footing. But when the next project comes along things could most certainly be different.

The other dimension is depth, which refers to the amount of knowledge held in the workplace domain. In my yesteryear story, I knew how to write and compile my COBOL program, maybe even as well as my friend. But if my program had a bug, I had one trick up my sleeve-- diagnostic debug statements. My friend had that and the ability to read core dumps, knew how to make the compile listing show assembly language (which he could look over for performance heuristics) and more. In other words, beyond the surface of the program source code we produced, he had a much better understanding of the platform we were operating on and how to exploit it. Again, my source code might have been a match for his, but if we needed to go to the next level..... there was an indisputable difference.

In today's world, this might mean the senior guy understands how to tune a JVM, or how to extract meaningful data from profiling tools. The senior level guy knows how to install, configure, debug and profile the platform. The senior guy will know how to establish the build environment, the junior programmer will likely only be productive once it's established.

So I guess I figured out that I had a lot to learn, and set about trying to increase my own depth and breadth. (An effort that continues to this very day!) James' words from two decades ago have helped me measure myself against my peers to see where I need to improve, and this has furthered my career in more ways than I can imagine. If you're on the young side of your career, I hope they can help you, too.

Happy Coding!

Rick