This post was first published on CoderHood as 7 Ranks of Coderhood: Coder, Programmer, Computer Scientist, Developer, Engineer, Architect. CoderHood is a blog dedicated to the human dimension of software engineering.

The Many Names of a Software Builder

In my blog, I have been using the terms coder, programmer, software developer and software engineer interchangeably. I do that mainly to avoid linguistic repetitions. However, I believe that there are differences between those words and similar others.

In this article, I will discuss a set of nouns commonly used to refer to someone who writes code. I will also give my interpretation of how those terms relate to engineering skill levels.

Interpretation of the meaning

The definitions that I will present here are not official. There are no formal definitions that I am aware of or trusted body to create such a thing. However, there are lots people with strong opinions on the matter. My understanding of what each of the terms implies is based on three decades spent in the software industry, but I fully expect that other people will disagree with my interpretation.

My intent is not to start a debate or attempt to convince anyone who may have a strong opinion. I do not believe that there is a right or wrong at this time. However, if you have not yet formed a strong opinion on the matter, I hope that this guide will provide some clarity on a possible interpretation.

A three-pronged approach

For the sake of clarity, for each of the nouns I will do three things:

#1 - Give a Description of the Skill Level

I will provide a description of the skill level that, in my interpretation, is implied by the term.

#2 - Provide a Parallel With Martial Arts Ranks

I will make an analogy with martial arts ranks. In particular, I will equate the technical software-making skill level implied by the term with martial arts belt colors.

#3 - Give a Code Example

I will provide an example of how I expect that somebody at that level would choose to approach a simple programming problem. The definition that I will use is trivial and not intended to be a realistic example. Its purpose is to compare and discuss skill levels. The simplicity is designed to allow anyone, regardless of experience, to easily follow along. The problem that I will use is:

Calculate the sum of a set of integers.

As you are reading my dissertation, please play along and imagine this as a proxy for a much more complicated case. In this make-belief universe, this task requires serious thought and has many potential solutions and design approaches. Imagine it to be a central piece of computation for a system that needs to scale and perform.

I will use Ruby to show some trivial examples of implementation; the code is simple enough that it should be understandable even if you don't know Ruby. If you don't understand it, don't worry.

The List

The nouns that I will be discussing are:

• Beginner.
• Coder.
• (Hacker)
• Programmer.
• Computer scientist.
• Software developer.
• Software engineer.
• Software architect.

Ready to follow along? Let's get started.

Martial Arts Belts

When I was living in Italy in my teens and twenties - about 40lbs ago - I spent years practicing Judo and Kung Fu. During that time I learned that in many martial arts, the color of the belt is a symbol of the skill level of the practitioner. A typical color pattern goes from white to black, where the darkness is proportional to the experience level.

A beginner wears a white belt because they have no experience. The color white indicates "new and clean." As the martial artist trains, the belt gets darker to show progress. The color represents the grime accumulated with hard work and sweat. A martial artist with many years of experience eventually achieves a black belt rank to indicate high levels of expertise and skill.

Traditionally belts were black or white only. In recent decades things have evolved to include more colors. Today, different martial arts schools have different belt color schemas. The schema depends on the style, the dojo, and the country.

Why Am I Talking About Martial Arts?

I will use martial arts belt colors to draw a parallel between software building skills of a software professional and the fighting skills of a martial artist. For this purpose, I will use a belt color schema commonly used in Europe. In order: white, yellow, orange, green, blue, brown and black.

The following table shows the engineering levels that I mentioned. For each of them, the table shows a corresponding belt color and a title that is commonly given to someone at that skill level:

The engineering skill level is related to the technical and teamwork abilities of the developer. The job title is an example of what the industry calls someone at that level (heavily dependent on the company and geographic area).

Beginner - White Belt

You have to start somewhere, and that is usually "no experience at all." A beginner in software development is just that: someone who is new to coding and is in the early stages of learning. Beginners cannot yet reliably write or understand simple functioning programs without consulting books, tutorials, cookbooks, or getting help from somebody.

Beginners might be able to write working code, but they often do not understand the details of why that code works. They commonly spend a lot of time searching for code snippets on StackOverflow or similar sites and stitching them together until something functions.

Powerful tools are not the same as robust skills

To make things more confusing, many "modern" languages and frameworks allow anyone to generate the structure and some of the implementation of complex programs without the need to understand what's going on behind the scenes. For example, getting a simple Ruby on Rails application up and running and accepting HTTP requests is something that anybody can do with a few command-line commands and a tiny bit of determination.

