Let’s start at the Beginning and define a Software Maker. FYI, I routinely switch back and forth between the terms Software Maker and Software Ninja.
On this site, you can safely assume that they mean the exact same thing: someone who gives instructions to a computer via a formal programming language in an attempt to get the computer to perform specific, custom behavior.
The purpose of this writing is to answer the question: “What can an employer reasonably expect from someone who is touting themselves to be a professional software maker?”
Is there a difference between a programmer, a developer, a software engineer, a computer scientist, and a software architect? Or are all of these terms synonyms for each other?
Rather than get involved with all of that bickering back and forth, I have devised my own system that I use when describing the degrees of quality (value to an organization) between those that provide a hands-on contribution to making software. Below I describe the Terence McGhee Software Maker Class Hierarchy.
These are the separations of skill between software makers that I’ve observed over the last 25 years. I’ve found these distinctions to be accurate and surprisingly repeatable throughout the industry. By that I mean that you’ll see these classes everywhere software is created professionally. Further, I find that my confidence in the lines that I’ve drawn grow stronger and stronger every day.
This person knows the syntax for at least one programming language and that’s about it. He uses this knowledge to bang out solutions to the things he’s trying to solve and what he produces is extremely low quality, even though it does (eventually) work. This is the starting point for every software maker out there. This is the base class for us all, if you will.
Code created by a Chump Coder will almost certainly suffer from one or or more of the four plagues. So, even though your Chump Coders can get something to work and can bring a product to market, it’ll be very difficult for that software to keep up with the changing needs of the the users.
Most Chump Coders don’t even realize the mistakes they’re making or just how poor their code is. Sure they’ll be aware of when they’re “hacking” versus implementing proper solutions but that’s not what I’m talking about. I mean, literally, that a Chump Coder will have no idea of the concepts behind what constitutes a healthy software system. All they know is a language and how to bang out solutions using that language.
Battlecry: Just make it work baby. I have the power!
You would generally want to hire a Chump Coder when either or all of the following are true
It’s normal to have a few Chump Coders around. Everyone has to start somewhere, but no one has to remain a Chump Coder. A Chump Coder with a good attitude can be a very valuable resource.
It should be noted that many a profitable product has been brought to market using only Chump Coders.
Be very careful not to get the impression that Chump Coders aren’t smart. Quite the opposite is usually true. Chump Coders are very smart and very intelligent. These are not stupid people. They just haven’t accepted and learned the many disciplines required to build healthy software systems.
I would not hire a Chump Coder with a bad attitude, because it will be very difficult to get them to the next level. The end result being that you’re stuck with a Chump Coder who can only make very limited contributions to your company.
An Algorithmer is composed of two parts. Special knowledge and Chump Coder. This person is really good at developing algorithms (in the form of formulas) from scratch using their special knowledge to solve specific problems. This special knowledge is usually higher mathematics but can also be a deep understanding of the particulars of some specific problem domain.
The Algorithmer can translate that understanding into formulas and then those formulas into code. For example, an Algorithmer understands the math to render a point in simulated 3D space on a 2D screen. She uses this knowledge to then create a formula (or set of formulas) to render said point(s). She then is able to code those formulas in the software and the result will be a working 3D rendering engine. Contrast this with a say a math professor who doesn’t know how to code. The fact that he is a math savant and can describe the steps required is not enough. If he cannot actually create the code, then he just has one of the requirements. It takes both abilities to be an Algorithmer. An Algorithmer is one who can devise the algorithm and write the code to implement it.
Note: it is expected that these algorithms will be highly performant. Also note that even though technically every set of instructions given to a computer is an algorithm, that’s not the context in which I’m defining the algorithms produced by an Algorithmer. These are considered to be more advanced, highly performant, and rely heavily on math or some problem domain specifics. Further, the formulas and ideas exposed by the algorithm have value even if they never actually make it into software. Of equal importance is that this person is a subject-matter expert first (and primarily) and a software maker second.
Also please note that the Algorithmer is just a special kind of Chump Coder. This class is not a higher rank.
Battlecry: I’ll show them. I’ll show them all!
I stress that in order to optimize success, your Algorithmer must be part of a well-rounded team that can work with him to produce the quality software system that your company needs.
I would not hire an Algorithmer with a bad attitude for the same reasons I wouldn’t hire a Chump Coder with a bad attitude. It’s even worse with an Algorithmer because they’ll usually already think they know everything so it’s even harder to get them to the next level. It can also be difficult for the team to build the software correctly because the bad-attitude-having Algorithmer can be insistent on littering the codebase with trashy code.
Even though this sounds like a really high rank, in reality, this person is only slightly higher than the Chump Coder. What separates him from his Chump counterpart is that he is an expert (or near expert) at the programming language he has chosen. He can tell you exactly what the compiler will do in most situations (assuming a compiled language) and can pretty easily recite back to you verbatim the specifics of a given language feature. He can also easily understand the syntax for a line of code, even if it’s a feature he hasn’t used before. Because of this deep knowledge of his chosen language, he appears to be more advanced than he actually is. The code he produces is still really bad, even though it may take advantage of many language features.
Battlecry: I think my chosen language is a great solution for this problem. For every problem!
From an employer’s point of view, you’d hire this person for the same reasons that you’d hire a Chump Coder. They’re really no different in what they can contribute to your software.
They do have a slight edge over their Chump Coder colleagues in that they’ll do less searching on the Internets to get a line of code correct. This could potentially lead to features being delivered faster.
They are handy references for the rest of your team. They may be able to help even the more advanced members of your team with a particular language feature or syntax here and there.
Note that it may be more difficult to get a Specialist (even with a good attitude) to the next level than it is to get a normal Chump Coder to the next level because the Specialist can potentially have an unfounded sense of superiority. So much so that he won’t think he needs to advance because his deep understanding of his language will deceive him into thinking he has a deep understanding of programming overall. He most likely hasn’t learned that the programming language is actually the tiniest part of building maintainable systems.
And of course, I would not hire a Specialist with a bad attitude for the same reasons that I wouldn’t hire a Chump Coder with a bad attitude.
This is the same as a Chump Coder, but he knows more than one programming language. This is unfortunate as it means that he spreads his trash code and poor technique around.
There’s also a high chance that the Expanded Chump is a really, really nice person. The Expanded Chump usually does a great job of trying to add value wherever he can. His goals are noble, even though his programming sucks ass. Please pay attention to the distinction between terrible programming habits and a terrible person. The person != the code they write.
Battlecry: What language u wanna use? Just lemme know and I can make it work!
Again, an employer would hire this person for all of the same reasons that you’d hire a Chump Coder.
Always keep in mind though, that these contributions must be very constrained or the overall health of your system will suffer.
This is the first step on the path to greatness and this person is many levels above the Chump Coder, the Specialist, the Expanded Chump, and the Algorithmer.
The defining attribute of an Initiate is that she is very passionate about making her code maintainable.
The primary way that she accomplishes this is a heavy focus on readability. She has learned that being able to easily read the code is far more important than being able to easily write it. Because of this, she goes out of her way to learn and follow all of the guidelines regarding readability.
Another characteristic of the Initiate, is that she is probably familiar with more than one programming language, although this is not a strict requirement.
Battlecry: Make reading the code easier, even if it means that writing the code is harder.
This is probably the ideal class level with which to build a core programming team because the Initiate understands that she needs to make her code easy to read and change.
She is an enormous boon to your team’s productivity and ability to quickly respond to change.
The lower level members of your team indirectly learn a lot about readability from an Initiate just by interacting with the code she writes.
You should hire this person if you have any desire at all to put together a staff that builds successful software.
It’s difficult for me to imagine an Initiate with a bad attitude. The core attribute of the Initiate is that she is firmly planted in the understanding that her primary role is to make her code readable and approachable by all and as such, she doesn’t have the hang-ups and attitude problems of the lower levels.
The reason the Initiate is ideal for any team is because they can make immediate contributions, are already team players, and their salary expectations aren’t likely to be as elevated as the higher level classes.
This is the next level beyond the Initiate. Everything done by a Codesmith is to maximize maintainability.
The difference between the Initiate and the Codesmith is that the Codesmith understands that in order to achieve true maintainability, there must be a heavy focus on software architecture and design in addition to readability. She understands that readability is only the first step towards her ultimate goal and she has graduated into more advanced disciplines to keep the software soft.
The Codesmith just “gets” system building and its many paradigms and is definitely proficient in more than one programming language and in more than one paradigm. She can apply sound software-creation techniques to any language she chooses to work in.
The Codesmith is well versed with design patterns, TDD, S.O.L.I.D, CQS, OOP, Information Hiding, the Law of Demeter, the Four Rules of Simple Design, and hexagonal/decoupled architectures. Just to name a few.
None, I repeat, none of these skills are acquired by being self taught. You need to learn these from an Adept or hopefully even a Guru. It takes years to get a firm grasp on these techniques and approaches.
However, once you begin successfully applying these concepts to real software, you have reached the status of Codesmith. You don’t have to have mastered them all, but you have a firm working knowledge of all of them and actively practice all of them.
Just to be clear, knowing about or having heard about these disciplines doesn’t make you a Codesmith. However, consistently applying them successfully in real software does.
You are a Codesmith when you actively apply the disciplines as a matter of course. When it’s instinctive and automatic. You don’t have to think about it, you just do it.
There are at least two Codesmith levels.
This person applies the disciplines consistently and successfully, but could do better. For example, the software he creates may still have some opportunities for refactoring into patterns or maybe a few missing abstractions here and there. Maybe some classes and methods could be closed that are still open, etc.
He will have a good grip on the core design patterns, but may need to improve in some of the more obscure ones. None of his code will be in strict violation but maybe his system could be improved upon slightly by a Level 2 Codesmith or higher.
However, one thing is for certain: all of it will be highly maintainable and easy to modify.
Code written by her is spot on compliant and any additional changes that can be made for conformance are purely aesthetic and a matter of personal preference.
Reusable components are a must for her. She doesn’t write a login screen 50 times. She writes it once and reuses the same one over and over. When I say reuse, I don’t mean copying the code and changing a few names. I mean reusing the actual binaries without modification. Of course, this assumes a compiled language, but you get the point.
Battlecry: I must fight the good fight to keep the software soft.
Simply put, you need at least one Codesmith on your team and hopefully you can find one. The benefits that a Codesmith brings to the success of your software are staggering. There really is a night and day difference between a system that was built with the leading of a Codesmith versus one without. Even a team of Initiates, who produce really great and readable code by the way, cannot compare.
You want maximum profitability of your software.
You want to be able to respond to change quickly.
You want to develop other team members in the proper building of healthy software.
In the end, I would not hire a Codesmith with a bad attitude, although I’d be highly tempted. Even though the code produced would undeniably be outstanding, one of the main benefits of having a Codesmith on your team is his ability to mentor and guide others. If you’re not able to get this component out of your Codesmith because of his bad attitude, he’s probably doing more harm than good.
Given that a Codesmith is available, and given that her attitude is correct, and given that you can afford her, you’d be a fool not to hire a bona fide Codesmith.
The Adept is the next level beyond the Codesmith. This is where you start to merge together the traditional notions of what a software maker needed to know and what the last 30 years of actual development has taught us instead.
You have in this one class all of the system building skill of the Codesmith plus a healthy amount of computer science. This includes the more traditional notions of higher mathematics, algorithm analysis, engineering, binary manipulation, hex, most certainly a healthy dose of assembly, and a love for the command line.
The Adept is very disciplined, highly principled, and has a strong scientific/engineering component. The Adept simply cannot be coaxed into creating software in a way that does not have maximum maintainability and efficiency built into it. It’s not optional, it just comes naturally with everything she does.
The Adept is really good at solving new problems. She is also really good at solving complex problems that have nothing to do with system architecture and design. The Adept can discover and implement new things.
Battlecry: With great power comes great responsibility
If you thought a Codesmith was hard to find, you’ll go mad with frustration trying to find an Adept. If you are blessed enough to find one, you’d better jump at the opportunity and concede instantly to all of her salary demands. Don’t dork around here and lose your opportunity to staff your team with an Adept.
All of the dangers of hiring a Codesmith are still present when hiring an Adept.
Even if the Adept has a bad attitude, I’d still probably hire him. This is about as good as it gets.
The guru, simply put, is the highest ranking software maker there is. Not only does she know everything the Adept knows, but there’s a good chance that she discovered and popularized many of the disciplines that the Adept has mastered.
If I had to guess, I’d say that in the entire history of modern software, there have been less than 5k Gurus total.
This person is to software creation what Neo is to the Matrix… all powerful.
Some well known modern Gurus are the likes of Martin Fowler, Kent Beck, Robert C. Martin, Ron Jeffries, and Ward Cunningham.
When you mention software maker royalty, start and stop with the Gurus.
Battlecry: The power and might of creation has arrived
Authority - this person is a slight variation on the Algorithmer. The difference being that he acquired his domain-specific knowledge by programming in the same field for a long time. Their expertise was learned on the job. The pure Algorithmer knows what he knows outside of any programming jobs.
It’s no guarantee that the Authority’s skill level is that of a Chump Coder though. He may have graduated all the way up to Codesmith or higher. An employer is usually interested in this class of software maker when they have specific domains that they need to staff.
The Chump Coder is not synonymous with a beginner. Even though a beginner can be a Chump Coder, you can find Chump Coders with many, many years of experience. I was a Chump Coder for probably 10 years before I saw the light.
Yes it’s possible that a Specialist can know more about a particular language than even a Guru. Even so, having that special knowledge doesn’t even come close to putting him in the same league with the Guru.
Most employers tend to ask programming language questions during the interview process rather than system building questions. This is unfortunate, because none of this speaks to the prospect’s ability to create maintainable software.
I purposely used the term profitable over the term successful when describing the contributions of the Chump Coder.