I disagree with the premise of this article. By trying to differentiate the different "programmers" by nothing other than their skill, he is ignoring the fact that you simply shouldn't group together low-level chipset programmers with PHP programmers with LABview drag-and-drop-individual-components programmers with computer scientists who also happen to be programmers. These people are fundamentally different, and trying to say that they are all the same and only differ in "programming experience" is fundamentally missing the boat on these distinctions.
I agree completely. I work on high performance C API's. Most of the code I write is as close to the silicon as possible because of that. So where am I? Not level 7, because our OO design doesn't have the performance we need.
But I've never done anything in the web space, which means I don't actually qualify for level 1.
Agreed and to expand on this, there's a big difference between the advanced architect who takes a year to build an incomprehensible framework, and the multi-paradigm programmer who solves problems efficiently.
Yeah - to put it another way, ordered, general criteria like these will rarely be fit for the purpose of selecting the best coder for a given job. They place a huge premium on showing the widest possible diversity of knowledge, whereas what makes many programmers world-class is that they offer highly specialized skills for dealing with highly specialized applications, with which they have huge experience.
I think his levels are really stupid. I can write functional & OO code somewhat well (in dozens of languages (Java, ObjC, C++, Scheme, ...) - in 3-4 of them I'm more experienced but with the help of StackOverflow can do almost anything I want, given a few hours time), read/write bash scripts, can (and do) write iOS/Mac GUI applications, can use PHP and Ajaxish things, have good experience with MongoDB/MySQL and a lot of other things. I use OS X Terminal.app regularly and have no problems doing tricks with bash (from piping to xargs'ing); But, I spent almost a whole day a few months ago and couldn't install an OpenVPN server on a linux machine. I just couldn't. I knew about IPSec, and that I must create exceptions in the ipfw for this thing to work, etc. but it wouldn't work, and I didn't have a single clue how to fix that mess. So by his test, I wouldn't even pass the first level...
You could be good at some aspects of programming and weak at other aspects. Programming is a multi-faceted art. You don't start at level 0 and move up; You learn different parts of it simultaneously.
While this article doesn't help at all to classify programmers, it's interesting in that it gives a good insight into the author's approach to computer programming.
It's a very book-oriented, "teach yourself how to program computers, then program them" way of looking at the sport. It's what I'd expect to see from a CS major who'd never programmed until he hit university, or possibly a history-major-turned -programmer who learned his trade through those big red Wrox Press books with 24 authors on the cover. My personal path never intersected this curve at all.
I (and I suspect a lot of other folks) came up the Tinker route, being given an Apple II or C64 as a kid with no games on it and needing to find the shortest route to get games written so that you could play them. Every exposure to a new technology (with a new thing that needs accomplishing) gets met with a new batch of playing around with it until it all makes sense, then on to the next thing. Windows programming, web development, database stuff, OOP, functional programming, and everything in between, but never with a plan or anything resembling any of the "stages" the author describes.
Even now, 35 years in, I can't find a place on that scale where I fit. I bet there are a lot of programmers out there in the same position.
The funny thing is not that you're wrong about me, it's how completely wrong you are. I'm self-taught, and started programming Commodore Pets under PetBasic with, woohoo, 4K of RAM and a cassette tape. Wrote my first contract program when I was 16, on an Apple II. I had written my first game a few months before that. I think I had four college-level programming classes in my early 20s. That's about it for formal training. I'm very much a tinkerer.
But you're right about the books. Being self-taught, I had to voraciously read, especially starting out. Since I ended up doing this for a living, and since everybody else had the advantage of a college degree, I felt very much under the gun: learn or starve. I read like a maniac.
I don't think people "fit" in the scale in any one spot. Different jobs require different skills. Much more interesting (to me) is if folks understand the levels and are able to work as needed in them. So far the comments look very much hit and miss, which was about what I expected.
Interesting analysis, though! I appreciate the feedback on how I sound.
DK on the subject of functional programming: “Out of the ~250 programs I wrote last year, 2-3 would have benefited from being written in a functional style.”
DK on the subject of functional programming: “With 1 or even 2 hands tied behind your back it’s hard to do anything dangerous.”
I know scientific programmers who still use FORTRAN and write incredibly fast programs in a domain that's much harder to get things correct than you think.
On one level these people are "geniuses" but many of them would be completely lost if it came to object-oriented programming or relational databases.
As for the computer scientist, he's an odd animal.
I remember a time when I got a program that did something almost magical from a guy who's a household name in machine learning and CS instruction. It turned out this program crashed before getting into main()! On close inspection the problem was that he was allocating a huge array statically that he never used! This worked OK on the 64-bit monster he was using, but would kill any 32 bit machine.
My experience is that code written by computer scientists is very rarely suitable for commercial use because computer scientists usually aren't professional programmers. They get rewarded for writing papers instead of writing programs, so a succesful endpoint for them is producing some artifacts that would demonstrate how the program would have worked if it really worked.
I don't really get this stuff. Building stuff that's considered to be hard are actually the things I learned when starting out with programming. Things like a driver, a boot loader, a compiler aren't things that are harder than any other piece of software. Of course everything gets hard when you go beyond the basic stuff, but I never got why people that program in C++ or Java (usually) tend to be so arrogant when it comes to these things. Assembly isn't hard and building an interpreter or compiler also is pretty simple. The thing that's really hard when programming is the "maintenance" stuff. Be it a web application, an operating system kernel, a compiler, video game or an IRC client. Implementing the feature itself usually isn't that hard. Fixing bug is, finding the right balance between performance and simplicity is too. Oh and progressing without breaking API or ABI compatibility.
It usually not important what paradigm you follow. I myself like languages like Perl, where I can choose what way I want to go. Also functional programming languages like Haskell are awesome for building interpreters, but really I consider Assembly to probably be the easiest language there is and everything should start with it, especially C or C++ programmers, because it will prevent you from making assumptions that are wrong and prevent stupid code.
Also looking at different languages is fun and everything that is considered hard is usually lots of fun. Haskell and Assembly are the best examples.
About research. If you don't do the same thing over and over it's always a way of researching things. Most people building awesome stuff are people connecting things that haven't been connected by now.
What I want to say in short is that I don't see how these "levels" can ever fit to anyone. Also I don't get what paradigms and well, everything thing listed fits the term "level". It's about what I thought when I had even less of an idea of what programming is about. I am still exploring stuff and am a complete beginner. I never had a serious project. I just hack (as in writing bad code) some scripts together.
Disclaimer: I know I am a bad programmer, if you can even call me one at all. I have a very idealistic view on things.
"Building stuff that's considered to be hard are actually the things I learned when starting out with programming."
Maybe it's not harder than other things on the list, but the author is saying that this order is the most common progression for programmers in his experience.
I think there should be a level "I believe I've reached a level where I can speak wisely about programming ability". Followed by the "Oh, oops. Now I see I STILL know nothing" level. ;)
Of course, the problem here is that by making that statement, you are both trying to wisely speak about programming ability while still claiming it's mostly unknown to you. Both bases effectively covered. Score! :)
It's just a blog entry with observations. I make no claim on being an expert or creating the next standard. Just throwing some ideas out. I knew this would generate a bit of a stir on HN, so I thought it would be fun. What can I say? I like putting out ideas and having people throw rocks at them. If the criticism is poor, then I know I'm on to something.
Having said all that, I think there is a level of symbols, symbol assembly, and abstraction involved, even if I did a poor job of grouping them together for this entry. Writing your own language is dealing with a problem from about 3 or 4 meta levels away. It's nothing like simple scripting. There has to be some kind of natural level involved there.
I think this might be a case where more words are worse. That is, by providing concrete examples it just gave people a bunch of stuff to complain about. Hopefully the follow-up put it in generic enough terms to be more tractable.
I'm sure those who have wrote complex scripts would probably disagree with you.
Do you know what writing complex scripts in equally complex environments entails? I sure don't, therefore it makes me sufficiently unqualified to determine "meta levels" (whatever that means) for that skill.
Unless you are deeply familiar with both, i'm not sure how you can say one is higher then the other.
I hit the "reply" button to tell you that no, no amount of "complex scripting" is as mentally challenging as developing a Turing complete language.
But maybe you mean scripts as any program? In that case, I agree that developing things like, I don't know, database engines and file systems and such are equal in complexity to developing a language.
I suppose the only caveat is that those things are usually teams -- sometimes huge teams. A language is often a 1-man or small team effort.
I personally don't like the idea of "levels", especially with programming. IMO it adds to the "I'm better then you cause I do xyz code" mindset which seems to get adopted more and more each day. It actually almost turns me off and makes me not want to participate in the community.
Perhaps that mindset is more common among those in the valley or other tech "hot" areas. But around here, Washington DC, if you know People Soft and SharePoint you can easily command a salary ~130k salary. Knowing how to write your own Ruby implementation or js library gets you pretty much nowhere.
If you increase your skill/knowledge that doesn't hinder your ability to use PeopleSoft/SharePoint. It certainly expands your options. While you can get a good salary using those technologies, eventually they will be obsolete. When that happens, we'll start to see news stories posted on some future-HN about how older IT workers are being passed up for younger, fresher IT workers and how it is a biased industry. When in fact, its just a group of people who decided that sitting in their comfort zone doing their day-to-day was good enough and when it was time to move on, they couldn't find any other jobs that fit their particular niche they'd had for the last decade(s).
Or it could just be that the younger crowd is using the tech that is popular today, therefore they are in higher demand.
10 years from now some next best thing will replace Ruby and the cycle continues..
As in my original post, the issue I have is the concept of knowing how to write your own language being considered a HIGHER skill then someone knowing Sharepoint or visual basic in depth.
Who's right is it to say that my particular skill is better or higher then yours..
Knowing how hardware works, how languages are compiled/designed, how libraries are architected. It can only increase your knowledge of [insert technology here].
I think you're confusing "Levels" with A > B (A is better than B) when in reality the point is that: A comes after B. You must first understand B, then you can move on to the next level in your path of understanding programming.
Actually I've found that in Silicon Valley, no one cares about quantifying programming levels, and care more about what you did and what you know.
When I applied for jobs on the East Coast, they all seemed to want things like GPA (even though I'd been out of school for 15+ years), and especially results from programming tests like Brainbench.
Pretty much.. But my bubble is better then your bubble! :).
FWIW I am a "programmer".
This list also doesn't take necessity into account. Is "A" programmer better then "B" programmer if "B" programmer has never had to derive their own programming language while "A" programmer had this requirement or need?
Personally I see this as a permanent cycle where I'm on different levels for different things all the time. With some languages I'm on a high level, with others on a low one. Even within languages I know very well, there are parts I didn't use that much. Same for many other things like commandline tools, frameworks, api, databases. Often enough I go down on a lower level and for example work through a beginners tutorial just to have a reason to use a few things in Ruby on Rails which I don't use often enough in everyday work. Or simply to go through the cycle of setting up a developer machine with rvm, RoR, some gems, git, github. All this more as a kind of programming kata than because there would be any need.
I am always a bit perturbed by lists such as this.
I have worked with people that would be categorized as a "script kiddie" and the work they put out is far more useful than what has been done by someone who has a doctorate in computer science.
I'd much rather employ someone who can get stuff done rather than someone who knows everything yet does next to nothing. The man driving the delivery truck is a lot more useful than the worlds best nascar driver.
My level: Some days I wonder if I am even a level 1 by this list.
My advice to you: stop taking it so seriously. It is just meant to be a metaphor for one's skills evolving from the concrete as a beginner to acquiring the ability to think more abstractly as your skills improve.
This same idea seems to crop up every month or so on HN, and it just seems like ego stoking. My friend is learning to program with a functional language. Does that automatically shoot him up to level 9?
Well it's part ego stroking and part just a normal wondering of how one stacks up to others who do the same thing. For me it's also part learning experience. For example, I know Carmack is a much better programmer than I am, but having never seen him program or his process it's hard for me to put it into concrete terms other than he's better. But what does better mean? Faster, more creative, more X? Knowing the details of better is how I can build a plan to improve.
I also liken the fascination with ranking to when I thought I was pretty fast running a 5 second 40yd dash. Of course I had read about or seen sub 5s of other people, but until I finally ran next to a D1 track athlete it was a foreign concept just how much faster he was. Once again, putting something into concrete terms helps people understand where they rank.
The levels in this article kept moving towards higher and higher levels of complexity (writing your own DSL), while in my experience, getting better at my job has resulted in writing code that's less and less complex.
I used to refactor things into inheriting models with overridable behavior, etc if it could save me from repeating myself. Now I just copy/paste code when it's appropriate, and it's way easier to maintain. Key word is appropriate.
In most programming projects, the most important thing is maintainability, and that is relative to the skill of the maintainer.
If the maintainer is going to be junior developer, then writing complex OO design is not good, even if it makes the program more concise; if the maintainer is a business developer who is not good in math, then crafting non-trivial algorithms will throw him off, even if it means shorter program; if the maintainer is smart and willing to learn, then you can do whatever.
I think it's difficult to group up knowledge like this. I read through the levels and found that I had bits and pieces from different levels, meaning the whole system sort of failed me.
Levels work in a structured environment. Programming and the learning of programming is far from structured.
I was curious about something a former boss told me. He had been a programmer before he had been a manager, and he said, "oh, you haven't written a compiler yet? When you write a compiler you graduate to a whole new level of programming."
I have learned Lisp and in that sense I have graduated to a new level, although I've still not used it enough to make macros an everyday joy. I still prefer JavaScript and I am going to learn some Ruby and some CoffeeScript.
But I have no idea what writing a compiler gets you, so if anyone wants to tell me about it, I'd love to hear.
I think the most interesting element was the idea that as you become more abstract you get a target audience of those who are less abstract. Sometimes it seems like programming (with the start-up space in particular) is a kind of pyramid scheme where you advance to create nicer tools for the people who are less advanced. Of course there are plenty of other ways that start-ups and programming are not like that, but it's a really interesting lens through which to view a lot of the news that is popular on HN.
I think in an effort to categorize himself, the OP has created layers of knowledge that only apply to him.
Personally, my expertise slides up and down all of these types, proving you can't really nail this one down.
There are going to be those who write to automate, write for design sake, write for scale, etc. Even saying that is a bit of a misnomer because there are so many facits that incorporate one or many of those functions.
Reading the comments, theres a lot of disagreement (for some valid reasons) but this list is getting more hate than it deserves. If you consider that the MAJORITY of programmers are essentially corporate code monkeys this is actually a very accurate list.
If I read this list and then apply its rules to the average programmer at fortune 500 companies it is almost perfectly accurate at measuring the least to most talented programmers I've worked alongside.
In the corporate world, the bulk of developers fall into one of the following groups: guys who can barely modify a custom report, guys who can write a report, guys who can create a basic CRUD class for reuse across reports, guys who can contribute to a complex application, guys who can design a complex application, and then the guys who are hired to create the tools/languages that are leveraged when creating complex applications.
There are obviously many areas of programming that do not fall under these definitions but the AVERAGE programming (i.e. average corporate developer) probably fits very neatly into one of these definitions.
If I ignore the rating system in this post, I see this list as an exercise to acknowledge my strengths and recognize where my weak points are. Doing so, I came up with a list of areas to explore in the near future.
I would say I'm close to 7, with a lot of peeking ahead toward levels 8 and 9.
It's an interesting way to look at prowess. Instead of looking at specific languages/technologies, we look at the progression of understanding. Ie how rich, efficient, and effective the programmer's mental model is.
What's a good salary aspiration for someone at this level who's situated in Sweden? I am currently making nowhere NEAR the ludicrous fantasy sums (ie $100k+) that you Americans consider to be a human right but I'm thinking I could aim higher.
Maybe I could use this level-based thinking when discussing salaries with employers?
> I am currently making nowhere NEAR the ludicrous fantasy sums (ie $100k+) that you Americans consider to be a human right but I'm thinking I could aim higher.
When comparing USA and €U salaries, you always have to factor in all the things you basically get for more-or-less free like complete medical care which you are paying ridiculously little for, way less than the amount of money you actually need in case of a serious illness - plus social insurance, more than twice as many vacation days than the average USA employee who just started out, plus way more restrictive labor laws, plus some sort of retirement money the government pays you (at least still for now) and paid sick leave. Then factor in the money USA employees have to spend to "keep up" with the on-average higher working hours - ever wondered why there are so many convenient services for practically everything in the USA that we Euros can only dream of? And ultimately you have to factor in costs of living in the valley or surroundings which are way higher than over here and way higher than in most other places in the USA.
Ultimately, I think this level of proficiency might be hard to sell in an interview because employers care about what you can actually do and if they want a Java or C genius, then they probably don't care that much that you could "write a library" but have no working experience in the languages they are requesting. But if you can plausibly sell them on your broader view and understanding of all things IT, ideally backed by some sort of study and degree, that might work but I am sure it would also depend on the position you are applying for.
You want to make close to or more than €100k as a programmer/it-expert in Euroland? Shouldn't be too very hard, either find a fantastic niche and work it and/or combine that niche with consulting work... I think the unfortunate truth is that unless you are some sort of coding rock star and/or become technical lead or something like that, just being good at writing lines of code in an arbitrary language isn't such a highly paid job anymore. Make that some obscure language for a very specific system, ideally serious-business system, somehow directly business/profit-related and all of a sudden you have leverage. A lot of the old host neckbeards are retiring or, excuse me, dieing out and I have to yet see a bank or stock exchange that runs completely without those old "legacy" systems and has successfully migrated 100% away from them. So, time to polish your COBOL and what-not skills, get some working experience there... I am sure you could find a LOT of happily paying customers with all sorts of software running on some host system and they no longer have anyone who knows what is going on. Or look into the myriads of software systems surrounding banks and stock exchanges in general. It's all just some software and a lot of it is pretty damn terrible but the prices customers have to pay for using it and for support is still ridiculous plus you have a niche with lots or a couple of customers pre-made for you.
If you like working as a consultant and carrying all the risks and benefits, then 5-figures a MONTH aren't a fantasy or wishful thinking but of course you are giving more than just your work and you are "paying" in other ways.
Just don't expect you will be making more than €100k just because you are so much better at LAMP than Johnny at age 16.
What are some highly specialized niches that I could look into for consulting?
I actually don't care that much about money, in absolute terms. I care about maximizing my free time and maintaining a somewhat decent standard of life. Ideal scenario for me: a high hourly wage + the freedom to take on work in whatever chunks I prefer.
I listed some quick-shot ideas there, did you see them? Ultimately you will have to see and try for yourself how well they work and what other opportunities are there - scout the terrain yourself.
> I care about maximizing my free time and maintaining a somewhat decent standard of life. Ideal scenario for me: a high hourly wage + the freedom to take on work in whatever chunks I prefer.
Most of this SCREAMS consulting, you could be making more a week than you are making a whole month now... but you have to put that into perspective. As a self-employed consultant, you will have to take care of all your taxes and insurances but at the same time you can effectively buy computers and certain other things MUCH cheaper (practically no value-added tax). You will have to find customers, projects or are lucky enough to find longer lasting maintenance gigs but YOU will have to do that. You will be your own boss and depending on your customers, your working hours might be extremely flexible but you will also have new and different responsibilities... taxes and insurances are one huge part of that, the other is that lovely thing known as "liquidity" that can break your neck faster than anything else. And when you are a consultant in some software-product niche, then chances are whoever makes that software will actually sign the deal with the customer and then pass it on to you but of course they will bite a nice chunk off first... but on the other hand this might also be a chance to get started and meet people and customers, use their name, reputation and connections.
Another thing is "taking on in whatever chunks I prefer"... generally, yes, you could say yes and no to any offer but chances are you will NEED them. So, while you are a lot more flexible that also means you are more dependent on actually having something to do that will ultimately pay the bills. You won't be able to simply rely on recurring, reliable amounts of money. Oh and there are customers who will just make you wait for whatever money they owe you because like I said above, everybody is liquidity's bitch and in the worst case you might not get paid at all... that is definitely a risk you will have to carry and be aware of.
So ultimately, those 4 figures a day sound insane at first but you will have to dig deeper and really weigh the ups and downs and whether it is something you like because ultimately it ends up being less; possibly still handsome but chances are your actual work won't just be "doing task x for customer y" but you will also have to do a, b and c just like a real company would have to - because ultimately, you actually ARE your own company at that point. Your best bet is to read up on it as much as possible, talk to self-employed consultants a lot and since you are European, chances are your government offers some sort of "kick-start" help, training or even funding when you start your own little "company".
Oh and, stay self-employed and if you need help, find other self-employed contractors before you take on actual employees working for you. European law doesn't frakk around when it comes to employees... save yourself that trouble for MUCH later.
The bottom line is: it has a lot of positive and a lot of negative sides when compared to a regular 9-5 job and you will have to weigh them yourself and see how it works out... it is definitely an interesting experience and can be such an exhilarating, empowering feeling because YOU are working for YOURSELF and make all the decisions but remember that most "startup" companies like that typically don't make it over the first 1 or 2 years and a LOT of "I can write Java really well" guys are desperate for gigs on the side because it is hard finding a project... so they write books or teach. That's why the idea with the niche. And see what your government, chamber of commerce etcetctec can do for you.
Well, I think I could swing it. What kills me right now is not my meager salary, but rather that it takes so much damn time to acquire it. And most of that is unnecessary time. Working hard and playing hard is more my melody, I dislike the middle ground.
I should also mention: consulting can also require (much!) more flexibility and traveling depending on partners and customers and staying in hotels and flying around all the time can get very old very quickly... most of the time you don't really have any chance to enjoy the place you are staying at anyway - if you are independent and don't have a wife or especially kids to worry about, if you are young and just starting out, it is definitely a great option to see a lot, meet people, get "front experience" and valuable contacts a lot easier and natural than any other way - if you want to have a family and enjoy lots of time with them and provide for them reliably, it might not be the best option.
And I hear you about working and playing hard... I would love to do my week's work in 2-4 days and have the rest of the time off but the overwhelming majority of employers is stuck in Ford's 40-hours-at-the-belt kind of ideology, especially in older, settled industries.
I like how programmers target other programmers at different levels (and also that the more advanced you get, the more able you are to target less skilled programmers). Not sure that's fully correct, and lots of details to disagree with, but I appreciate this point of view.
An overall objection: though it does both, it focuses on coding solutions rather than understanding problems. While there's a case for defining a programmer as "someone who programs", to me, understanding the problem (aka asking the right question) is the difficult bit (see Douglas Adams).
What I said when that hit HN still applies. Treating the creation of yet another programming language as somehow being the pinnacle seems like a bad idea.
The first few levels make sense, but beyond that unless the author is the highest level described here i have to ask if this is a prediction or a description of their experiences?
Seems naive. I came up with an engineering scale that I think is pretty solid, at least over the 0.5 to 2.2 range. http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . I'm only about 1.7 so beyond about 2.2 I had to start using "bigger and badder" type definitions because I could only delineate those levels based on visible accomplishments, not experience or observation. Also, it's more of an "liberal arts" engineering (adding value to organizations) than one focused on domain-specific programming capabilities, which are still important but much harder to measure. You can become a 2.0 engineer in artificial intelligence, or in front-end web development, or in embedded device development and the processes of getting there are rather similar. Being a "good programmer" in each discipline is different.
What OP's system describes is the progress from a novice (0.5) to a competent adder (1.0) to a general-purpose multiplier (2.0). Most serious programmers are between 1.0 and 2.0, so the growth process is about becoming a multiplier. At 1.1, you start automating annoying tasks by writing scripts. At 1.4, you're starting to become aware of the need for language-level support for code reuse and complexity management, so functional programming becomes attractive. The 1.5-1.7 range is when Lisp's language-oriented features (macros) start to shine. Most 2.0 programmers are cautious about when they use such things, though. Yes, DSLs can be very powerful; they can also be unmaintainable, miserable cruft-piles. Being a great (2.0+) programmer is about adding the most value though team- or company-wide multiplier effects, not being clever. Often, you add the most value by designing systems so simple and elegant that they almost insult the user's intelligence (in a good way).
Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects). And pretty much every 1.5+ programmer knows what functional programming is and what its rules are (and when to break them). That said, it's not a strict rule that to reach or surpass 1.4-1.5 you have to spend X amount of time using functional languages.
You know, one thing I like about your system is that you aren't at the top of it. I have to question peoples' motives when I see an article like this where they're clearly at the top of the hierarchy.
I developed the scale because I found myself frustrated by "95th-percentile" syndrome. I noticed that, from when I started programming to now, I always considered myself around 95th percentile. And so did most other programmers I knew, whether they were "objectively" 80th or 99.5th. Which meant that these percentile-based self-assessments were worthless.
Similarly, if I were at the top of the scale, that would show a lack of imagination on my part, and also make the scale worthless in a "I won at a game where I just wrote the rules" sort of way. Personally, the territory that's most interesting to me is 1.7 to 2.2, because that's what I intend to be covering over the next 5-10 years.
People tend to estimate themselves as average within what they consider their peer group when comparisons are difficult or impossible to make (and the fact is that it's really hard to compare two programmers). So I think the 95 comes from the fact that it's "common knowledge" that 90% of "programmers" are incompetent.
Of course, these percentiles depend on a population and competence distribution that are by no means immutable, which makes them meaningless as technologies evolve and more people come into software, so I needed a scale for professional development of an engineer based on general knowledge and approaches. The actual 95th percentile is probably around 1.5 on that scale, but that's just a wild guess.
I'll still use "5-percenter" (loosely; no clue what the actual percentage is) to describe an elite set of programmers, but that has more to do with attitude, bearing, and trajectory than present-time skill. For example, the guy who picks up SICP because he's topped out and bored at his Java job is probably only 1.2-1.3, which is not yet 95th-percentile, but he's a "5-percenter" because he has the attitude and has found the resources that will make 1.5 likely and 2.0 possible-- which wouldn't be the case if he stuck with his same-every-day enterprise Java job.
I was mostly agreeing with you until you starting on the technology bigotry.
> Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure
What about people like Doug Lea and Josh Bloch? What about people like Trustin Lee? Why do these people not qualify as 'multipliers' in your framework because of their choice of technology?
The idea that using a single technology or approach - in your case a functional language and not even a functional style - would be the difference between an adder and a multiplier is simply absurd.
And then you go on to say:
> This is because the Java+IDE environment, and operating systems like Windows, are designed to bring up the rear (0.7 to 0.9) while holding back the best programmers, artificially imposing that “ceiling” around 1.2-1.5
You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for. What about many of the really useful sites and services that are served from Windows (or Java running on Windows, gasp!) or the innovative and world-changing pieces of software which are primarily developed for Windows? Excluding all the people behind those from being upper levels seems like a stretch.
> these technologies are intentionally designed for a performance-middling effect– to make it possible for huge teams of “commodity” developers to produce something while holding the excellent back from producing great things.
This is the core of my problem with your argument. I can think of many more things I would call great that used technologies like C++, Java and Windows than used technologies like Lisp, Scala and Clojure.
> Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects).
You are simply wrong about this. There are many marks of a good engineer. An interest in different programming paradigms is one of them, for sure. To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill.
I have been lucky enough in my career to work with many great engineers, leaders in their fields, who have chosen to use the technologies you deride and are therefore forever stuck at the lower levels of your hierarchy because of those choices.
(On the other hand, I may have just fed the troll).
First of all, I was exaggerating the negatives of Java. There are 2.0+ programmers writing in Java every day. The vast majority of these would prefer to use another language, but that's another story.
My experience is that most 1.5+ developers, when forced to use Java, react in one of two ways. The first is to scale back their general tendency toward ambition in coding and tolerate uninspired patterns, such as objects with 25 getters and setters. This works, and it can produce quality software, but it's not fast and it's definitely not fun. The second is to follow Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) which describes the process by which a skilled programmer, confronted with under-powered tools for his job, creates a personal DSL (and usually a bad one) for solving the problem. Rich Hickey and Martin Odersky are counterexamples: instead of writing shitty DSLs, they built full-fledged, awesome languages.
Are there 1.5 and 2.0 programmers in languages like Java? Absolutely. Is it common? No. Is it likely that a person exposed to only Java and C++ will ever crack 1.5? Absolutely not.
You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for.
You're taking it a bit far. Obviously, there are exceptions. Multiplier effects happen on bad languages, but you have to either (a) fight the language the whole way through, or (b) deliver a complex system, which ends up being a divider effect if someone other than you ever has to maintain it.
To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill.
Disagree, unless you're taking a very strict view of what "functional programming" is. A 1.5 programmer in Python will find himself using a lot of list comprehensions. Are his Python programs likely to be "purely functional"? Absolutely not. It's not idiomatic for the language. But his code will be in a state where the average Lisper will understand what he is doing and why, and in which the average Java developer will be asking "where are the Factories?"
My experience is that most of the highly skilled engineers that I have worked with don't really care about the language that much. Most of them are much more interested in what they are building, and interested in how they are building it to the extent that it gets in their way or gets in the way of future maintainers. There are those that are much more productive in languages other than Java, but for most the barriers to productivity or delivery time are not the language but the environment. Using a well-supported and mature platform like Java (both the language and the JRE) helps a great deal here, as does the wide variety of libraries and frameworks available in the Java world. The same applies to the .NET platform, and some other mature platforms that are available.
Languages like Scala and Clojure blur the line here a bit, because they are 'more powerful' languages on an mature platform. The Java language still holds some benefits over these languages, mostly in it's stability.
> but it's not fast
No, let's not start the 'Java is slow!!!!' debate again.
> Greenspun's Tenth Rule
I think Greenspun is wrong about why this happens. I think it's a sign of weak program design, rather than a weak language.
> Are there 1.5 and 2.0 programmers in languages like Java? Absolutely. Is it common? No.
I think you are wrong about this. I have seen little evidence in my career of a correlation between chosen technology and ability to deliver results. There are some technologies that I don't like or find not to my taste (PHP springs to mind), which have been the basis for some fantastically successful projects.
I might admit that the median skill (measured by the ability to deliver effective results) of people who chose Java is lower than those who chose other languages, but my experience suggests that those differences disappear quickly as you move upward.
> Disagree, unless you're taking a very strict view of what "functional programming" is.
Expanding your definitions to preserve your point is a symptom of fallacious reasoning.
Engineers chose tools for many reasons, and a good engineer will have a wide set of tools they know and good judgement about which is the best to use. Looking at which tool they happen to have chosen isn't a good indicator of skill - the actual outcomes are much more useful. Is what they built useful? It is maintainable? Was it delivered on time? Was it delivered in budget?
My experience is that most of the highly skilled engineers that I have worked with don't really care about the language that much.
My experience is that most good engineers are conscientious. They don't want their code to be tomorrow's legacy disaster. This makes them care a lot about languages, if we're talking order-of-magnitude differences like Scala vs. Java. If we're talking about Clojure vs. Python, then maybe not.
Friends don't let friends maintain Java code.
No, let's not start the 'Java is slow!!!!' debate again.
Java is slow to write. And very slow to read. Ever maintain a Java or C++ project? It's glacial. I'm talking about human performance, not runtime speed.
I think Greenspun is wrong about why this happens. I think it's a sign of weak program design, rather than a weak language.
I think it's a sign of bad practices. One thing that impels people toward bad practices (and not the only thing) is using the wrong tools.
C was designed for simple programs that need tight control over resource use and speed, or that need direct, reliable hardware access. As per the Unix philosophy, these programs were never supposed to become large; they should be modular and communicate through pipes or sockets. For those purposes, it's excellent. But if you have a 250 kLoC C++ program, you're doing something wrong.
One causative factor for the Greenspun effect is inappropriate language choice. It's not the only one.
I think you are wrong about this. I have seen little evidence in my career of a correlation between chosen technology and ability to deliver results.
"Deliver results". Here is your problem. A 1.2 programmer can code software to spec, meet deadlines, et cetera. That's an additive effect: cranked it out, met deadlines, went home. The difference between a 1.2 and a 2.0 is the ambition (in the latter) toward multiplier effects-- toward using technology to make whole teams or companies more effective. It's not just about "results"; it's about what those results are.
Expanding your definitions to preserve your point is a symptom of fallacious reasoning.
I guess my point was that it's not accurate to say that 1.5+ programmers always use functional programming, but the weaker claim is true that, for complex tasks requiring high-level languages, they prefer languages that support the functional style.
Enterprise Java idioms are slow to write and slow to read, but if you use Clojure to write the same sort of crap you end up with same sorts of crap. Read Vuse's source code for a fresh look at what it means to use Java. http://dev.vuze.com/
I think the only "level" you should really care about and isn't on that list: being fluent enough on all systems, APIs, libraries and infrastructure you are connecting to or using so you ultimately do not really care all that much which language you are programming in, on which system and OS and even if you didn't know the system or language all that well to begin with, you would still manage to become fluent and productive in it in reasonably short time.
It takes experience and some understandings of the fundamentals of computers, software and networks and some curiosity and will to find things out and better yourself but if you want to be a programmer and even work as one, then this is what you should aim for... be "fluent" enough on (almost) all OSI layers so you can figure things out and understand what is really going on and whatever very-specialized knowledge will be required at a certain point in time, you will be able to figure it out and pick it up along the way because you will have the broader overview and understanding to connect things.