Here is how you do it on a *nix system:

$ gem install rails
...
$ rails new website
...
$ cd website
$ bin/rails server
...

Done! That is all you need to get a server responding to HTTP requests generated by a web browser. If this were a martial art fight, it would be the equivalent of showing up with an armor and a gun. The armor might allow you to survive a little longer, and with the gun, you might win the match. However, winning a fight that way doesn't make you a skilled martial artist. It just gives you tools to do something challenging without traditional training, effort or study.

Don't take me wrong. Tools like Ruby on Rails that allow a developer to get things done fast are great. In fact, I think that cutting down the time spent on any boiler-plate code is fantastic. It is an excellent start of a project, but it only requires the skill level of a white belt.

The real fight starts when the tutorial ends and when tools do not automatically generate the application you are trying to implement. To move past that point, you need to become a coder.

An example

If a beginner wanted to write a program that sums a set of numbers using Ruby, they might Google "How to sum array of numbers in Ruby?", and find this page. That's the first Google result at the time of the writing of this post. That page gives the following most voted answer, which got 524 upvotes on StackOverflow:

array.inject(0){|sum,x| sum + x }

And sure enough it works. Here is an example:

$ irb
2.4.2 :001 > array=[1,2,3]
 => [1, 2, 3] 
2.4.2 :002 > array.inject(0){|sum,x| sum + x }
 => 6 

The beginner might get that to work, but they don't understand the tradeoffs of that code. Is it readable? Is it fast compared to other ways of doing the same thing? Is it maintainable? Why does it work? What exactly happens when that line gets executed? How much CPU does it use? Are the variables "sum" and "x" defined after that line of code runs?

A beginner Ruby developer is someone who does not know the answer to most of those questions.

Coder - Yellow Belt

A coder is someone who can put together many lines of computer code to resolve a range of simple problems without help. The result won't be beautiful, but a coder understands why it works and they get the job done.

The first necessary step

I called my blog "CoderHood" because every person who writes code for living reached a "coder" level at some point. Coderhood is a word I made up to indicates a developer's life in tech, starting from that first yellow belt.

The main difference between a beginner and a coder is that a coder can write code and understand it. They might not understand what's going on behind the scenes in great details, but they do know why they wrote the code they wrote.

In the industry, the title associated with a coder is something like "jr. developer" or "developer in training."

An example

I expect a "Ruby coder" to be able to come up with and know the difference between most of the following methods of calculating the sum of an array of integers:

$ irb
2.4.2 :001 > array=[1,2,3]
 => [1, 2, 3] 
2.4.2 :002 > array.inject(0){|sum,x| sum + x }
 => 6 
2.4.2 :003 > sum=0;array.each { |x| sum+= x };sum
=> 6 
2.4.2 :004 > array.sum
=> 6 
2.4.2 :005 > array.inject(0, :+)
 => 6 
2.4.2 :006 > array.reduce(0, :+)
 => 6 
2.4.2 :007 > eval array.join '+'
=> 6 

In case you are wondering, some of those are terrible solutions, but they are working solutions nonetheless.

Hacker - Jeans And No Belt

I include "hacker" on the list because somebody will ask about it. However, it is not a great fit for this discussion.

Not a necessary skill

I don't believe that "hacking" is a necessary skill in a software developer's growth path. White-hacking skills are useful to learn how to test and secure software applications and systems, but I don't see it as a word describing an overall "skill level." I'd categorized it as something some people do and not as something that gives an indication of technical proficiency. In fact, a hacker's skill level can be all over the place. Some are amazing, while others not so much.

Since being a hacker is not a necessary stepping stone in the software development progression, in my analogy, a hacker does not wear a traditional martial arts belt. They are more an equivalent of a street fighter, wearing Jeans without a belt.

Some of them are angry thugs, others are survivalists, others are good guys defending people, and most are somewhere in between.

The many types of "hacker."

There are many types of hackers. Some of them can code, others can't. The meaning of the word depends on the context and who is using it. Some common definitions are:

1. A computer expert who adheres to the technology and programming subculture.
2. An individual who can compromise computer security for malicious (black-hat) or security research (white-hat) purposes.
3. A software developer who gets the work done in the quickest and dirtiest way possible.
4. Someone who studies, experiments with, or explores telecommunication systems, equipment, and systems connected to telephone networks. This type of hacker is also called a phreaker.
5. A skilled engineer who works very close to the metal to gain more control on a system for good reasons (i.e., to squeeze more performance out of the hardware) or malicious purposes (i.e., to exploit security holes and find ways around operating system defenses).

