Experience Levels for Programmers

by Jeffry R. Fisher


As an independent consultant, I frequently encounter potential clients who compare me to other, often less experienced programmers and expect my billing rate to be similar, as if all software developers were interchangeable except for the names of their programming languages. I am sometimes granted the opportunity to explain why I am worth more than "those other guys", and I do so gladly. However, speaking off the top of my head always means forgetting a few things and recalling other things out of order. Consequently, I am writing this primer (a work in progress) to collect and organize my thoughts on proficiency concepts implied but not guaranteed by software developers' overall years of experience.

My goal is to impress management folks with this thesis: that the most important qualities in a software developer are subjective ones like organization, discipline, and general design skills, not objective qualities like perfectly matched buzzwords and counts of years using particular tools. To this end, I have created the following ladder of idealized proficiency levels to show how developers operating at different levels offer vastly different value.

My analysis is loosely based on my own maturation as well as the job titles and descriptions I have encountered at several companies; please translate if your local terminology differs. The basic progression is from tunnel vision to the "big picture", from needing inspiration to supplying grand vision, and from using tedious brute force to inspiring effortless elegance. I am, for now, aiming to cover only two aspects of software development. The first is instructing the computer to do what somebody wants, which I call programming. The second, which I call "analysis", is figuring out what somebody wants and expressing those desires in terms that might make sense to a programmer.

At the lowest levels of proficiency, one is either a programmer or an analyst, but not both. To attain the higher levels, both aspects must be mastered and synthesized. At the highest levels, hardware is also involved, but since my focus is software, I am setting aside that whole progression and will mention its confluence only in passing. My dual entry progression is thus:








Junior Programmer

Senior Programmer

Programmer /Analyst

Systems Analyst

Systems Engineer

Staff Scientist




A software developer may become an analyst first and then (maybe) advance up the programming side to become a programmer/analyst, but most begin their careers as junior programmers (as did I). In time, one might evolve into a senior programmer and then possibly learn analysis; however, seniority alone does not guarantee advancement. Each person has a maximum level of competence beyond which one is either befuddled or simply unmotivated.

Therefore, besides merely accumulating years of experience, one needs both aptitude and a fitting temperament to attain the higher levels. It also helps to have good role models along the way, for it takes much, much longer to reinvent a discipline than to learn it from a good example. Therefore, determining whether a developer is a systems analyst or merely a moldy junior programmer requires intuition and subjective discernment. To some extent, "it takes one to know one." Objective measures such as years of experience and job titles are merely clues, not definitive descriptors.

Level One

[Let me preface my first level remarks with this apology: clerks and junior programmers are generally diligent, conscientious workers. I do not seek to demean them; I just need to point out how much more there is to programming than merely picking up its tools and wanting a desired end product. Though my descriptions may seem harsh, understand that they are as much a self-critical reflection back upon my own youthful exuberance as an examination of recent events. My primary aim here is to paint a realistically gloomy backdrop against which the expertise of the higher levels will shine appropriately brightly.]

Jr. Programmer

Junior receives detailed instructions and then writes a computer program or piece thereof. The detailed instructions need to tell Junior not only what the program should do, but also much of how. Junior rarely asks why a program should be written or why it should be written a certain way, and this endears him to those supervisors who wouldn’t have answers. [Note: The competent technical supervisor does have reasons, and those supervisors wise enough to cultivate junior programmers to the next level see "why" questions not as annoyance but as a sign of greater potential. Therefore, they will invest time to answer.] However, Junior does sometimes ask more about "how". When he doesn't, you may wish that he had, because he tends to jump into programming at the drop of a hat without "wasting time" with a design. Junior doggedly pursues the first solution that pops into his head, usually without much regard for how tedious it may become or how it may waste resources.

Most of the warm bodies and extra pairs of hands supplied by temp agencies fit this description. Unless firmly disciplined and led by higher level developers, junior programmers and their creations will be very shortsighted and inefficient. They’ll produce a hodgepodge of poorly coordinated, poorly designed programs. It's sort of like hiring children to finger-paint your house: messy but cheap... per hour... per head.

Unfortunately, though their hourly rate seems like a bargain, many budgets have been bled white by the headcount needed, hours consumed, and deadlines missed. Later, managers discover that nobody in the world can decipher the tangled mess left behind, so they’ll never be able to add new features or to fix the persistent, annoying bugs. After limping along with their mess for a few years, they throw it all away and start from scratch.

Note: Junior doesn't understand end users or the jobs they do, and they don't understand Junior, so a wise supervisor never lets them meet, preferring instead to insert an analyst (or better, an analyst and a superior programmer) as a buffer. One avoids much screaming and yelling that way.

