

Things web developers should know - olind
http://www.netmagazine.com/features/10-things-web-developers-must-know-become-truly-amazing

======
irahul
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.

------
chucknelson
The statment "A really great dev can debug problems on a system without seeing
a line of code" is a bit overreaching. Yeah, "debug" as in "I can tell
clicking this button is the problem!", but nothing specific enough to be truly
useful.

Also, anyone else bugged when a title/headline sounds like marketing?
"..become truly amazing"? Sounds like a commercial...

~~~
Hopka
Yes, the title actually violates HN guidelines as it begins with a number,
contains a "gratuitous adjective" and is, in my opinion, linkbait:
<http://ycombinator.com/newsguidelines.html>

------
cmdkeen
Hmm...

Developers definitely need to fit the "be human" requirement - that helps you
actually converse with users to find what they need. But wants and needs are
different - and you need to be able to find what they actually need/want - not
what they think they do. Because otherwise you can create a monster system
that is incrementally better than what they already have.

But CS degree type developers shouldn't be overlooked. It is simply not true
that "everyone can code" - self taught is not always a good thing. If you're
coding anything that needs to properly scale, run on limited hardware etc then
you need someone who has a grounding in the subject.

------
Paul_S
I'm getting tired of all this huggy feely advice on how to connect with your
inner user. I guess if you're a hip and with it developer selling, errr, I
mean providing solutions and positive experiences this is all valuable and
thought provoking advice.

If you're just a simple programmer, turning curmudgeon, you'd rather connect
with your database and that's the sort of thing you'd like more advice on.

------
SkyMarshal
Meh. The more exhaustive, cannonical list:

[http://programmers.stackexchange.com/questions/46716/what-
sh...](http://programmers.stackexchange.com/questions/46716/what-should-every-
programmer-know-about-web-development)

------
jeffehobbs
#1a. Don't waste your finite time and attention reading "#X Things" lists! :)