Some examples

Type 3

A hacker of type 3 might choose to sum an array of integers with the following "ruby code":

$ irb
2.4.2 :001 > `echo "1+2+3" | bc`.to_i
 => 6 

It works, on some systems at least, but it is a... "total hack." That's the type of thing that unskilled hackers-who-code do. They do things in dubious ways, usually executing unreadable command-line commands until they somehow get the result they want.

Type 5

Hackers of type 5 operate at very low-level and close to the metal. There is something to be said for that skill; it is not easy to acquire and can be very valuable if you are trying to secure a software system or write extremely high-performance applications. I was never what you would call a "hacker," but I started coding very close to the metal (C and Assembly) and I still consider myself a low-level developer at heart.

Type 5 hackers can be fantastic street fighters, with mad skills that would let many professional programmers in the dust on some very specialized tasks. That kind of "hacker" might choose to sum an array of integers using Assembly, like this.

Programmer - Orange Belt

A programmer is someone who can write functioning applications, understands basic algorithms and possesses some computer science rudiments. A programmer can get a product to work, even if it might not be very scalable or maintainable in the long-term. A programmer typically works well alone, and might or might not be a good team player.

The majority of developers stop at this level, especially if they don't plan on studying computer science theory. Programmers can write decent code and work in the software industry at that level for their entire career.

From an industry title standpoint, a programmer is often known with a title of "Software Engineer."

In the simple "sum of an array of integers" example, a programmer is someone who might decide to write the code this way:

#!/usr/bin/env ruby

if ARGV.size==0
  puts "Usage: "
  puts "   sum [space separated list of integers]"
else
  puts ARGV.sum{|x| x.to_i}
end

This code implements a usable command-line command to sum a list of numbers. If you invoke it without parameters, it displays a helpful usage message. Otherwise, it prints the result on standard output. Here is an example of usage:

$ sum
Usage: 
   sum [space separated list of integers]
$ sum 1 2 3
6

It is a "complete solution," it is self-documenting and is somewhat abstracted since you can call it as a command-line command.

Computer Scientist - Green Belt

A computer scientist is someone who studied Computer Science, either in school or on the job and has a good understanding of concepts such as:

• Base-N (N = 2, 10, 16)
• Binary operations
• Boolean logic
• Algorithmic complexity & big-O notation
• Data structures (arrays, linked lists, B-trees, red-black trees, queues, stacks, hash tables, heaps, sets, graphs)
• Sorting algorithms, and when to use them.
• - Basic understanding of NP-completeness
• Basic multithreaded algorithms
• Memory management & garbage collection (just because you code in a language that takes care of memory management for you, it doesn’t mean you can get away with not understanding it)
• Pointers (you need to understand the concept at least, even if you don’t code in C or C++ ), and the difference between passing parameters by value or reference.
• OOP concepts (interfaces, inheritance, constructors, destructors, classes, objects, abstractions, encapsulation, polyphormism, etc…)
• OO design and patterns
• Recursion
• Some basic understanding of dynamic programming, greedy algorithms and amortized analysis, string matching and approximation algorithms

A computer scientist has a CS degree or has worked as a developer for many years and studied applied CS theory on the job. As you know, I don't believe that it is necessary to have a CS degree to have a successful career in software engineering.

Now, being a computer scientist alone doesn't make you a great programmer, which might seem to break the martial art analogy a little. However, it doesn't. Think it this way: even in the martial arts world, there are specialties. Some green belts are better than others at some things. The progression is non-linear. The belt color often represents a level of experience and the quantity of work that was put in the mastery of the martial art, not necessary a level of skill for every facet of it.

A computer scientist would probably code the sum of integers solution like the programmer did. However, the difference is that a computer scientist would be able to tell you immediately that the complexity of that algorithm is O(n). As mentioned, this is an elementary example, but you get the idea.

Software Developer - Blue Belt

A software developer is someone who can get larger and more complex projects done. In comparison to a programmer and a computer scientist, a software developer:

• Writes code that is cleaner, better designed, more maintainable, documented and readable.
• Writes fewer bugs.
• Works faster.
• Works better in teams, and understand the value of development processes.
• Is stronger at finding and optimizing bottlenecks of code and software systems.
• Has more experience (has been there and done that).

An example

In the simple "sum of integers" example, a software developer is someone who might choose to solve the problem by building a service that exposes a Web API. The API would take a set of integers, and return the sum.

I expect the application to be well documented and configurable, at least. It would also have tests, proper source code organization, and it would be easily maintainable by other developers.

