I don't disagree with the comments about the triteness of this page and other articles like it. That doesn't mean it's entirely without value though. Think of it as like a financial budget: you know you're not going to hit it completely and some of the items you've budgeted for will turn out to be unnecessary or wasteful. At the end of the budget period, though, it gives you something to measure actual performance against.
The value in an exercise like this is the insight into the collective assessment, especially spanning different software disciplines, and with broader expert input.
I would introduce ‘make’ in the build automation (level 3) section.
Understanding make (dependency graphs, splitting up the build process into small tasks which can be parallelized, restarted, and leave an exact record of how much was succesfully built) I consider a valuable trade and magnitudes better than “writing your own build script” (as is presently what is the level 3 skill).
Isn't this the sort of table that shows its author is a L337 hax0r because he's in the top category of everything? Anyone who automatically puts things like DVCS, TDD, and practices obviously related to Open Source development in the top tier sounds more like a Kool-Aid drinker than an objective observer making a sincere attempt to provide a useful resource.
These things are heuristics, not things that actually make you good. Look at "has tried bzr/hg/git". That's probably true of the best programmers. But trying git for one day is not going to make you one of the best programmers.
A lot of the O(log N) items were depressingly basic. An undergrad education in CS will get you to O(log N) in basically all the Computer Science categories.
Where are the finger trees? Array-mapped hash tries? Cuckoo hashes? Where's the domain-specific algorithm knowledge, like machine learning or information retrieval or computer vision? The IDE plugins? "Let it crash" and supervisor processes for error handling?
It's also depressing that O(log N) for "years of experience" = 10+. A motivated and reasonably intelligent student can get to O(log N) in all the other categories with an undergraduate CS degree and about 2 years of work experience at a good employer.
Last time this came up, somebody made the comment that you're in the highest category that you have finished everything below. Just because you started with git doesn't make you good at VCSs, but if you have done everything below it as well, you probably are an expert. To put it another way: would you put SVN on the right side of that row?
As an aside, I do believe that DVCSs are somewhat more complicated than their centralized counterparts. This is mostly because they are young and lack the mature tool environment that things like SVN do. As a result, users are forced to understand how they work, instead of relying on pre-defined sequence of work->save->test->commit. If SVN was the new hotness, people would have written reams about the theoretical motivations behind a a centralized server, copying-as-branching, etc. But it's not, so git/hg/bzr get all the credit for being algorithmically interesting. In the end, this means that if you don't want to think about it, go with a VCS that's a little older, and I think that justifies the ordering in the chart.
Hmm... as joe_the_user said, it's a nice checklist for holes in one's background, but I'm not sure if it should serve as a list for "hireability" - I know people that are probably on the higher end of most of the points, but are terrible at real-world situations.
These probably are crucial for the kind of programming done at the startups, though.
I score as Level 1 or Level 2 at most on almost all the items, some Level 3 points don't seem relevant (why should I need a license header for my work programming?).
What I believe is that some of the points are WAY more important than others, I personally place great value on my domain and business knowledge and believe that is a trend going forward.
Still, thanks for making it available, reminded me I have to do some more studies.
He misses a few points subjects like computer graphics, computational geometry, understanding of databases (did he mention this?), numerical simulations, GUI design, general math skills, compression algorithm, heuristic algorithm, etc
This matrix is a bunch of crap. The ability to "get things done" is the most important factor of programmer competency. Every thing else is incidental.
Not true. Getting "things done" while creating an O(N^2) solution, in spaghetti code, to a problem that's already well solved by an external library is horrible.
Using your argument:
Mcdonalds, Starbucks, Walmart, Coke and many other companies are O(N^2) solutions and therefore failures. They repackaged an existing idea, made slight modifications, and sold it for lots of money.
I hate seeing wasted money and stupid solutions succeed like the next guy and maybe we're talking about different things. But whether things got done should be decided by the customer not your TDD fanatic coworker.
I tentatively agree because these things can be showstoppers, but it really depends. I've seen PhDs who can't tie their shoes. Theoretical knowledge is useless in production software if you don't know how to apply it, and yet without it you will be greatly limited in the scope of systems you can build.
I used to believe that too, but I've changed my mind.
Now, I'll always prefer clean organized code, even if it doesn't work. I can always hire someone or jump in myself and make the changes that are necessary.
It is safer to assume that all code is broken in some way. E.g. If someone says that code "works", what they usually mean is that the software is broken in ways that they doesn't understand. When someone says a system is "secure", it means that it contains vulnerabilities that they haven't yet discovered.
A pessimistic attitude, but it has served me well.
Sometimes a decision can be made to accrue technical debt or to keep paying the interest on the acquired "technical debt rather than the principal. However, the decision has to be made by someone who understands what an elegant solution would look like (if time or budget restrains aren't there).
That's why you need somebody who is both smart (can see the elegant solution) and gets thing done (will ship a minimally acceptable solution and re-factor when needed).
You sound just like my old pointy haired boss. I'll do with you, what I did with him. I'm going to roll my eyes and call you names when you talk to me, because I know you're too dumb to do my job and smart enough to know that.
No! This is what makes you a good entrepreneur. It's in no way a reasonable definition of a good programmer.
There are already dozens of dimensions that you could use to measure programmer greatness: being able to solve very difficult problems, writing very maintainable code, writing working code very fast, writing very rigorous mathematically correct code, debugging very fast, having good intuition about how the project will evolve over its life, working well in a particular team, working well with other disciplines, being able to deal with corporate politics and still get shit done etc.
Tying product design and marketing to this plethora is a wholly unwarranted conflation. Even if it's just two software developers in a garage.
Agreed. This attitude is why software has such a bad reputation. People are in such need for software, that they will tolerate horribly unreliable software if it happens to sort of solve their problems. Good software is rarely available, so people just expect it to be bad.
If people started demanding software as reliable as the things produced by other engineering professions (buildings that don't collapse, etc.), then being a good programmer would be strictly tied to making money. But right now, the code is the least important part of software companies. The idea and the marketing is significantly more important. (Hello, Twitter.)
Also, people are quick to associate personal gain with the economic value of a program. The Facebook founders may be rich, but automatic trading systems handle a lot more money (even though the programmers didn't necessarily get rich writing it). Facebook can have as many bugs as it wants, and they will be fine. An automatic trading system can ... cause problems ... if it is not bug-free (and well-written, or written by good developers). But you never hear about that sort of thing from these people; only how their blog makes $10/day and that how they are a genius and visionary for doing that.
It's true, but that's only one way to be a great programmer. There are a lot of positions out there where it might be incredibly valuable to an organization to build a new CMS, a better UI, or a more robust middle tier, but these aren't independently valuable. With two or three people who can do these things, you can make something people pay money for, but that doesn't mean that the individual programmers aren't competent.
If you disagree with this 1x1 matrix that means you value form above function... which means you're destined to be a starving artist who writes software that is great for your imaginary friends, but will never become a great programmer that writes things real people want to use.
I had a professor in college that used to say A+ is for me, A is reserved for God, A- for the head of the department, and the grades B+ and below are for you...
So by that line of reasoning I assume that O(1) is reserved for the author.
The books category is especially ridiculous. You might have read some books in each one of those levels, and they're not exactly prerequisites to one another.
I also use Git exclusively, that doesn't mean I'm proficient with SVN.
