What Level Programmer Are You?

Everybody’s talking about how programming is the skill that we all are going to need. [Except those folks who might feel that most programming could be turned into wizard-like tools. Insert long discussion about Strong AI.]

But what’s a programmer? Is the guy who set up his own Apache Web Server a programmer? How about the guy who created a complex Excel spreadsheet? The guy who made his own RPG level? Minecraft players? When we say “Everybody is going to have to know programming” what, exactly, does that mean?

We need a set of programming levels.

  • Level 1, The Read-and-Type: This is the guy who can read how to set up a web server, go through the directions, and get the thing working — as long as nothing goes wrong. He knows how to use a text editor and basics of the file system he’s on. He also has to have some ability to move and manipulate files, like using zip or FTP. He can use abstract symbols in a structured, explained way along with having system skills.
  • Level 2, The Script Kiddie: Can write a linear script to tell the computer to do something. Able to learn and use symbols on his own. Should be able to script out a very simple solution to do something useful for himself in bash or VB if given enough time and written instruction.
  • Level 3, The Librarian: This is someone who has learned some libraries or APIs and have the ability to learn more. He knows that for whatever scripting language he is using, he needs to be able to connect libraries to it. If he had to, he is able to read manuals and do that on his own. He is also able to search for libraries on the net and use them. He is able to find and sometimes even create his own symbols for his job. (Can write a function or declare and use a struct). Most beginning system administrators fall around here. Also beginning users of advanced Macro systems, like Excel.
  • Level 4, Object-Dot-Method Guy: Beginning to learn coupling and cohesion, this person starts organizing their scripts into objects with public and private members and methods. This is your six-week-programming miracle, the introductory .NET programmer. He’s supposed to play with a wizard, know the libraries, and then construct something that fits inside of classes that are given to him. If he’s not using classes, he can create his own modules or code files. Some advanced users of scripting systems get this far. There are a lot of advanced Excel shops with stock brokers who have basically coded their own VBA application without really knowing it who are in this level.
  • Level 5, Multiple Paradigm Man: Once you are able to crawl, you get into all sorts of trouble. A common next step on the programming ladder is being able to work in multiple paradigms. You can code C#, but you also know how to build tables and write SQL. You can write acceptable C, but you also can work with Javascript and HTML. You’re not a master of either skill, but you’re able to understand different ways of looking at the same problem. You know you’ve reached this step when you stop saying “We could fix this in X” for every question where X is the language you first really understood.
  • Level 6, Architect Apprentice: This comes as you really begin to engage in the craft of programming. You begin to deeply understand the libraries and APIs that you use everyday for work. It’s not that you have memorized them. It’s that you understand the different patterns the architects use to accomplish their goals. Want to draw in Win32? Probably going to need a handle to some GDI resource. Maybe a few. You know that a handle is a UInt32 hash into a system table somewhere — a common paradigm for Win32. Want to add your own library to JQuery? There’s a format for any new library. You know how that works and can explain why it works that way. As you work your tools, you begin to start thinking like the people who put the tools together. You also begin to learn how to refactor your code to the point it rocks. You start learning what code quality looks like. You begin to understand.
  • Level 7, Architect Astronaut: The time comes for you to build your own API, platform, or library. Maybe it’s a large project that requires it. Maybe you just want to take your new knowledge out for a spin. While your system is designed to solve a real-world problem for users, your target audience is maintenance programmers at Level 5. At this phase you’re deeply into the Gang of Four, OOAD, templating, and best practices. Most of us make a mess the first few times into this area, not understanding that it’s easier to make something complex than it is to make it simple. During this phase, which can go on for a long time, you continually mistake creating more complex and flexible libraries with building higher quality systems. Many times you (and hopefully a few others on your team) understand what you’re doing, but to bring in somebody from the outside would take months of domain-specific training. Support personnel don’t stand a chance — most all support calls end up on the team’s desk.
  • Level 8, Meta Man: At some point, hopefully, you realize that much of the complexity you have put into architectures and frameworks can better be described as a Domain-Specific Language. Your target audience becomes programmers at Level 4. Yes, the coding complexity is greater, but the code itself is much shorter and the DSL opens up your code to go all kinds of places. In short, you become the writer of the script languages that beginning programmers use. Your systems are open to beginners through easy-to-use scripts and wizards. You can learn this skill separately, but most times after many large complex architectures, eventually you factor your way to a DSL. And then again. And again. Pretty soon you start seeing the pattern: well-understood problems lend themselves to DSLs.
  • Level 9, Functional Nirvana: Moving into the bonus round, you start really learning how to program by learning Functional Programming. Your target audience is maintenance programmers at Level 3. FP makes you a better imperative programmer, helps you easily kick out DSLs faster, and can massively reduce the amount of code it takes to solve a problem. It can also be highly-scalable. With some functional languages you can even hot-swap while the system is running. Just like with all these other advanced levels, at some point you start feeling getting a bit of nirvana going on. FP must be the answer to everything! By this time, however, you’ve been through several of these stages of euphoria, so this one isn’t as bad as the rest. The real world intrudes. FP, although less buggy and many times much faster, can be very difficult to code. Programmers have to carry a linker around in their head much of the time — they have to keep track of lots of symbols. Eventually you realize FP is also just a step on the path, much similar to OOAD.
  • Level 10, Language Oriented Designer: You view all programming as creating new programming languages. The only difference is what the new language is supposed to do. You understand how to create Object-Oriented languages, Functional languages, and simple untyped scripting languages. You know when each is appropriate. Your target audience is maintenance programmers at Level 2. You sit down for each project and ask “What kind of language do we need here?” At the end of your project you have a nice tool that both fixes the problem and is easily understood and extensible by entry-level programmers, freeing you up to move on to other things. You can easily make the case that most projects do not require language-oriented designers, but that’s a story for another day.
  • Mystery Level, Computer Scientist: This is either the pinnacle of programming or doesn’t exist on the spectrum at all, depending on your perspective. This is the science of programming. Lots of cool stuff here. Your target audience is everybody else in the universe. But the focus is not on making things people want, it’s advancing the state of knowledge. Because most other capability levels of programming are so people-based, these guys live in a different world, but a necessary one. How easy is it to cross back and forth between the two worlds? Beats me.

