Why isn't there a row for "figuring out how large, poorly-documented legacy systems work"? That's what most of my daily development tasks consist of, anyway.

Also, anger management.

I couldn't agree more. Unless it's a startup, or the company produces "throw away" solutions. You're usually dropping in on a product where either the previous team was fired or it was boot-strapped by one guy who knew was he was doing, supported by 5 junior devs fresh out of college.

Don't forget the oh-so-common "We've built our core library up over years of different products, so it's kind of a mess".

Unfortunately, most new stuff on e.g. github isn't much better in this respect. So this is a competence most programmers have.

Oh, god, not this "Indian TopCoder superiority guide" again.

Here's a previous discussion https://news.ycombinator.com/item?id=4626695 with links to 6 more discussions before that.

It's cute, five minutes to read, and easy to pass around, like an infographic. And, like an infographic, it's a kind of mental junk food.

This was first posted on hackernews here: https://news.ycombinator.com/item?id=232192

It's about seven years old now, and is showing its age in a few places. The version control like seems most in need of updating now - git is widely used.

This is a pretty handy guide to technical skill levels but I've found (over my 30+ year career) that these skills only comprise about 15% of being a successful software engineer (lower case).

Software engineering is all about communications: There communicating your desires to the computer which I'd estimate at the above mentioned 15%. And the rest which is communicating amongst a large enough team to create something useful (and many problems are bigger than a single person can solve). There's communicating with your future self - I easily forget my previous code by about six months out. There's also communicating with another future maintainer, which is somewhat harder than communicating with the future you.

Start-ups tend to disregard many of the skills (and related costs) of the remaining 85% because failing to successfully get to market and become profitable is deadly on it's own. But the successful start-up will eventually have to transition to a more maintenance/continuity/reliability focused organization and there are plenty of pitfalls during that transition. (Note that I realize there are wide variations in how that transition can occur).

At some point, any communications that was put off becomes technical debt ... and like the old commercial says - "You can pay me now or you can pay me later". Either way, developers that only know the technical skills on this competency matrix will either have a lot to learn or be out of work.

> Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP problems etc.

I'm pretty sure the author means "NP-hard" problems. And putting dynamic programming at the top of the algorithms tier is a pretty low bar. My guess is the author of this table isn't so strong on algorithms and hasn't explored what's beyond an introductory algorithms class.

Edit: the reason I say "pretty sure" is because there are a lot of people who work on practical problems that are not in NP because the problem does not have well defined solutions. But in the context of the rest of the table, the author likely did not intend to make this fine distinction.

Yeah, P != NP hasn't been proven, so identifying problems in NP that are not in P might be impossible! Maybe identifying exponential or higher-order functions would be more tractable :)

not loading for me

Google cache: http://webcache.googleusercontent.com/search?q=cache:qh2y61o...

I don't know about the experience part. I think it's dangerous to assume that the more years experience you got, the better programmer you are.

It has been a paranoid hypothesis of mine that the best programmers wind up programming people instead.

That doesn't have to be paranoid. That's exactly what good management is (also coaching). Done right, it's very valuable.

Unfortunately (or fortunately?) at least at the moment, it's outside my skill set...

But how do I know that I want my mind to be the way X wants my mind to be, without shaping it like that and biasing my assessment afterwards? How do I know whether I wanted my mind to be this way? How did my mind get this way?

I know it's paranoia but sometimes I think ideas are more like viruses in more than the colloquial internet memetic sense. Like the brain literally has difficulty letting go of ideas because of the ways various ideas may alter brain structure and consequently influence perception.

OK, I did not mean it like that. A good manager is not going to manipulate you in ways that are not for your own good (really).

Example: Say I have trouble finishing tasks assigned to me. A bad manager fires me. A different bad manager tries to manipulate me. A good manager works with me to help me learn how to get better at finishing stuff. Does that change me? Yeah, maybe it does. But unless I regard "the way I am right now" as the perfect standard for who and what I'm supposed to be, change isn't this thing to be regarded with paranoia. It's not something that you should desperately seek to undo, except that you can't quite figure out how to do so because you're different now. It's a good thing. (At least, it can be, done well by good bosses.)

Another example: My boss sees that I'm not good at Android. He sends me to some Android training. That changes my skill set, but not who I am in any fundamental sense. But my boss is still, essentially, programming people.

I understand your perspective and in the rational, everyday setting I agree with you. Thank you for your considerate reply.

Well, your perspective isn't necessarily wrong. There are people who will try to mess with your mind, manipulate you, even gaslight you. Some paranoia is warranted.

With that said, though, still don't lose your ability to trust...

Following on that analogy: Skepticism would be the immune system. Nihilism would be an autoimmune disorder.

I think its better to read that section the other way around: if you have 10+ years of experience, you should be in the level 3 bracket in (at least some) other sections. If you're a first year programmer, it might be acceptable to be in level one in other categories.

You can't even make it to level 0 unless you use an IDE. I guess you're level -1 if you're an experienced old person using "vi" and "make".

There is a level beyond what is shown on the chart: the mythical O(1), constant time, which those who speak of do not know, and those that know do not speak of...

Serves to feed ego of a programmer: "Done that, know this - oh, I'm pretty good" vs. "Done that, have no idea what this is - oh, I don't care, this post is bullshit! I know I'm a good programmer"

If you understand this matrix as a rough guideline, to identify the general areas where you might want to work on your skills, it is not without merit.

