Live data from Hacker News

Programmer Competency Matrix

starling-software.com

81–90 of 127 posts

Re: Programmer Competency Matrix

#81
post #32

I'm not sure this has anything to do with "competency". When I was in high school, I implemented a kd-tree for a ray tracer using photon mapping. I knew that my n^2 algorithm was slow and that there was probably a better way, so I Googled and figured out how to write code for such a structure. Since I'm not a programmer (I'm a chemical engineer), I don't instantly know all of the orders of various algorithms (which a…

I agree with this - e.g not being able to bust out a dynamic programming implementation perfectly on a whiteboard doesn't make you a bad programmer - more important is to understand, "hey, looks like when I divide this problem up it has overlapping subproblems - let me research using memoization or dynamic programming". But that still assumes you have the right terms in your head to be able to do the research - and t…

True. But note that the matrix isn't a binary "good/bad". If you know the concepts that underly dynamic programming and can look it up when needed, great. If you have used it before and can bang out an implementation without looking it up, well, that's even better.

Re: Programmer Competency Matrix

#82

Earlier quoted context omitted.

so programming is your hobby, have some fun while researching and solving some problem using some random solution found on the internet which might work or not professional coding is about something different

It may be a "hobby" but I've been doing it for 12 years, made money off of it, and would argue that I probably know more (theoretical and practical) than your average bachelor's grad in CS. And I don't know where this "random info on the internet" came from. My knowledge comes from algorithm textbooks or papers from university websites. Why the vitriol?

there are few more levels of knowledge and experience to achieve in order to improve overall quality of your work and that's the point of this article,

you can ALWAYS achieve your target in a better way

Re: Programmer Competency Matrix

#83

This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience…

I'd just like to see a list of some things that should be minimum / recommended concepts that every programmer should know to be good at their craft.

I'm ~40 and going back for a CS degree isn't very appealing / practical. But if I knew what things to study... I could start on my own.

I'm advanced in my career, but its been mostly advanced level support and system administration work. I want to get into programming.

I say all that to make the point that a degree track isn't the best fit for me.

Re: Programmer Competency Matrix

#84

I'm not sure this has anything to do with "competency". When I was in high school, I implemented a kd-tree for a ray tracer using photon mapping. I knew that my n^2 algorithm was slow and that there was probably a better way, so I Googled and figured out how to write code for such a structure. Since I'm not a programmer (I'm a chemical engineer), I don't instantly know all of the orders of various algorithms (which a…

> I'm not sure being good at programming has much to do with having a whole bunch of CS knowledge; rather, it's being able to figure out what knowledge you need to know -- when you need to know it.

What I often tend to find valuable is not so much knowing what I need to know (although that's good too), but knowing what's possible. For example, there's really little need for me to be able to rattle off the code for a splay tree off the top of my head, but knowing its characteristics (and those of other data structures) is very useful - it allows me to match potential solutions to problems. All I then need to do is read up a bit more on the specific solution I have in mind.

I've found that this approach stops me reinventing the wheel too much, although it has also given me a slightly depressed view on many innovations within the computing world :-).

Re: Programmer Competency Matrix

#85

This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience…

If its title swapped 'Programmer Competency Matrix' with 'Computer Science Competency Matrix' it would make a lot more sense. Some of the level 3 competency ratings have little relevance in the real world.

Everyone in the programming world knows programmers (often intelligent, educated, and experienced ones) get caught up in silly details of perfecting their code and are completely unproductive without an experienced manager (or tutor) guiding them. I can't help but laugh when a bushy tailed non-programmer steps in, and produces something quickly and effectively using seemly simple tools.

Re: Programmer Competency Matrix

#86
post #80

Thank goodness B-trees are considered the most-advanced of the data structure knowledge. My com sci classes never did a great job of making those applicable.

B-trees are great! They have better locality than binary trees --- that's why filesystems are universally based on B-trees: seeks are slow. As cache effects become ever more important, B-trees are starting to become important even for problems that fit in main memory.

Re: Programmer Competency Matrix

#87
I land solidly in the right-hand column, particularly on the systems programming front: I've made major contributions to the NT kernel. I'm not sure this matrix has all that much significance: Google rejected me after the in-person interview: do they want people who can sort N items in O(1) time, work 30 hours per day, and create new scripting languages over lunch?

Re: Programmer Competency Matrix

#88
post #22

"Checks all arguments and asserts critical assumptions in code " Wait, I just finished code complete, and it told me that you specifically _don't_ check all arguments throughout your program. Instead, you choose a list of classes at that will check arguments for input as a firewall, and assume all classes behind those logically will receive the correct, sanitized input. Did I misunderstand this?

If you're paranoid (eg, programming embedded where it absolutely, positively, should not fail), you always check all arguments and return values. Sometimes libraries shipped from the vender are not perfect, sometimes the vendor's compiler will do something, ahem , unexpected with your return value in some edge case where you've exceeded the stack. I'll agree that wrapping with inlining is a good idea to make code rea…

> programming embedded where it absolutely, positively, should not fail [means] you always check all arguments and return values

Let's distinguish "checking" invariants, preconditions, and postconditions from blithely propagating logic errors as error codes all the way up the stack. If you're programming in "paranoid mode", as it were, and you detect inconsistent state, you should abort the program. If you don't, you're in uncharted territory and you have no idea how your program will act. If you abort the program and restart the system, you'll probably end up back in a useful state.

Many, many times, I've seen code like the following:

    HRESULT hr;
    hr = DoComplexThing();
    if (FAILED(hr)) { RaiseFailFastException (...); }
Say someone passes a NULL pointer to a function somewhere deep inside DoComplexThing's implementation that doesn't expect NULL. If this function helpfully "checks" all parameters, detects the NULL, and returns E_POINTER, E_POINTER will probably propagate all the way up the stack to the top level, where we'll abort the program. Now you have a crash report, but you have no idea where the problem actually _is_.

If this function had instead not checked the NULL pointer and crashed or explicitly asserted its preconditions instead of treating contract violation as a runtime error, the problem would be a lot easier to diagnose.

In general, you can separate problems into two classes: logic errors and runtime errors. Logic errors are indications of the program being written incorrectly. Your program should blow up when it detects one. Runtime errors are errors that could conceivable occur at runtime due to reasons outside the program's control (e.g., removing an SD card). Only runtime errors should be propagated using your error reporting mechanism of choice.

Re: Programmer Competency Matrix

#89
post #83

This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience…

I'd just like to see a list of some things that should be minimum / recommended concepts that every programmer should know to be good at their craft. I'm ~40 and going back for a CS degree isn't very appealing / practical. But if I knew what things to study... I could start on my own. I'm advanced in my career, but its been mostly advanced level support and system administration work. I want to get into programming.…

I'm 30, and have a computer science degree, and am log(n) on the chart in many areas (but certainly not all). In almost all cases, the relevant experience came from me trying to do a side project that required knowledge I didn't have. I can install a database because I had to. I can program in functional languages because I was reading about them and I tried to use one for a side project.

The side projects don't even have to lead anywhere, but they get you to the point where you can say "ya, I can write a node.js server" and then you can do it on the job, and a few years later you're an expert.

This is definitely not the only way to acquire skills. I'm sure some people dig through books, or just focus on doing their job and still grow. But for me, side projects have always been the driving force.

Re: Programmer Competency Matrix

#90
post #80

Thank goodness B-trees are considered the most-advanced of the data structure knowledge. My com sci classes never did a great job of making those applicable.

B-trees are great! They have better locality than binary trees --- that's why filesystems are universally based on B-trees: seeks are slow. As cache effects become ever more important, B-trees are starting to become important even for problems that fit in main memory.

And as data and disks grow, we'll see write-optimized structures like LSM trees and Fractal Trees in this matrix as well.
Post reply on HN