7 Ranks of Coderhood: Coder, Programmer, Computer Scientist, Developer, Engineer, Architect

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:

Engineering Level	Martial Art Level (Belt Color)	Example of Job Title
Beginner	White
Hacker	Street Fighter (No Belt)
Coder	Yellow	Jr.Dev
Programmer	Orange	Software Dev
Computer Scientist	Green	Software Dev
Software Developer	Blue	Sr. Software Dev
Software Engineer	Brown	Principal Dev
Software Architect	Black	Software Architect

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!

Comments

[Ben Halpern]

I've been reading CoderHood as Coder Hood, as in Coder Neighborhood. But now I feel like it's supposed to be more like livelihood or knighthood, right? If that's the case it may be worth making the H lowercase.

[Lorenzo Pasqualis]

That is correct, and you have a good point. I'll need to think about it. Changing it would be a major pain, but probably worth it... Thank you.

[Jess Lee]

for what its worth, I always thought CoderHood was related to knighthood and think the lowercase h would actually make it seem more like Code Neighborhood. 🙃

[Ben Halpern]

[Lorenzo Pasqualis]

Ha! I like this interpretation better, Jess! :) :) I think I will (conveniently) follow your instincts ;)

[Ben Halpern]

Probably that big a deal, but yeah, I think it could help. The most important thing is the content. XKCD has gotten along just fine without getting trivial naming details just right. 😄

[K]

I watched Black Dynamite lateley so I was thiking about the neighborhood.

But while I read A Song of Ice And Fire I probably would have thought about knighthood.

[Lorenzo Pasqualis]

LOL. This discussion reminds me of this quote:

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton.

:)

[K]

Seeing these "levels" I feel I have a bit of every part, but nothing really "full"

I studied CS, but my focus was on usability, and programming techniques and not complexity theory.

I worked as a dev for 10 years now and did a bit of everything while focusing on UIs.

Often I ask myself, how can I grow as a dev and deliver more value, but I find it hard to find and adress problems in my skillset. Often I simply learn a new technology to tell myself "I got better"

[Lorenzo Pasqualis]

Yeah, I can see that. Despite my attempt and dissertation about classifying "ranks linearly," I fully realize that reality, in practice, is a multi-dimensional beast and things are never that simple.

Thank you for taking the time to read!!

[David J Eddy]

Love the article! I have had a similar discussion with a number of other professionals over the years. If now there was a was to empirically demonstrate a person a strengths and knowledge in order to progress through the ladder...properly and not game the system.

[Lorenzo Pasqualis]

Thank you, David! I think that results (not effort) are what demonstrate strength. Unfortunately, it takes time, but I have not found a better proxy.

[Jason C. McDonald]

The levels look interesting! I like how you separated the levels of proficiency. This really is a field where we continually improve, and I think the comparison to marshal arts is apt.

However, I take some umbrage with the titles. "Computer scientist", "software engineer", "software architect," and similar suggest that this is a scientific, engineering-based field...and it really isn't.

Building code is nothing like building bridges, and every rule of computer programming is technically one of our own invention. Math and physics affects it, much in the same way math affects music and color science affects painting, but math and physics do not define programming like it does any scientific field. (See The Cake Is A Lie for more detail.)

Meanwhile, hacker is actually tricker territory than I think your article realizes. Removing the illegitimate, media-fueled uses of the word, a Hacker is truly the most skilled of coders. We aren't just come up with kludgy solutions. True "Hackers" write the most efficient algorithms, the cleanest code, and the best functioning software. We come up with unusual solutions, true, but those solutions are elegant, not kludgy. Eric S. Raymond, Linus Torvalds, Alan Kay, Guido Van Rossum, Bjarne Stroustup - these gentlemen are Alpha Hackers, having truly earned the title.

According to hacker culture rules, you cannot even call yourself a Hacker until a Hacker calls you one first. I only recently earned that distinction myself.

