A shortcut from Junior Programmer -> Journeyman

Programmers generally have 2 transitions they can go through in their career lifespan:
-From Junior Programmer to Journeyman
-From Journeyman to Heavy Hitter

Some programmers don't make the transition to Journeyman. Mostly these are folks that just aren't suited to the profession for one reason or another and quit within the first 3 years or so. Very rarely, you'll find a 10 year Junior Programmer, but these are a rare breed.

Most programmers stay at the Journeyman level for the duration of their career. There's nothing bad about this-- these folks make up the bulk of the workforce and get most of the work done. These are people who prioritize their life in such a way that they spend a 'fair' amount of time on their career, but don't go out of their way to constantly study IT in the off-time. These are the people everybody depends on to carry out their orders and keep things moving.

A small percentage of programmers make it to the 'Heavy Hitter' level. Every organization has them-- the folks who set new directions and establish development processes. These guys can't afford to stagnate (because they are relied upon to bring new ideas) so they're always studying.

This column deals with that first transition. If you're a Junior programmer today and are looking for a way to make it to the next level, read on.

I know of a technique that can be used to accelerate the first phase and move you to the second one as quickly as possible. This is important for two reasons:
- It brings more responsible assignments (and with them more pay and geeky prestige)
- It starts your 'time in grade' in the Journeyman level, which is a necessary prerequisite towards advancing to the 'Heavy Hitter' level, if that's your ambition

To use this shortcut, you'll require 3 things:
- A solid, working plan of self-improvement
- A reliable pipeline of work assignments, at least 4 or 5 months worth
- A viable alternative place of work that is hiring

1) A solid working plan of self-improvement
You need to conduct yourself in such a way that your boss realises you are on the way to more responsible work assignments. Back when I was a junior programmer (in the stone ages), this meant reading IBM manuals and workshop binders, and taking home thick mainframe greenbar compile listings. Today, this means studying things on the web and on your home computer, and studying your company's business artefacts in your off time. If you aren't willing to part with the time to devote to these activities, stop reading now because this shortcut won't work for you.

2) A reliable pipeline of work assignments
You need to have a steady stream of assignments in your near future, tasks you know your boss is going to assign to you. Some of these will be things that you are best suited for based on your skill sets. Some can be tasks you volunteer for because nobody else wants to do them. Either way, you want to position things so that your boss considers you the go-to person for a bunch of work that's slated to happen in the near future.

3) A viable alternative place of work that's hiring
Of the 3 requirements, this is the only one that requires something other than disciplined hard work. What it does require is a little research and a healthy dose of 'guts'. You need to look inside your company and out for a job posting that's for a programming job at the Journeyman level. They aren't hard to find-- if it's not paying at the guru pay scale and if it doesn't say 'Junior Programmer', then that's your target. Make sure it's someplace you actually would consider working for and make sure you're reasonably qualified for the posting (albeit at the low end).

The Plan:
After making absolutely certain you have your 3 requirements met, make an appointment to talk to your boss. In your conversation, say something like this:
"I've been working hard on advancing my career, and I think I'm ready for more responsible tasks. I really like what I'm doing here, and think I'm making a difference, but I'm tempted to look into this position I see at (name your third Requirement). Can you help me get promoted here so I can advance my career, but still stay here?

If your boss acts like mine did, he will immediately adapt a defensive position in which he hurriedly explains why you can't just ask for a promotion and it's not your time yet. This is fine-- his job is to keep expenses low and to maintain stability in personnel matters. What he really needs is a little time to think things over, because you really are bringing him a good business proposal. Your response should be something like "Well, I'll keep working and learning, but please give it a little thought. How about if we follow up in a week?"

That should give your boss plenty of time to really consider things. If you've done a good job with your prerequisites, your boss should be thinking thoughts like these:
- If I don't keep (insert your name here), I have to train somebody else to do all this stuff. It'll take forever to get a Junior programmer to that level again.
- (Your name) has already been taking on some mid-level assignments. It's a little early, but that promotion will come soon anyway.
- Crap! Where am I going to get someone to handle that stream of work I've got lined up for the next 4 months?
- (Your name) is being a little ambitious here, but I respect that he wants to advance his career.

Then in your follow-up, there are a few things that might result:
- You get the promotion. In that case, congratulate yourself and send me a nice thank you note.
- You are told you're still a little green, but you can work on your development plan and perhaps get your promotion soon. If this happens, BE SURE TO ASK ABOUT TIMELINES. It's up to you to decide how much emphasis to put on the 'viable alternative place to work' at this point. (Do NOT over-emphasize this, as your position really isn't that strong. The purpose of that requirement was to lend a matter of urgency for your request-- the "Why now?" factor). NO MATTER WHAT, YOUR CAREER IS YOUR RESPONSIBILITY, SO SECURE SOME COMMITMENT TO A TIMEFRAME FOR YOUR ADVANCEMENT. Think of it as a project deliverable-- you need to establish a timeline.
- You are flatly denied. In this case, you will have been given some valuable feedback in some form or other-- think about what it means.

Remember, your boss is a business manager, and as such is going to respect the business aspects of your proposal. If you've been diplomatic (and not a ham-handed extortionist) you should not have angered your boss. If anything, your boss will have a newfound respect for your professionalism. (And if not, again-- you have some valuable feedback.) To get to be your boss, this person has had to have gone through a few promotions, too. They know what it's like to want to move ahead.

This plan worked for me 18 years ago. If you choose to try it, I hope it works for you, too. Good luck, and Happy Coding!

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