You could construct many alternate paths here — for instance, functional programming might come first for you, then OOP later on. You might also put in building your own compiler — wasn’t that fun in college? Or assembly. Or really understanding set theory and how it applies to both databases and programming data structures. Or writing your first true programming tool.

But this is the path I see most programmers follow.

ADD: Please read the (very short) follow-up for another look at this.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

19 thoughts on “What Level Programmer Are You?

  1. Paul W. Homer

    I’ve taken to referring to programmers in the mid-levels as ‘having one eye open’. They can build stuff, but they’re still building the wrong stuff a lot.
    My suggestion is not to equate any of the programming paradigms like OO or functional over each other. They’re all just different branches on the same tree, and there are many many more branches out there. What seems to happen is that a programmer starts on one, gets functional with it, explores its boundaries and then hopefully jumps to one or two others.
    At that point, I think they start to look for better ways to build things faster. DSLs come in, but so do Patterns, re-use, architecture, etc.
    I agree with your upper level being science, but then beyond that I think engineering is next. First you explore the inherent limitations of coding, but then you start thinking about ways to feed that knowledge back into the process of actually building bigger stuff. The idea is that you’re no longer dependent on just hoping the code below you does what it needs to do, but rather that you know exactly what it does, and can leverage consistently. The trick then is being able to do that so that the lower-level programmers can leverage your work, while building high-quality, sophisticated systems.
    Paul.

    Reply
  2. DanielBMarkham

    Thanks for the comment, Paul.
    I think we disagree, but I’d need to explore this further with you to be sure.
    Quality and Engineering are orthogonal to this list. I re-did the list on another post. I think the mistake I made with this post is getting too concrete, mentioning OO and FP. Once I did that, people started taking positions based on their own experiences with FP. Take a look at that (very short) post.
    The reason I think we disagree is that, to me, FP is simply a better paradigm for creating and dealing with complex systems of meta symbols. You just can’t do that in OO with any degree of ease. Believe me, I’ve tried.
    The entire quality/engineering/patterns discussion happens in the middle levels, where you realize that there is a system to making your coding model more “correct.” The cool part about those things is that, if consistently applied, they’ll carry through the rest of the levels naturally. What I find in many cases, though, is that coders have the tools to continue refactoring and understanding how to do better and better, they just give up. The solution is “good enough” and off she goes. Nothing wrong with that, but it delays the day when you see the larger patterns open up.
    Hey, I’m no expert, just some random guy on the net. So take all of this in the easy-going spirit it was intended. I’m getting much more from you guys, reading all the great comments and criticisms, than anything else. Thanks again!

    Reply
  3. Paul W. Homer

    We’re not really that far apart :-)
    I do tend to see the decomposition in terms of code and data being either static or dynamic, but symbols and meta-systems is fine.
    I have little real experience with FP, but although it has a different paradigm from OO it doesn’t come across as having been a big leap like going from assembler to 3GLs. Certainly I’ve heard many an ex-APL programmer grumble about how much more then could get out of their language then they could with something like Java. The different paradigms all have their strengths and weakness, but so far I’ve found that they tend to be better with some types of programming, at the expense of others.
    I don’t really think quality is orthogonal though. I think it is similar to learning to play an instrument. At first you’re just happy hitting the right notes, but as you get better and better, you refine the quality of the music you are producing. I see this often with young programmers who are just happy the code works a bit, but often their overall approach to solving the problem was weak, and the corner-cases left untended. Older coders aren’t as stressed by just getting the basic logic, so they can spend extra on really refining it, possibly fining a nice abstraction to wrap it all up in a bow.
    I’d like to say I’m an expert, but nobody would believe me :-) (Is anyone an expert in software, anymore?)
    Paul.

    Reply
  4. Xun

    It is surprise that Functional Nirvana is elevated to such impossible height, 5 ladders higher than OO dudes, got to ditch my OO books now.

    Reply
  5. DanielBMarkham

    I’m hoping you’re just yanking my chain to get a link to your blog. Please don’t ditch your OO books.
    I think a lot of functional programmers are crippled because of their lack of OO knowledge. They take some OO in college, maybe work a miserable job in C++ or something, then cop an attitude about how bad OO is and just skip ahead to FP. That’s not a good thing. I wouldn’t want to wish that on you.
    The world of OO — analysis, design, set theory, abstractions, modeling, structured engineering, coding for large groups — you can’t skip over that. You shouldn’t skip over that.
    Put another way, without knowing OO inside-out you’ve missed the point of FP and LOP. OO thinking is freaking awesome. If you want to be a good programmer other people can count on, you need OOADP. These aren’t levels in a game. These are levels of symbol manipulation and practical knowledge. Using each one to make technical things people want is a required part of moving up the ladder.
    Thanks for the comment. I appreciate your feedback!

    Reply
  6. Bram Cohen

    Your list starts off well, but the levels above 7 are horribly tainted by your own ideas of how things should be done, which I just plain don’t agree with. Functional programming and embedded scripting languages in particular are things which are almost never a good idea.

    Reply
  7. DanielBMarkham

    Bram,
    Awesome comment, but I beg to differ. Did you look at the more generic list on the next post? Would be interested to hear your thoughts about that.
    Embedded scripting and DSLs are not synonyms. FP is the best tool for meta symbolic manipulation in complex environments, which is the natural last step before LOP.
    But I appreciate your agreement up until level 7. I guess that means I got it mostly right? :)

    Reply
  8. Developer Art

    An amusing read indeed, and it is true as well.
    I found myself at “Level 6, Architect Apprentice” and then I realized your classification takes a turn at this point. Level 7 and beyond it describes the path of a techie, computer geek, the person whose main interest is technology.
    But what about people whose main interest is domain area, solving people’s problems, seeing happy faces of users? To them technology is but a tool to reach the goal.
    You might want to extend your classification to include an alternative Level 7b, 8b,… Nb for a business type of a programmer.

    Reply
  9. DanielBMarkham

    Thanks Art!
    Yes, you are correct in that one of the “mistakes” of this piece is not focusing enough on the people aspect of programming, which is half of the job! This just focuses on the ability to manipulate symbols and structures in your head and code. I think by not including people in the mix, it gives the impression that programming is simply technology-related, and that’s not the case at all.
    I think the upper levels still have as much to do with people as before, it’s just not spelled out as well. For instance, as you begin to work with more complex structures, your customers become both the users and other programmers, which means whatever you make has to be easy to use for them.
    The guys I know working at level 10 (I’m not one of them) say that it’s possible to keep both groups of people together. That is, you can write a solution that is extremely easy-to-use, but also a fully-programmable turing machine. So you get the best of everything: you solve the problem for the user, you set up an easy-to-maintain and extend system for whoever cares, and you don’t have to revisit the problem continuously to tweak things.
    Level 7 is a tough spot to be. I stayed there for almost ten years. You know enough to know that a lot of programming you see is crap, you realize that there are a hell of a lot of tools and ways to solve a problem, but yet the mapping of the domain to the user in a way the _user_ finds extensible can be very frustrating. Plus tools and language vendors know you guys on level 7 and they love you. Always some new architectural pattern or whizbang set of UI tools to keep you distracted. Fun toys, though!

    Reply
  10. Brij Sharma

    I guess I am at level 5. Didn’t know where I was and didn’t know where to go, but probably I do now. Thanks.

    Reply
  11. Yannbane

    I don’t agree with your implication that it is possible to sort programmers into those categories… I’m always for using some kind of tags, other than categories (well, you basically categorize based on characteristics, which I refer to as tags). You simply cannot put a real person in any of those categories (well, maybe you can, but that’s rare)! People are a mix of those things, a really complex mix…

    Reply
  12. DanielBMarkham

    Great criticism!
    The point here isn’t to put people into boxes. This is lighthearted. Take it as such. The point is for programmers like you and me to take a look at what levels of symbols and abstractions they are comfortable working in. Heck, you might be great at working at level 10 and spend all your career working at level 4. That doesn’t make you a “level 4 programmer” We’re talking capability — a plan for your future education. Not sticking people into boxes. Sorry if you misread it as such.

    Reply
  13. Marty Grogan

    Many years ago, circa 1986, I published a similar piece as a brochure to lighten the mood for clients who were computer shy. Just to share the headings…
    1.0 Neophyte Wimp
    1.5 Yellow Paged Pigeon
    2.0 Outreaching Adventurer
    2.5 Mail Order mainac
    3.0 Recreational Practitioner
    3.5 Bulletin Board Banchee (Remember BBS?)
    4.0 Recreational Practioner Parent
    4.5 Keyboard Kitten
    5.0 Competent Professional
    5.5 Competent Professional Extraordinaire
    6.0 Apprentice Power User
    6.5 Established Power User
    7.0 Power User Mystic
    (With apologies to the National Tennis Rating Program.)

    Reply
  14. Bram Cohen

    I have the same issues with your abbreviated list in the next post, which is a reasonably accurate summary of this post. I write code in very pythonic Python, and don’t even use subclassing, for the simple reason that I don’t see any utility in using anything fancier for my work. There’s a strange wrinkle on the last one though – I am in fact a scientist. Your positioning on that is a little strange, because you don’t posit any levels of skill at algorithmic thinking and understanding of asymptotics until the very last one of doing cutting edge research in such things. The waters there have been muddied a lot over time, because everything comes with a reasonable collections framework now and for the most part if you use the collection which seems most natural for the task at hand you’ll get the right asymptotic, but the basics of algorithmic runtimes should still be understood by all professional programmers above a certain level.

    Reply
  15. DanielBMarkham

    Bram I’m not really sure what the heck you are talking about.
    There’s no recommendation here for using one level or another for any type of work. There’s no implication that if you are working at one level that moving to the next level is inherently better. Just the opposite: you should work at the simplest level possible for the given problem you have. You don’t write a new computer language for something you could script out in ten minutes.
    So if there seems to be some recommendation on _how_ to do things, I apologize. The point was that there are levels of working. You could be very comfortable working at a high level and spend your entire career never working there. Good for you! The simpler you can make an answer, the better.
    The problem I see is a failure for most programmers (who by and large do not have a huge amount of formal education in computer science) to acknowledge that levels exist over where they currently work. So they take a lower-level tool and, using a hammer, make it fit a problem that requires something with more oomph. This leads to pain all around. If programmers simply realized that there is a scale, they would at least know that other people were solving similar problems without so much pain, which is a good first step.
    As far as the collections and such provided by most libraries, yep, they have them. And yep, you should pick the right one. And yep, you should know the trade-offs involved with using each one in terms of storage and performance. But nope, I have no idea what that has to do with anything.
    I appreciate your taking the time to comment. Sorry if I’m being as dense as a rock. Wish we were communicating better, but I honestly appreciate your effort.
    Sounds like you have a fun job! I’d love to play around with Python some, just too many projects and not enough time. :)

    Reply
  16. Rodrigo Montemayor

    Hahahahahaha excellent post man.
    I think functional programming would be a little earlier, now that more and more programming languages are implementing it (or attempting to).
    At the very end, after the computer scientist, I think would be the person who knows how to use a computer like in the movies where they hack any system in five minutes, creates the algorithm so you can zoom in eternally and don’t lose quality, and someone, someone who people are afraid to approach asking him to fix their computer because it is slow and has 20 browser toolbars.
    =P

    Reply
  17. BE Burns

    I think a beter way to examine your concept is by using a three dimmensional map instead.
    The three dimensions would consist of:
    DIM User,Support and Programmer
    DIM The measure of skill level (-100 to 100).
    DIM Operator, Creator and Manager.
    The individual’s skill level should intersect where the first and third types come together. The skill level incates how close the roles are to each other.
    It doesn’t matter what tools or paradyms you are using; the test is if you know when and how to do so (indicated by the skill level measure).
    You then take your measure; where you are on the intersection map, how close you are to either end of each scale (and the associated tool/method involved).
    The tool/method can be broken down using the the same mapping method. This allows you to control how detailed your view is.
    The scale can show you as much details as needed. Such values range from the highest leve,l ie. you have great expertise in all tools/methods, to the lowest ie. you are not even aware of any existing tools/methods.
    The mapping can verify your knowledge of what tools/methods that you have mearly heard exist to the ones you work with on a daily basis.
    And there you have the process defined :)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>