Honestly, a Hacker can appear anywhere in this spectrum. I agree we're something of a "street fighter" type - we follow our own credo, and not that of the Big Organized Groups. You can be a Hacker in infosec ("white hat"), in programming, in computer engineering, and in many other branches of the computer industry, but you are either a member of Hacker Culture who has earned the title, or you are not. All others who claim the title are imposters.

[Lorenzo Pasqualis]

Thank you for your note. However, I am going to respectfully disagree with some of what you said.

Math is made-up by humans, and so is physics. We invented theories and rules to describe and model reality, but math is not "reality," it is only a tool to describe it. Physics is the same thing, a set of rules to describe, study and make sense what we experience.

Many "laws of physics" break down when you change the conditions (like at the sub-atomical level or speed of light), clearly showing how little we know and how those are only approximations.

Computer science is the same thing. It is a set of models to and theorems used to describe characteristics of problems that affect real life. In other words, computer science is a science as much as Math and Physics are sciences.

[Jason C. McDonald]

Well, no, I would not be able to agree at all. Don't confuse the fact that we don't fully grasp math and physics with the idea that they're somehow theoretical, fluid concepts.

Gravity works. It will always work. We can't stop it from working. We just haven't fully comprehended or described how it works.
Similarly, 2+2=4. For all time, those quantities add up in that way, and it is literally impossible to get anything else out of it. You can change the names on the quantities, describe the problem differently, but the principle that addition and the quantities describe is real, has always been, and will always be.

You only described how our understanding of the laws changes and breaks down. The laws themselves are beyond our present grasp, but they're there, complete and unbreakable.

By contrast, we invented every rule of computer science. We decided to use binary for storage (granted, it was the most efficient, but there are other working systems). We wrote assembly code. We decided what instructions a CPU could process. We designed the behaviors and specifications of every single language. The rules, flaws, foibles, and factors of programming are entirely the result of one human-created design piled on top of another.
Thus, it is more akin to an art, such as music or painting, than to building a bridge.

In fact, I'd venture that you'll have a very hard time finding any Founding Fathers of Modern Programming who would equate software to engineering. By way of example, Donald Knuth, Eric Raymond, Alan Kay, Gerald Weinberg, and Fred Brooks have all made these observations before. Programming isn't a science. Trying to cram it into that box is what keeps getting us into trouble.

[Lorenzo Pasqualis]

The vast majority of computer science theory doesn't have much to do with physical computer hardware and programming. A lot of it is the study of problems and algorithms, which is much closer to math than to computers. In other words, it is a theoretical science that can be applied to real problems. That is very all similar to Math and Physics.
You are right that Programming isn't a science, but Computer Science is absolutely a science.
Confusing computer science with programming is similar to confusing math with woodworking.

[Jason C. McDonald]

Well, and I think we can agree there. The trick is, when 99% of people say "computer science," they mean "programming," and that gets really tricky, because it's wrong.