Don’t get me wrong; there’s a place for junior programmers on large projects where higher level developers can delegate tedious but necessary work. They can produce significant amounts of high quality code if they are expertly organized and monitored by masters of the craft who have been around the software life cycle block a few times. Just don’t imagine for a second that Jr. programmers alone can create a satisfactory solution for anything unless you plan to use it only once and then throw it away. Junior programmers are the apprentices of the software development world. Like the Sorcerer’s Apprentice, they can create quite a mess if not closely supervised.

Jr. Programmers typically have some training in a computer language or a development tool and less than two years of overall professional programming experience. To distract from their inexperience, they lead prospective employers to focus on how precisely their language training matches what a project requires. Since decision-makers are usually non-developers, so they’re often attracted by the objectivity of this nearly insignificant criterion. In IT departments where such tactics succeed, some managers have never even seen higher level developers, so they have no idea what they’re missing.

When I interview candidates for salaried Jr. programming slots, I ignore language matching and look for the unteachable personality traits (intelligence, creativity, organization) of a potential higher level developer. That’s because similarly constructed languages can be taught quickly, but raw aptitude is something one is born with, temperament develops over a lifetime, and organizational discipline develops over many years of well-mentored experience.

Quote: "What's a Cartesian product? And why don't you like it in my SQL?"


Clerk is not a software developer. I include this description here because I need a placeholder for the research equivalent of a junior programmer. By definition, "Clerk" doesn't understand how computers work, so Clerk often asks the IT department for ridiculous, utterly impossible things... but doesn't know enough to ask for easy features that would save enormous amounts of clerical time and effort, possibly even obsolescing Clerk's whole job.

Some "clerks" are highly placed professionals in other fields like accounting and sales. They may be (and probably are) excellent in their areas of expertise. However, as far as software design is concerned, they are fish out of water. They are like prospective homebuyers who know that they want nice houses but whose earnest desires do not qualify them as architects, general contractors, or even real estate agents. In spite of this, one of the most common mistakes made by many firms implementing new software is to treat topical experts as software architects, assigning junior programmers to them with predictably unfortunate results.

However, there is hope. If Clerk focuses long enough on software acquisition, has the right stuff, remembers wondrous revelations of the possible, and can learn from explanations of the impossible, then s/he may evolve into an analyst able to act as liaison between IT and unevolved clerks.

Quote: "Please write me a program that'll restore my B&W images to original color… I need it by tomorrow."


Sr. Programmer

It may seem ironic that "senior" programmer is but the second of six levels of software developers, but "senior" is a designation only relative to "junior". While the juniors are like home builders who know how to hammer nails into wood but know not when or where without supervision, seniors know when and where but are not yet qualified to design whole houses that can support their own weight.

Senior receives a list of requirements, figures out how to satisfy them with a program, and then writes it. Senior doesn't need instructions in as much detail as Junior; he (or she) can figure out internal details unassisted. He also doesn't require as much monitoring as Junior because he is more likely to think of more than one solution to each task and then choose one that runs efficiently yet is not too time consuming to write. The critical factor here is that senior thinks about design before launching into programming.

However, Senior is not an analyst yet, so don’t inflict him/her upon the outside world without supervision. Senior also still suffers from tunnel vision, working on one program at a time without anticipating how each one should fit with others in the overall scope of a system. Still, Senior’s algorithms are vastly superior to Junior’s junk.

Whereas Junior was equipped with tools but no skill, Senior has developed some skill from experience and good mentoring. An aside here for those who don’t know: Programming languages are not skills, although it takes skill to use them well. On the contrary, programming languages are merely tools that can be picked up in a matter of days by any competent senior programmer (or higher) who has already mastered the relevant design skill in any similar language. It’s like a carpenter setting aside a Philip’s screwdriver to pick up a standard one. For instance, structured programming is a skill. One who has mastered structured programming in Pascal can pick up Ada by reading a book. Similarly, object-oriented design is a skill. One who has mastered object-oriented design while using Visual Basic can pick up C++ in a fortnight and then lead any junior programmer who has been using (or abusing) C++ for years.

Therefore, when one is hiring senior programmers, focus on desired design skills like assembly coding, structured programming etc. Some complex tool sets containing protocols as in Windows™ MFC library and Actuate’s report design AFC library etc. are useful to know in advance, but they’re still just lists of facts. They can be picked up from reading books, online help text, or (for a sure shot) intensive training, requiring maybe two weeks instead of two days to acquire.

