What Level Programmer Are You? (Guest Post)
This article was originally posted by Daniel Markham at What To Fix blog.
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 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.
* The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, Jelastic or its technology and distribution partners.