Programmer Competency Matrix: Do you use it when hiring?

Indiangeek comes first, so it is probably online the longest. Not to mention that the hacker news post about it is 881 days old, and is the second result on Google.

Mentioning a Windows-only technology doesn't make it Windows-centric.

Mentioning only a Windows-only technology? Now that's Windows-centric. However, I see no example of that in the list.

I bet nobody would flinch if they saw reference to a UNIX-exclusive technology, either. (I saw VSS was called out - but had this been written three years ealier, Git would be in that same boat.)

Selective quoting, much?

- The context in which it mentions VS.Net: "Limited to primary IDE (VS.Net, Eclipse etc.) "

- The context in which it mentions Powershell and VBScript: "Perl/Python/Ruby/VBScript/Powershell "

So it describes a number of alternatives, some of which are for Windows-only, and all of a sudden the table is 'Windows-centric'?

I mean if you don't like Windows, fine, I don't care. But playing ostrich for anything Windows is just ignorance, and I mean that not in the 'not knowing' sense, but in the 'not wanting to know and proud of it', the 'ignorant hick' sense.

The 18 upvotes (as of now) of the GP make me sad. It makes me feel like many people voting are offended by the table because they don't score very well on it, and are looking for a reason to dismiss it, and oh look - something about Windows, that must be bad, because anyone using Windows or programming for it must be a moron.

I don't agree with all the details in this table, either; but that's irrelevant. This is a conceptual framework, a skeleton to apply further critical thinking on. It's been around for years and has been repeatedly upgraded and refined. It's not perfect but it's at least something. Outright dismissals of attempts at making programming and software engineering more quantitative processes, and - dare I say it - more like 'real engineering', and especially the dismissals based on hype technology fetishism, hold back real progress down in the trenches.

(oh and yes, I'd subtract just as many point for not knowing what 'PowerShell' is as I would for not knowing what 'Ruby' is, if any, in any interviews I'd do around this chart.)

I'm still not sure of your argument; if you've heard of the higher level concept but don't know the fundamentals, that obviously still says something about your skill level and drives as a software engineer. It's kinda useless to try to list what exactly it could mean in this concrete example, the point is that the model allows systematic evaluation of skills.