So, in general, I avoid the term "computer science", and separate things out - programming, computer engineering (a branch of engineering, definitely a science), and...whatever you call algorithmic mathematics. (Dangit, I'm two mugs of coffee shy of remembering what you call that.)

Incidentally, "computer science" was itself coined by the ACM with the intention of approaching computer programming as a science, centuries after mathematics first began studying algorithms.

But, bringing the point back around, software architect and software engineering, as well as "computer science" in the context of programming, are...definite misnomers.

[Lorenzo Pasqualis]

I covered this in the post, but software engineering is not just about programming. Software architecture is also not just about programming. Programming is part of it, but it is not the same thing.

The terms describe exactly what they describe, and that is not programming.

That's why, in my view, they are levels on a path, like belts in a martial art.

What a black belt can do and understands is not the same as what a yellow belt studies. It is not "more of the same", it is "more and different."

Many people who code can't architect systems. Many people who code also cannot engineer systems. The confusion stems from using programming and those other terms interchangeably. The entire premise of the post is to differentiate between the terms, which mean different things and describe different levels on a path.

[Jason C. McDonald]

To be honest, I hadn't caught that the first time around, but I can see now that's the point your making. And, once again, I would have to disagree. To place them in a continuum would somehow suggest that a programmer must become a "computer scientist" (algorithmic mathematician), and must become a software architect, etc etc, to progress in career.

Yet Donald Knuth, who is regarded as one of the greatest programmers and mathematicians in computer science history wasn't a "systems architect", and yet he was far more skilled in the computer industry than most systems architects ever will be. You'll find the same true of many other greats. Meanwhile, some of those greats do not have degrees in computer science, and quite a few people with CS degrees aren't half as skilled as many peers with no degrees.

So, in short, I'd say that to place these differing fields on the same continuum is missing the point; it's like saying that a sculptor is more advanced than a painter, and therefore a painter must become a sculptor to move up in career. Clearly, that is not the case - painting and sculpting are different, but they are in no way inferior or superior to one another.

But, if you were to stop short of blurring entirely different branches of study into one continuum, and focus purely on one's skill in software development, you'd be onto something.

[Lorenzo Pasqualis]

Programmer is before computer scientist, so no... a programmer does not have to be a computer scientist. At all. In the post I also talked about how many people stop at Programmer, and have fine careers. Sometimes great careers.

I knew that a 3000 words post would not be read completely by lots of people. Oh well.

[Jason C. McDonald]

Well, yes, I saw that part. The problem is, if we were to equate this to levels of marshal arts, the problem remains that Donald Knuth, Alan Kay, and many other true black-belts would get relegated to a lower level, below people they can code circles around. See my issue?

[Lorenzo Pasqualis]

Martial arts (not marshal).

You don't have to be a black belt in martial arts to kick a win a fight against a black belt. That is a fallacy. There are masters of martial arts in their 90's who don't have a chance against strong and much younger athletes. That's why the analogy works so well.

Lots of people become masters of their niche and don't need to progress past it to have an amazing career. Donald Knuth is a master computer scientist and programmer. I am not sure what is the point you are contending. You call that "true black belt," but what does that mean? In many schools of martial arts, if you don't study certain Katas and other things, it doesn't matter if you are a super strong fighter. To get a new belt you need to master certain skills.

Does he also possess the skills that I described for Software Engineers and Software Architects? If not, then in my book he is not a "black belt," even if he can run circles in programming and computer science theory around people who I define as architects.

Anyway, I think I described a model in the post and I also made it clear that I expect some people to disagree. I am happy to see that I was right on that one at least :)

[Jason C. McDonald]

Well, I can appreciate your perspective, even if I don't agree with it.

[David Taitingfong]

If no one has told you yet Lorenzo, we appreciate your posts here. You continue to give us quality posts, sound advice, and easy-to-understand analogies. I'm always appreciative of leaders who can share their wisdom!

[Lorenzo Pasqualis]

Thank you, David. Your note made my day!

[Don Denoncourt]

Amazing piece. Andy Hunt, in Pragmatic Thinking and Learning, covered the Dreyfus model of skills acquisition to five levels: Novice, Advanced Beginner, Competent, Proficient, and Expert. You have made great improvements over the Dreyfus model and Andy's use of it. I actually have an InfoQ article scheduled to be published where I talk, very briefly, about Dreyfus, and, when I get the article back for last edit, I'm going to add a reference to this piece.

[Lorenzo Pasqualis]

Thank you, Don. I am honored and humbled by your thoughtful note. If you do add a link from your article, please consider linking the original as it helps my SEO and it helps to spread the word about the work I am doing. Looking forward reading your article.
Ho letto nel tuo profilo che hai imparato l'Italiano. Bravissimo! Io sono nato e cresciuto a Firenze, dove ho vissuto per 26 anni. Mi fa piacere vedere che la lingua Italiana e' apprezzata e studiata.

[Don Denoncourt]

Gracie per tua risposto. Io e mio moglie amato Firenze quando noi visitato li cinque anni fa. Uno domanda per te -- Lascia conosco qualcuno siti de Italiana for tech. Mi piacerebbe a leggere buono articoli in Italiano. Io gia letto multissimo romanzi in Italiano. A proposito, I letto, (in realtà, ascolto) in Inglese, due del il libri che te ha consigliato in "11 Books All Software Engineers Must Read" in il ultimo mese.