On the other hand, skills are disciplines that are absorbed over the course of months and years, and then only from good mentoring or from enduring the unpleasant consequences of testing or maintaining poorly designed programs, and then only if one has sufficient aptitude. A junior programmer may have invested thousands of dollars and many weeks training and reading to acquire a tool set, and he may even have a year of experience using it. However, without the design skills that come only from applying long experience and good mentoring to an above par natural aptitude, he is still just a junior programmer with a new hammer. Take a senior programmer (or higher) having the relevant general skill, send him (or her) to the same training, and two weeks later you have someone who can program circles around junior and his year or two with the tool. [A competent contractor can send himself to training on his own nickel during the week or two between the day he signs and the day he reports.]

A typical senior programmer has 2-5 years programming experience, some of it working for a superior developer. The higher caliber, uncommon developers offered by agencies are usually senior programmers, though just as many are junior programmers who’ve logged a lot of time without learning a whole lot. Caveat emptor.

Quote: "I’m glad I used logical structure when I first wrote this; it’ll be a snap to add the new features."


The evolved form of Clerk, Analyst is a bridge between programmers and users/customers. Analyst mostly understands users and their jobs (or hobby or whatever context could use some assistance from a computer). In addition, Analyst has an inkling of what the computer can and can't do, so he (or she) can ask users some incisive questions, suggest feasible alternatives to impossible demands, and then write a list of program requirements.

However, a mere analyst is not a programmer. The best analysts realize this, so they restrict themselves to abstract terms that a programmer can translate into code in the most efficient way possible. However, much more common is the mistake of couching requirements in overly specific programming terms (e.g. specifying an "array" to store a bundle of data where a senior programmer would prefer to use a linked list).

Note: If you ever meet an "analyst" who doesn’t ask the right questions or suggest feasible alternatives, then you probably have a clerk wearing an analyst’s hat.

Quote: "What if we do this… Will that get the job done?"



The PA is both an analyst and a senior programmer. Most are programmers who learned to talk to outsiders to research requirements, but a few are analysts who were sucked into programming and became good at it. A PA is told of a need, and then he (or she) does the research to find the features required. Most PA’s then do their own programming, but some may guide one or more lower level programmers to whom they may delegate.

A PA knows much more about what the computer and its tools can and can’t do than does a mere analyst, so a PA is very apt to respond to requests by offering up features that the requester never dreamed of. Consequently, PA’s tend to produce much more elaborate and valuable program specs than pure analysts do. Therefore, analysts’ research can usually profit from a PA’s review (or higher) before being handed off to programmers. Not surprisingly, allowing a gifted PA to exert influence over the programming style of lower level developers nearby will improve both their productivity and the quality of their programs.

Programmer/analysts are uncommon within IT departments. Though many wear the hat, maybe only one in twenty IT developers synthesizes programming and analysis skills at the levels of inventiveness and scope I am describing here. They more commonly arise in high tech companies’ R&D departments. Perhaps for that reason, the PA is generally the very highest level of developer available from an IT or MIS oriented temp agency (or the management consulting arm of an accounting firm). Real PA’s being rare and expensive, usually the only agencies to have them are engineering and software firms specializing in big project consulting. Watch out for temp agencies and accounting firms offering IT "programmer/analysts" that are really mere analysts trained to be junior programmers. From a low-tech supplier, you need luck to get even a senior programmer who is on his way to the third level. Again, caveat emptor.

On the other hand, programmer/analyst is the lowest level at which independent software consultants can survive. Independents must be able to fly solo, which virtually requires that one be both an analyst and a competent programmer. If an independent has any satisfied customers at all, then he is probably at this level or higher.

A typical PA has 5-10 years overall programming experience and is comfortable interviewing non-technical people to learn what their computer needs are.

Quote "Well, if that’s how you plan to use the program, let me tell you about an off-the-shelf function I can insert to automate your whole task with the click of a mouse…"



Systems Analyst

A systems analyst is assigned the broad goals for a whole modest project or a major slice of a large one. The SA’s primary function is to break the project into multiple programs or modules that will be programmed together and possibly work together as a cohesive system. To do so, the SA needs to choose a suitable software design methodology and anticipate the interfaces by which the pieces will fit together. The SA is usually a team leader who then assigns pieces to lower level developers, constraining them to fitting the interfaces. The SA (or higher) is also a person who creates programming standards and then tells junior and senior programmers to abide by them.

Because the SA looks over the scope of several programs and compares multiple needs, he (or she) has a chance to notice programming that can be shared or reused. The SA also has a chance to detect goals that can be solved without programming, realizing enormous cost savings. As a strategic planner, a systems analyst is also farsighted, investing time and effort in the present to save money and effort later. This farsightedness will show up in both the interfaces and the standards and practices imposed on subordinates.