The main application might look something like this in Ruby, using Sinatra:

require 'sinatra'
require "sinatra/config_file"

# Load the server configuration from config.yml:
config_file 'config.yml'

#
# EndPoints:
#
# /sum/n1+n2+n3+n4+...
# Return:
#     {result: [sum of n1,n2,n3,n4,...]}
#
# Example:
#    $ curl http://localhost:8080/sum/1+2+3+4
#    {"result":"10"}
#
get '/sum/:numbers' do |numbers|
    {result: numbers.split("+").collect{ |x| x.to_i}.sum}.to_json
end

A good software developer would be well aware of the many limitations of this solution compared to other ones. For example, this solution is limited to performing the sum of a set of numbers that fits in the URI; it has no explicit error checking, it interprets as zeros strings that do not start with a number, etc.

Software Engineer - Brown Belt

The difference between software developer and software engineer is arguable; I admit it fully. The two terms are typically used interchangeably. However, I am going to suggest that a software engineer is someone who has the CS knowledge of a computer scientist and a lot of experience as a Software Developer. The major differences are:

• Ability to create more scalable systems.
• Longevity of their work. Their work lasts for longer and has fewer problems.
• Fewer bugs, and better code quality.
• Ability to be a technical lead for projects and teams.
• Possesses excellent collaboration and communication skills.
• Enough software architecture skills to be able to get the job done.

In the industry, you'd find this kind of developer with titles such as "Senior Developer" or "Principal Developer."

An example

A software engineer is someone who might choose to write the "sum of integers" application by building a service and exposing an API to take a set of integers as a developer would. However, I’d expect the software engineer solution to include improvements such as:

• Result Caching.
• Abstraction of the concept from a sum to any mathematical expression passed in the request.
• Include logging, authentication, monitoring hooks, etc.

This example gets silly

As you can tell, the simplicity of the example I chose becomes problematic and even foolish. It morphs into a discussion of how to improve an already over-engineered solution for a trivial problem.

For example, managing a cache of the results of simple operations performed on a small set of numbers is most likely heavier and slower than making the calculations in the first place. It would make sense only if the set of numbers you could pass to the API were huge; but in that case, however, the list would not fit in the URI of the request.

You could move the list of numbers to the body of the request, but then it would no longer be a RESTFUL API, and the request would no longer be cacheable. At that point, you'd be tempted to change the request to be a POST, but that would make it never cacheable. Anyway, the discussion could go on and on.

The critical part

Do you see what's going on here? As the skills of a developer improve and projects become more complex, a funny thing happens. The hard choices become less and less centered on the "core code." Instead, they become more and more centered on handling the context in which the core code operates.

As a result, highly skilled software engineers spend the majority of their time refining aspects of a system such as scalability, performance, error checking, robustness, maintainability, abstraction, portability, handling of edge conditions, etc.

Also, they learn ways to work more efficiently or improve how they interface with other developers and how they plan to approach the work to minimize risks, etc. Building software becomes less about coding and more about engineering systems and solving problems.

Software Architect - Black Belt

All software developers and software engineers need to be able to design the parts of the systems and products they are going to build. A "software architect" brings that skill to a higher level, and needs to be able to make design choices on the high-level interactions of larger software systems developed by other engineers.

An example

In our example, among other things an architect might draw this diagram to guide the implementation of the service to sum a set of integers:

Muscle memory and leadership

To be able to do so effectively, a software architect must have been trained by years and years of experience in the weeds, working at all levels. That hands-on experience must have become embedded in their muscle memory. That allows an architect to make right high-level decisions without getting stuck in details.

That said, I do not believe in pure architects, that is engineers in charge of making high-level decisions full-time. Instead, I think that reliable architects need to jump in and out the details, staying at a high level when necessary, ready to dive into the code regularly and efficiently.

In martial arts a black belt teaches and mentors. I think that teaching and mentoring is also one of the functions of a software architect. The teaching I am referring to is not direct (lectures), but is more done by example, showing the way and guiding people to make their decisions.

Conclusions

Serious martial artists study their art all of their life; serious software developers do the same. I hope that you found this discussion useful. Hopefully, it gave some context to some terms that are often poorly defined and ideally it explained how to use common terms in more precise ways.

If you enjoyed this article, keep in touch!

• Find all my posts on CoderHood. Don't forget to Subscribe to receive notifications of new posts by Email.
• Join my professional network on LinkedIn.
• Follow me on Twitter.
• Join my Facebook page.
• And finally, follow me here on dev.to!