Script Kiddies

The Answer: It's In The Code

Last time I checked, there were three types of computer programmers: the script kiddy, the typical software engineer, and the abominable console programmer. With little doubt, the latter two know what they are doing. The first, though, is easily the most unusual concoction of the late nineties.

By my definition, a script kiddy is a wannabe programmer with some inkling of software engineering, is usually fluent in at least one scripting language - Perl, Python, JavaScript, ASP, PHP, etc - and has some passing familiarity with a compiled language. Script kiddies emerged because there had been a high demand for computer savvy programmers who could make whiz-bang doohickeys with the latest technologies and products. And, by commanding the obscene salaries that accompanied the .com bubble, they worked into their heads the notion that they were an authority and an important part of the company.

Well, the .com bubble burst and I've noticed the trend in engineering has been to RIF the script kiddies. Good riddance, too, because I couldn't stand their arrogant rhetoric. Ask a script kiddy a question, and you won't get a fanatical explanation, or cock-and-bull story about why the answer is beyond you; the script kiddy figures that since they know how to write code, so must you. And the answer to your question must be: "it's in the code."

At one point, I was brought to the point of excruciating misery by the abominable console programmers' inability to speak in laymen's terms. However, I eventually learned to speak some of their jargon, and now just ask them for the name of the header file (C/C++ projects) and work from there. But, just as I had found a way to garner information from the one extreme, the script kiddy revolution took off and I found myself confronted with a new level of hypocrisy. On the one hand, script kiddies are supposed to know the ins-and-outs of the language they are working with, and they usually do. But, on the other hand, they possess the same remarkably inability to explain what they are doing. Hence, their answer is to direct the questioner in the wrong direction. If they had gone to college, or at least finished high school, they should have gotten this method of reply out of their system.

There is a reason developers don't care to ferret out specifics from the code because said code is typically a complete mess. I don't put my curly braces on a new line, I use tabs and not spaces, and I have never gotten around to putting spaces between my conditions and when setting values. Plus, I have my own naming convention all worked out. I call it: use what the rest of the company uses, or label the damn thing based on what it does. However, script kiddy code is an utter nightmare, mostly because they have no concept of structuring their application. I may call an object CustomerList, and the script kiddy code would have it labeled as CaptainKirk. It doesn't take a genious to figure out that they gave no forethought to design.

I remember working with Curmudgeon Rollup on a project and I had to find a bug in an overly complex project written entirely in a scripting language. No other software engineer would touch this project because it should have been written in a real language; meaning one with syntax checking and a compiler. And, the project was a complete jumble of tacked-on features. After giving me an exasperating explanation on why he was so busy working on new projects and how he didn't have time to do everyone else's job (the bugs were in code he had written), Curmudgeon finished with: "it's in the code."

It's an interesting story on many levels. First, Curmudgeon felt like he had to micromanage the project because nobody else could figure out the bugs in his code. Second, he thought he was such an amazing programmer, that he shouldn't have to spend time writing decent software and fixing his own bugs. Third, he honestly thought that anyone who was familiar with the language should be able to read his code.

Software engineers don't want to read other people's code: they want to write code. If they wanted to read code, they would be software testers or quality assurance engineers. And software engineers certainly don't want to try to decipher someone else's code because it is quite painful and nauseating, unless that code was written to a standard accepted by the team.

Responding to a question with "It's in the code" is a cheap, unintelligent answer, and it only serves to identify a person as a devout script kiddy, and above all else, not an engineer.