Finally, as an added bonus, a systems analyst can mentor lower level programmers who may never have seen "software methodology" before. Those who care enough to pay attention can become better programmers, a long-term boon to the company that can retain them.

Only the largest and luckiest IT departments have true systems analysts. The rest either occasionally contract a top-drawer consultant for their infrequent big-project analysis needs, or else they get by without the cohesiveness, coordination, and farsightedness that an SA provides. If a low-tech temp agency or accounting firm ever serves up an SA, it’s almost certainly an independent consultant who has been subcontracted under its banner. A high-tech, big-project software consulting firm might have an SA leading its team, but the team lead is as likely to be a PA. Most SA’s are cultivated and retained by software and engineering giants, though they can sometimes be lured to promising startups offering loads of stock options.

Don’t hire an SA to fill the role of a junior or senior programmer. He won’t be content to wear blinders and work on tiny, disjoint programs without knowing how they’re supposed to fit together. He will be especially reluctant to take inexpert direction from a supervisor who’s in over his head. What’s more, the SA is liable to investigate program requirements and even the obsolescence of the positions requesting them, finding that major pieces of work don’t need to be done and that some whole job descriptions or offices can be eliminated from the client’s organization. If you know The Peter Principle, then you know that this sort of over-competence can ruffle feathers, upset apple carts, and tread on toes. Sure, the SA may save a company millions, but who would trade the short-term happiness of the administrative staff for a few zeroes on the bottom line? If you’re like me, you want to have your cake and eat it too, so invest a few extra dollars to put the SA into an authoritative expert consulting position from which startling revelations will be better received.

The typical SA (if there is such a thing as typical among such elite developers) has 10-15 years overall development experience (more if never mentored by a competent SA or higher) that has covered all phases in the software life cycle (requirements analysis, development, integration, testing and maintenance).

Quote: "I talked to Mr. Z_____; we discovered that I can design the program to deliver his numbers directly to him in the form that he wants instead of delivering them to you in form you requested. Therefore, your whole job is going to be eliminated. You should talk to your supervisor about assigning you new work so that you won’t be laid off."



Systems Engineer

At this level, another whole stream of advancement (hardware development) merges into my progression. Systems engineers integrate software and hardware, viewing an even larger project scope than systems analysts. Many SE’s begin as electrical or mechanical engineers first and learn software as a secondary discipline while advancing through similar levels as hardware developers.

Though there are some hardware decisions in IT, there really isn’t the need for an SE like you have in high tech R&D, inventing new devices or embedding software into chips and boards. Therefore, placing an SE in an IT setting could be overkill. SE’s do things like integrating all of the parts of an automobile drive train, including all of the programming on all of the chips.

Even more so than SA’s, SE’s are jealously hoarded by engineering departments where huge salaries and copious stock options virtually guarantee that they’ll never see the light of day.

Quote: "No matter what goes wrong with the hardware, we’ll compensate in the software."



Staff Scientist

Staff scientists are both engineering wizards and visionaries. In high tech giants, they virtually have carte blanche to start their own projects and spend money. Members of the board of directors are more likely to know their names than vice versa. Though usually guarded jealously, some escape to attract investors (if they even need them) and create their own companies. Think Steinmetz.

I don’t think that staff scientists are ever available as consultants, unless perhaps you dig one up out of (semi) retirement to knock off a little project for fun.

Quote: "Ah, I think we really could put a miniature particle accelerator on a silicon chip and use it to fuse hydrogen for power. I’m going to require the following people and resources…."


So where do I rate myself? Notice where the descriptions suddenly become much briefer. I am easily a systems analyst, even having some inkling of systems engineering. I have dealt with integrating hardware and software from the software side, but I am light on hardware design. I can talk to hardware, but I won’t pretend that I can invent it. The rest of systems analysis, as I’ve described it, is well within my grasp. I am especially keen on discovering ways to avoid unneeded programs or to eliminate jobs by rendering them obsolete. Therefore, I see myself as a top-drawer programmer/team leader who doubles as a management consultant.

So… that’s why I am worth many junior programmers… or even two or three senior programmers.

Jeff Fisher is the founder and president of Propagate Ltd, which is "liberating digital content" as LiberateIP.com. Still available as an independent consultant based in Vancouver Washington, he specialized in database reporting using the Actuate system, but is amenable to object oriented design in any suitable language. He contracts both directly and indirectly, traveling 100% and internationally as needed. When not on the road, he may be contacted at "programmer (at) jeffryfisher (dot) net".
Copyright 2003 by Jeff Fisher