I'm sure some of you have come across this before. It is yet another ranking system for programmers.
Let's have a look at some of the rankings:
Intersting, no?
For the most part, I agree with this list. In general, as you progress up the list from level 0 (called 'n^2') to level 3 (called 'log(n)') you tend to move upwards in programming skill.
The problem I have with this matrix, what I consider its failure, is its lack of context. Yes, it's great to know that if you understand the concept of Concurrent programming languages, you're a level 3 programmer, but does anyone reading this list know what that means?
I'll tell you what it means: it means you understand Concurrent programming languages. Nothing more, nothing less. Yet to anyone reading this chart, you'd think we programmers get together and rank ourselves based on this. Admittedly, I'm new to the field of software engineering, but I've yet to see anyone who openly considered themselves better than anyone else because they are a level 3 programmer on some chart.
Even worse, this chart (like almost any way to lump people together in an arbitrary manner) is open to misuse and misapplication. Suppose a hiring manager got their hands on this, and decided that they don't just need any programmer for their new app, they need a LEVEL 3 programmer.
They work for months to find him, weeding out hundreds of candidates who just don't measure up. Sure, they might have ten years of professional experience and have written their own frameworks, but their blog is just a LINK BLOG. Such a fine gentleman is obviously NOT a level 3 programmer.
Once they find this elusive beast, the level 3 programmer, they hire him, and damn the cost! Two weeks later, he's bored out of his mind with adding buttons to the dinky little windows app to count widgets in a warehouse, and is wondering why he ever took the job.
A chart like this relies on two things to be properly used: a common set of standards with roughly equal weight, and the knowledge of a viewer of what the levels actually mean.
In my example above, the company didn't need a level 3 programmer, as defined by this chart. They probably only needed a level 1 or maybe a level 2. But how were they supposed to know? No context is given. There's nothing here that says, "a level 1 programmer is likely competent and capable of learning, and can handle most common tasks" or "a level 0 programmer is still learning, and could improve if given training and time". It's a hard, fast, limit: Quality X indicates Ability level Y.
In addition, there is a gross disparity between what makes up the differences in levels. Take for example, scripting. At level 1, you can make batch files and use basic tools. At level 2 you use a large number of scripting languages. At level 3, you have "written and published reusable code". This is one of the less useful metrics I've seen in recent times. The difference between levels 2 and 3 is minor and not even related to the topic! Publishing, in and of itself, means nothing. If I write a script that automates building and deploying a widget, or even generalize it to build and deploy any widget given some parameters, what difference does it make if I publish the code? How does it make a difference to my ability to script if I have posted my scripts for reuse? How does it limit my ability if I don't?
Consider the database section of the matrix, levels 2 and 3.
So...the ability to DESIGN a normalized database schema is a lesser ability than basic administration? Understanding basic concepts of databases and their administration is (IMHO) much simpler than designing a good database structure. Knowing how a two-phase commit works is far less difficult than being proficient in ORM.
The concepts of database design, database usage, and database administration are complex and disparate...yet here they are all lumped together, seemingly in no order.
And don't even get me started about the 'Years of Experience' myth. Coding Horror has done it. Far better than I could.
I could go on, but I think I've made my point. Pigeonholing people into arbitrary categories is a substitute for understanding.
Let's have a look at some of the rankings:
| data structures: | |
| Level 0: | Doesn't know the difference between Array and LinkedList |
| Level 1: | Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks |
| Level 2: | Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc. |
| Level 3: | Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc. |
Intersting, no?
For the most part, I agree with this list. In general, as you progress up the list from level 0 (called 'n^2') to level 3 (called 'log(n)') you tend to move upwards in programming skill.
The problem I have with this matrix, what I consider its failure, is its lack of context. Yes, it's great to know that if you understand the concept of Concurrent programming languages, you're a level 3 programmer, but does anyone reading this list know what that means?
I'll tell you what it means: it means you understand Concurrent programming languages. Nothing more, nothing less. Yet to anyone reading this chart, you'd think we programmers get together and rank ourselves based on this. Admittedly, I'm new to the field of software engineering, but I've yet to see anyone who openly considered themselves better than anyone else because they are a level 3 programmer on some chart.
Even worse, this chart (like almost any way to lump people together in an arbitrary manner) is open to misuse and misapplication. Suppose a hiring manager got their hands on this, and decided that they don't just need any programmer for their new app, they need a LEVEL 3 programmer.
They work for months to find him, weeding out hundreds of candidates who just don't measure up. Sure, they might have ten years of professional experience and have written their own frameworks, but their blog is just a LINK BLOG. Such a fine gentleman is obviously NOT a level 3 programmer.
Once they find this elusive beast, the level 3 programmer, they hire him, and damn the cost! Two weeks later, he's bored out of his mind with adding buttons to the dinky little windows app to count widgets in a warehouse, and is wondering why he ever took the job.
A chart like this relies on two things to be properly used: a common set of standards with roughly equal weight, and the knowledge of a viewer of what the levels actually mean.
In my example above, the company didn't need a level 3 programmer, as defined by this chart. They probably only needed a level 1 or maybe a level 2. But how were they supposed to know? No context is given. There's nothing here that says, "a level 1 programmer is likely competent and capable of learning, and can handle most common tasks" or "a level 0 programmer is still learning, and could improve if given training and time". It's a hard, fast, limit: Quality X indicates Ability level Y.
In addition, there is a gross disparity between what makes up the differences in levels. Take for example, scripting. At level 1, you can make batch files and use basic tools. At level 2 you use a large number of scripting languages. At level 3, you have "written and published reusable code". This is one of the less useful metrics I've seen in recent times. The difference between levels 2 and 3 is minor and not even related to the topic! Publishing, in and of itself, means nothing. If I write a script that automates building and deploying a widget, or even generalize it to build and deploy any widget given some parameters, what difference does it make if I publish the code? How does it make a difference to my ability to script if I have posted my scripts for reuse? How does it limit my ability if I don't?
Consider the database section of the matrix, levels 2 and 3.
| Level2 | Able to design good and normalized database schemas keeping in mind the queries that'll have to be run, proficient in use of views, stored procedures, triggers and user defined types. Knows difference between clustered and non-clustered indexes. Proficient in use of ORM tools. |
| Level 3 | Can do basic database administration, performance optimization, index optimization, write advanced select queries, able to replace cursor usage with relational sql, understands how data is stored internally, understands how indexes are stored internally, understands how databases can be mirrored, replicated etc. Understands how the two phase commit works. |
So...the ability to DESIGN a normalized database schema is a lesser ability than basic administration? Understanding basic concepts of databases and their administration is (IMHO) much simpler than designing a good database structure. Knowing how a two-phase commit works is far less difficult than being proficient in ORM.
The concepts of database design, database usage, and database administration are complex and disparate...yet here they are all lumped together, seemingly in no order.
And don't even get me started about the 'Years of Experience' myth. Coding Horror has done it. Far better than I could.
I could go on, but I think I've made my point. Pigeonholing people into arbitrary categories is a substitute for understanding.