But I think the complexities of software development make it fairly hard - if not impossible - to view someone through such a two-dimensional lens. Kind of like an IQ test. Knowing how somebody did on an IQ test might allow you to tell a genius from an idiot, but for the wide grey area in between, it is pretty useless, and downright dangerous if people start taking it to seriously.

This is useful for every person who is beginning to learn programming in a hard way. Also, experienced programmers can polish their knowledge with this competency matrix. Thank you for this work!

This is such a terrible rubric. Where's the points for "doesn't write vulnerable software that an 8th grader could trivially exploit"?

Oh wait, India? My experience with India has led me to believe the country sits at "largely incompetent, with a few great folks": https://scott.arciszewski.me/misc/Linkedin/Fail.html

You have toremember there are ~1 billion people in India. So just playing the numbers game there are three-four times as many incompetent programmers there than in the USA. Of course, that doesn't mean India is 3-4 times worse than the States. Although, thinking about the maths for choosing a representative sample size from a population, it looks like for large populations the required sample size to get representative data will be equivalent. I don't know enough to work out how un-representative a small-N sample will be, with population size varying. Anyone?

So the site's not loading for me, but if it's what I think it is, I remember coming across this a number of years ago and feeling really shitty about my skills.

The only thing to feel shitty about is having wasted minutes of your life reading this fallacious rubric and then thinking it actually meaningfully measures developers.

Edited my post to say "years ago", since I missed it the first time. I agree now, and I brushed it off at the time too.

This is pretty handy - I found it pretty useful to help me find where my strengths (and weaknesses!) lie, just by reading off where I'm Level 3 and where I'm Level 2. :)

It also feels like a great and clear challenge to action to up everything to Level 3. :D

I'll probably end up showing this to all my friends starting off in our field. :D

This covers about 1% of what it really means to be a developer, and it does so poorly in a very biased manner. I'm being generous when I say 1%.

Perhaps[1]. It doesn't mean it's not a valuable or indicative 1%.

Moreso, this does a surprisingly good job of balancing between practical (vocational) skills and background knowledge.

[1]: though it depends what you work on - this happens to constitute a large portion of what's required for my work.

I dunno, if all of my co-workers were level 3 in all of these categories, subtracting the company, platform and publishing specific items, it would be a big improvement!

What is the other %99?

Does someobody have a nice printable version that doesn't look ugly when printed? I would love to hang this onto our wall in the office.

Not sure if making this into an Infographic is less work than creating a css style that allows printing it correctly.

this page, I looked for this page for years after finding it an unspecified amount of time ago. thanks. this is the page that kicked my introspection as developer and made me discovery code complete and so many awesome literature about software as engineering and not as development.

Did I miss it or is there nothing in here in relation to secure coding. Ship first I guess.

Unfortunately, secure coding is a specialty. Most software has the security requirements of a house, which is minimal at best.

What a BS Matrix

yay. another yardstick I can use to demonstrate my own ineptitude. solid level 1.5 of fail here.

Thank you for sharing these standards for being a better engineer.

Standards?

No, and your linked position paper from IEEE does not support your statement. Their position is that anyone with an ABET-accredited degree should be able to call themselves an engineer, and that licensure is required for the legally-protected titles.

My position may be antiquated (I became engineer in 1995), but still valid. ABET accreditation requires that a person graduate from an accredited program and degree, the only degree that applies here is Software Engineer. http://www.abet.org/uploadedFiles/Accreditation/Accreditatio... How many programmers are Software Engineers? Not many from my perspective as a hiring developer. So again I say Programmer != Engineer PS For a program to be ABET the instructors must be Professional Engineers (Pass the PE Exam) go figure: "The overall competence of the faculty may be judged by such factors as education, diversity of backgrounds, engineering experience, teaching effectiveness and experience, ability to communicate, enthusiasm for developing more effective programs, level of scholarship, participation in professional societies, and licensure as Professional Engineers. "

You specifically said engineers must be licensed. That is factually incorrect. It is also not the position of IEEE to make "engineer" a protected term (much to the chagrin of Canadians).

> ABET accreditation requires that a person graduate from an accredited program and degree, the only degree that applies here is Software Engineer.

Wrong again. First off, there are 271 ABET-accredited Computer Science degree programs. Holders of those CS degrees are eligible to call themselves engineers by the IEEE's criteria as well as to sit a PE exam. Second, the subject of the degree is irrelevant. I have a a Bachelor's of Science in Electrical Engineering, but have been an electrical engineer, systems engineer, and software engineer at various points of my career. I do not have to stop using "engineer" just because I lose the "electrical". I can sit for any PE exam I wish.

> (You) For a program to be ABET the instructors must be Professional Engineers

> (ABET) The overall competence of the faculty may be judged by such factors as ... licensure as Professional Engineers

How did "may" turn into "must"? I wonder how my university has been pulling the wool over ABET's eyes for so long, since most of the engineering professors are not PEs. Hell, I don't think some of them have any industry experience at all.

You are wrong about IEEE and ABET programs that can call themselves engineer. This is from the IEEE publication posted above: "It is our position that the title, “Engineer,” in the United States should be available for use by individuals who have graduated with an engineering degree from an ABET/EAC accredited program of engineering education (or its equivalent). " IEEE's position is you must graduate from a ABET accredited Engineering program. Computer Scientists are not Software Engineers.

...within the jurisdiction of Texas, surely due to lobbying from those who benefit from the PE situation. It's the same as how Tesla can't sell cars in Texas. It's Texas...

You might like that to be true but it simply isn't. I'd suggest to "keep trying" but really that won't change the reality of how the term is used.