Each node has a piece of data, and a pointer to the next node (or null if you've reached the end of the list). In a doubly linked list the nodes also has a pointer to the previous node.

This structure lets you build a list of arbitrary length without having to know in advance how much memory to assign it. You can append and iterate over elements in O(1), however seeking to an individual list element is O(n).

Most dynamic languages do not make much use of linked lists since it is easier just to use dynamically resized arrays. Any time you fill it you allocate a new array that is, say, 20% bigger and move the data. These allow you to seek to any element (including the next one) in O(1) with better average performance than linked lists. They also let you append in amortized average O(1) cost. Meaning that when you average out the cost of n appends, the overhead is O(n). However that cost is born unfairly, most are cheap but very occasionally you need to allocate the next bigger array and move existing data. For many applications (eg building a web page) this is fine. But if you're working in real time code then amortized average O(1) is not the same as O(1), and you must use a linked list.

There, now you know what a linked list is.

Level 2^n: uses string concatenation in his SQL, for web forms passes plaintext passwords around in Javascript, has already been rooted and doesn't know it.

Level n^2: uses stored procedures, knows that cross site scripting and sql injection is bad, stores passwords in a form other than plain text, may block certain kinds of 'naughty' inputs (e.g. http://xkcd.com/327/ )

Level n: uses whitelists to validate input, does not use windows or SQL Server for anything, understands that security has a price (eternal vigilance) can explain what salting and hashing are, can protect your password against malicious database admin.

Level log(n): can protect against social engineering, audits OpenBSD for jollies, has transcended the need for users to create accounts and enter passwords, is completely unable to communicate with outside world since all their email has been PGP encrypted since the late 90s.

That is why the matrix is conveniently broken into specific sections.

Yes, it most certainly does. In the long run, the developer with the better grasp of fundamentals (e.g., discrete maths, data structures, algorithms and so on) will produce better code. NB, I'm not saying that the "naive" web coder can't produce good code. Nor am I implying that CS education always makes you a better developer. On average, however, that's exactly the case.

Even with generic web 2.0 stuff.

We all know rails has problems with scale, and that these problems can be overcome. The way to overcome these problems is through optimal and performant coding/data-storage patterns, and to practice these one requires knowledge of CS-type matters.

Now Rails or Rails-esque apps obviously will not encounter these issues until they reach a certain size. Therefore unless one has the requisite CS-style acumen, one's projects have a cap on their maximum success/popularity.

Assuming that when we say "dreams" we are referring to hackers' projects becoming big and successful and popular, (thats what everyone around here seems to dream about,) they will not be realized without someone around who knows their big O from their divide and conquer.

On interactive debugging, it's terrific stuff when it's needed. I've done a LOT of programming, and a few times I've used interactive debugging: When I needed it, it was terrific.

Net, I just haven't needed it very much. On my current project, I haven't needed it at all yet. I believe that I've written the challenging code, and I had no problems with debugging.

For some of the trickiest parts of the code, I just coded the operations twice, once a simple, slow way and once the faster, trickery way I wanted in the final version; then I had the code compare the results. I ran enough test cases to have good confidence that the two versions give the same, and correct, results. If the results were not the same, then to find the difference, instead of interactive debugging, I would have just 'desk checked' the code carefully. I find such desk checking terrific stuff -- each little possibility for a problem has to be checked, and sometimes more than one error is found. With interactive debugging, I can be tempted to quit checking when the first error is diagnosed for just that one test case -- not so good.

Or, "Joe, there's a bug in here somewhere. Find it with desk checking."! Or, "Mary, Joe says that this code is correct. Here's $1000: If you find an error, then you get the $1000; else Joe does."!

I wouldn't have coded just the tricky version and then tried to use interactive debugging to be sure the version was correct: My test cases were too extensive for checking 'interactively'.

For "I can't imagine adding print/log lines for every imaginable variable in a scenario.". I don't do that either or need to. Occasionally a few print or log file writes, in a small part of the code, say, where I just added some code and something doesn't work, have been enough.

Generally, though, any reasonably complex system should be able to report, at levels of detail requested in real time, what it is doing, and a lot of print or log statements are a start. In my most important code, I have such statements controlled by a variable that specifies 'message level', that is, the 'level' of detail of the messages. My intention is later to use Microsoft's code instrumentation infrastructure to send the contents of such statements to some 'system management' platform. So, generally I like 'messages' from code.

And, actually, in my testing, I have lots of such print statements executing. The output of a small test case can be some thousands of lines, and I explore them with the capabilities of my text editor; I wouldn't want to do that work with interactive debugging.

E.g., recently I had to reinstall the Microsoft software on my boot drive (grim story) so wanted to be sure my code would compile and run as before. So, for each directory of code, I made a copy of the directory and in the copy again ran the relevant scripts to compile the code and to run it on the test cases. Then I took the output, with its thousands of lines, and used a simple editor macro to do a line by line comparison of the new and old output files. Some lines were different because of time and date stamps or reports of allocated memory addresses. A few editor commands removed those lines, and then the old and new output compared perfectly. I can't see any easier or better way to do such a test; I want the print statements and don't want interactive debugging as a substitute there.

To me so far interactive debugging is so unimportant I haven't even taken the time see what is available with VB. I believe that somewhere I saw that VB has interactive debugging also via command lines; if so, then that should be the most I would want. But I haven't even looked.

Here are my 'source control' tools!

First, if I am making any change at all in an old program or any significant change in a program still under development, then I start with a new file. So, if the last version of the program was PROG013.VB, then the next version is PROG014.VB; that is, I copy file PROG013.VB to file PROG014.VB, put some explanatory documentation at the top of the file, and start making changes.

I don't don't even see the "014" -- I have an editor macro find that for me! My editor gives me a directory listing, and one keystroke sorts the files in descending order on time, and then PROG014.VB is right at the top of the list ready for work!

You mentioned "undos" -- that's PROG013.VB! Of course another source of 'undos' are the daily incremental disk backups! And another souce is just my text editor.

Second, for making changes in a program, typically I slap a time and date stamp on the change. So my editor does that, e.g.,

Modified at 01:32:46 on Wednesday, December 1st, 2010.

For source code files, the editor puts this line in as a comment, choosing the comment syntax based on the file extension.

So, I get time and date stamps, and that's close enough for me for a "logbook" of changes!

For "comments for explanation", I'm big on those!

For "I'm not a fan of English docs either":

Well, fundamentally there's no alternative: Again, as I wrote:

"There is, so far on this planet, exactly one way to record and communicate meaning -- a natural language, and of these, now, the most important is also my native language, English."

Fundamentally, that statement is just true. Sure, with enough detective work, decoding, etc., people commonly guess at the meaning given much less than what I described.

Other aids to understanding the meaning include mnemonic symbol names, pretty printing, and your "readable" code. Still, at least fundamentally, these aids cannot replace English as the source of meaning.

You wrote

if(noUser || userIsBusy)

Okay. For using English documentation, I gave as examples college texts in math and mathematical physics. In such books, the symbols are carefully defined and maybe also motivated, discussed, and illustrated. Then commonly the exposition can continue with some 20 lines of algebraic derivations without additional English. Your statement 'if' can be seen as parallel.

For your symbols

noUser userIsBusy

likely somewhere you specify the data 'type' of these as 'logical' or some such, and then your code can be plenty clear.

Yes, keeping the English documentation up with the code is a pain:

For an on-going development project, it can be tempting to rely on the fact that the team does know the code and delay a lot of documentation. But if the project goes on for many months, then staff can leave and leave the project short on what parts of the code 'mean', and new staff can arrive and be lost and nearly useless.

Further, at some point development slows and the software becomes an 'asset' of the company. For continuing value, there needs to be enough documentation so that a new team could with reasonable efficiency take over and 'maintain' the code. So, that new team needs, typically, quite a lot of good English documentation, both as comments in the code and as an external paper. So, before the original development team goes on to other work, it can be important to take one more pass over the code documentation and get it up to date and clear. Sorry 'bout that.

Generally on code and its internal documentation, Knuth's work on 'literate programming' is one polished way to proceed.

In particular, for the code I wrote a year ago, without reasonably good documentation I wouldn't know what the heck the code does or what I was thinking about.

Here's a related point on IDEs: Of course, can use SQL Server Management Studio to 'define' a database, that is, say what the tables are and for each table what the columns are. Yup, can do that! But I refuse to!

Instead I define the database using the T-SQL statements in a text file, and here's why: The text file has about as many blank lines just for 'readability' as T-SQL lines. Then the comments are about five times as many lines as the sum of the blank lines and T-SQL lines. These comments explain what the heck I had in mind for that database 'schema' (in the traditional sense, not really in the sense of SQL Server 2005 and later). So, when a table has a clustered key and also a separate index, the comments explain why. Etc.

So, that 'schema' with its documentation is a rock solid part of my project; as I write code to manipulate the database, all the code writing draws from the ONE, SAME documentation of the database as the code should.

If I typed the schema into the SQL Server Management Studio IDE, then I'd miss out on the documentation and the primary source of crucial 'meaning'.

GUIs have often been praised with "What you see is what you get", but there is a perceptive old response, "What you see is all you've got.".

Or, using SQL Server Management Studio to type symbol names into text boxes just does NOT create the crucially important meaning.

Sure, one way to be sure that English documentation is not "flat out wrong" is to omit all the English documentation! But I suspect that if you were to maintain code written by someone else, then you'd rather have more English documentation, possibly with some errors, than less.

Yes, important, undocumented code can be a form of job security! But for my 'job security' I want the code well documented because in two years the code may need some changes and I may be the person who has to make them.