Sigh. Another fluff piece - n things crap, coupled with the know-all attitude.

> I get CVs with people with computer science degrees, AI courses, various media and coding under their belt but there's still something missing

Yes, sure. If your job is making websites for local boutiques, AI courses aren't much use to you. But there are multiple scenarios where you need someone who has studied, say, statistics and AI for some time, and has implemented a number of concepts. Unlike your "need to show a jQuery alert when the help icon is clicked", statistics and AI(and a thousand other things) isn't something you can google and copy paste.

> Make them sketch out what they're talking about.

I will punch you in the face, plain and simple. I don't sketch, I can't sketch. Never learnt it, have no plans to learn it. But that's not important. The important thing is I am not where to cater to your ridiculous whims. If a mock-up is needed, I will use balasmiq or something. That is my call.

> Get them to explain with pictures, objects and (it works) cut outs of people exactly what the system will be like for the humans using it.

And here we go from ridiculous to out right stupid. Cut outs of people? Seriously?

> I'm going to talk negatively about developers, but I think I'm allowed because I am one.

No, you aren't. You are allowed to talk - freedom of speech and stuff. But I didn't grant you the right to spew bullshit about me because we both are developers. Also, if your criticism has merit, it won't matter if you are a developer or not.

> Build tools; CI; git for version control were taken for granted, but looking back over CVs these hardly appeared.

The day a candidate is to be judged for a programming job based on whether he knows git or any other version control is a sad day. The basic flow(the one we use 95% of the time) is so simple someone can learn it in an afternoon and check-in code before leaving. And concrete experience? What do I write in my CV? I used git for 6 months and expand it using "my day consisted of git ci, git push; and git branch, git merge; and ..."?

> If it's Perl you use, understand how to install Perl modules and configure them.

If it's Perl I use, what are the odds I don't already know how to install perl modules? It isn't something specific to prod(HINT: You do use modules in dev as well).

> Debugging and testing is the 99 per cent of a developer's life

I don't know where you are getting this 99 per cent from, but debugging and testing isn't 99% of my time for sure.

> The are many books (sadly, not the one I pitched to the publisher I won't name) on debugging and every developer should read all of them.

Why would I do that? As far as debuggers go, I learnt gdb in the beginning, and almost every other debugger is a subset. I use the debugger to see where the error is occurring and what is the error, followed by thorough code scan. Some people check logs followed by code scan. Either ways, reading multiple books isn't going to help.

> Developers must be able to draw their ideas on whiteboard, paper and beer mats.

And as I said, I don't draw. Even if I did, I won't. When mockups are needed, I do that on a computer.

> Don't trust the developer who nods, says they've understands and opens up their editor.

If I understood the requirements, I am going to nod and get back to work. If you want mock-ups, provide it or ask for it.

> And what if you have to spend 10 hours solving a problem by moving a link around?

What if you have to get punched in the face repeatedly? Enjoy it.

/s

I will move that damn link, but am sure not going to enjoy it.

PS: Like a piece of chocolate hidden in horse shit, this article does have some good advice. But the horse shit is making it difficult to enjoy the chocolate(fluff headline - n things, patronizing tone, know-it-all attitude). May be I worded it a bit harshly.