[XXXandBEER]

Or! We can just stick to Junior/Senior/Lead titles. And not make up our own interpretations of words we act like we understand. Ie Hacking is programming... Hackathons. Engineers and Developers are entirely dependent on the company. Most Engineers I know don’t touch a lick of OOP code.

[Lorenzo Pasqualis]

About performance, you might find this is interesting:

def trace(&block)
  printf "%8s | %-10s | %-20s | %-15s\n", 'event', 'line', 'id', 'classname'
  printf "%8s-+-%-10s-+-%-20s-+-%-15s\n", '-'*8, '-'*10, '-'*20, '-'*15
  set_trace_func proc { |event, file, line, id, _, classname|
    printf "%8s | %-10d | %-20s | %-15s\n", event, line, id, classname unless ['trace','set_trace_func'].include? id.to_s
  }
  yield
  set_trace_func(nil)
end

puts "Method 1"
trace do
  [1,2,3,4,5].sum
end

puts "\n\n"
puts "Method 2"
trace do
  '1+2+3+4+5'.
      scan(/([-+\/*])?(?:\s*)(\d+)/).
      reduce(0) { |res, (op, num)| res.public_send(op || :+, num.to_i) }
end

Prints:

Method 1
   event | line       | id                   | classname      
---------+------------+----------------------+----------------
    line | 15         |                      |                
  c-call | 15         | sum                  | Array          
c-return | 15         | sum                  | Array          


Method 2
   event | line       | id                   | classname      
---------+------------+----------------------+----------------
    line | 23         |                      |                
  c-call | 22         | scan                 | String         
c-return | 22         | scan                 | String         
  c-call | 23         | reduce               | Enumerable     
  c-call | 23         | each                 | Array          
    line | 23         |                      |                
  c-call | 23         | to_i                 | String         
c-return | 23         | to_i                 | String         
  c-call | 23         | public_send          | Kernel         
  c-call | 23         | +                    | Integer        
c-return | 23         | +                    | Integer        
c-return | 23         | public_send          | Kernel         
    line | 23         |                      |                
  c-call | 23         | to_i                 | String         
c-return | 23         | to_i                 | String         
  c-call | 23         | public_send          | Kernel         
  c-call | 23         | +                    | Integer        
c-return | 23         | +                    | Integer        
c-return | 23         | public_send          | Kernel         
    line | 23         |                      |                
  c-call | 23         | to_i                 | String         
c-return | 23         | to_i                 | String         
  c-call | 23         | public_send          | Kernel         
  c-call | 23         | +                    | Integer        
c-return | 23         | +                    | Integer        
c-return | 23         | public_send          | Kernel         
    line | 23         |                      |                
  c-call | 23         | to_i                 | String         
c-return | 23         | to_i                 | String         
  c-call | 23         | public_send          | Kernel         
  c-call | 23         | +                    | Integer        
c-return | 23         | +                    | Integer        
c-return | 23         | public_send          | Kernel         
    line | 23         |                      |                
  c-call | 23         | to_i                 | String         
c-return | 23         | to_i                 | String         
  c-call | 23         | public_send          | Kernel         
  c-call | 23         | +                    | Integer        
c-return | 23         | +                    | Integer        
c-return | 23         | public_send          | Kernel         
c-return | 23         | each                 | Array          
c-return | 23         | reduce               | Enumerable     

[Justin Lam]

This reminds me of how Riot Games organizes their title bands.

engineering.riotgames.com/news/deb...

engineering.riotgames.com/news/deb...

Just FYI. Thanks for the article! Would love to see your perspective on their categorization.

[Lorenzo Pasqualis]

Thank you! I'll need to take a peek.

[Lorenzo Pasqualis]

As long as it is clear what problem it resolves and the tradeoffs. For example:

• it resolves the original problem, but it is very slow at doing so.
• it is a solution for a class of related problems.
• it does not resolve a general expression problem. For example, if 1+2*3.5-4+5 is to be interpreted as an expression, the correct result is not 10, so the code doesn't solve that problem. (The correct result is 9.)