How to improve the quality of programmers

by Salvatore Iovene on 9 March 2007 — Posted in Opinions, Coding, Articles

After claiming that most programmers just can’t program, and actually addressing most of the problems to the lack of passion of people who decide to start a career as a programmer, I would also like to express my point of view on a tightly related subject: what can be done to improve the situation? The problem that I was trying to bring up in the spotlights, is that a lot of people just start (or wish to start) a career in the IT for no particular reasons. Those are the ones who don’t love and don’t loathe programming, and they just see it as something that pays their bills. Well, maybe the first question that I should address, actually is: why is this bad? Sure there are so many jobs which don’t require passion at all, and people just do them because a job is just a job, and don’t really care. In my opinion, being a programmer is different.

There are many people, especially the ones who sit high in the hierarchy of a company, who see programmers as the last and least important step of a ladder. They often think that programming is quite of an automated and repetitive task, and it could basically be done by anyone, with just a little training. Unsurprisingly, this seems to be the opinion of most common people, who ignore what programming really is. I wouldn’t want to discriminate among different types of programming, or different programming languages, but it’s obvious to me that programming, to some extent, actually can become an automated an repetitive task. That’s quite the minority of cases, though, so I will simply ignore them, and focus on the rest.

As anybody who’s a programmer knows, programming is a highly creative task, that requires good imagination and great problem solving skills. Everybody else might just see it as “typing stuff on a computer”, and believe me, there’s a whole lot of educated people who think that programming is a monkey matter. Hence the term “code monkey”. This term has historically been abused a lot, by even programmers themselves. A “code monkey” is said to perform a programming task so easy that even a monkey could do, as the image suggests. There are two truths about this phenomenon: first of all, luckily, programming requires far more skills than it’s usually believed; secondly, and sadly, the majority of people just ignore it.

The problem with lousy programmer is kind of similar to a medal: it’s double faced. You could actually call it a dog trying to bite its own tail: as programming is believed to be an easier and easier task, more programmers are needed; as more and more programmers are needed, more people will jump on the field; as more and more people try to become programmers, the lousier the average quality of programmers gets. Unfortunately, what average non-programming people miss to understand is that although it doesn’t really take a hard training to become a lousy programmer, it takes a damn hard one to excel in the art of programming. Moreover, most people just lack the innate logic mechanisms that make you a potential programmers. Such mechanisms are developed in your mind when you’re very young, and it’s quite rare to develop them after your twenty-somethings. With this, though, I’m not denying that there are a lot of people who actually do develop those mechanisms in advanced age. I’m just trying to think of the big numbers, here.

So, getting to the point, what went wrong and how can it be fixed? I don’t think it would be wise to say that what’s wrong is that there’s too much need of programmers, ergo the average quality was inevitably doomed to lower and lower over the time. I rather think that the problem is with education. Of course I can’t speak for all the universities and colleges in the world, but I can at least try and speak for the one I’ve known personally, or through people who have studied there. It seems that, as more and more people apply to Computer Science or related departments, the easier it gets to get in (sorry for the pun), and to get through with it, i.e. to graduate.

I know this happens most likely in any other faculties, but seeing that there are people who have been studying CS for three or more years, and still can’t get through the most simple concepts, just doesn’t seem right to me. Yesterday night, I was sitting in an IRC channel about the C programming language, when somebody joined in and asked:

“I just started studying structures in C, and I don’t get them. Can anyone explain to me what’s the use for them?”

Ok, I don’t really think there’s anything wrong in not getting the point of C structures right away, but after a little chatting, it turned out that the guy was in his second year of Computer Science, and this was the second time he took the C class. Still that wouldn’t be a reason of hatred, of course (not that I have any hatred), but after another small while it turned out that the guy didn’t like programming at all, but he just got himself into it because he applied to CS since he liked to “fiddle around with computers”.

What’s really needed, in my opinion, is a harder and less tolerant educational system, that would be more selective, rather than pushing everyone forward. People that find out to be really not made for it, should just give up and move their focus on something less.

I’m actually very well aware that a lot of programming work, nowadays, is not really rocket science, still this doesn’t mean that it should be done by completely unqualified people. If what Jeff Atwood says in his post about programmers who can’t program is true, and that is that 199 out of 200 applicants (not programmers, applicants) can’t write any code whatsoever, than it obviously means that something is wrong. Looking at the numbers provided by Joel Spolsky, it looks like a lot of these basically incompetent people are going to end up working on an actual programming job, and maybe their code will end up on The Daily WTF (Paula, are you there?).

Unfortunately, the education is not the only one to blame. No matter how much education will improve, there will always be unqualified people who are going to apply for jobs that require a lot of skills, and in the end the odds will help them, so they’ll manage to get a job as a programmer. Is it so bad, considering that it’s most likely not going to be any critical position, and the only ones that will be damaged will be the owners of the company that hired them? Well, the point is that this is not true. There’s someone else who gets damaged, in this scenario. I’m talking about the community out there, the good programmers, who find themselves competing with newbies who’re happy to earn peanuts. The salaries keep going down, and customers are not able to distinguish a good job from a good one.

In a comment on the previous post of mine about this subject, Hoowie Goodell really gets a great point with this paragraph:

“There has been a great effort to industrialize programming, too. Again, there are many good features, and it’s a field I’m interested in. Building a large program requires a structured approach. Language design, libraries, programming frameworks and IDEs can and should incorporate as much existing human knowledge as possible — computer science, domain knowledge, solid pre-written code and human interface principles. (Check out Thomas Greene’s “Cognitive Dimensions of Notations” for some of the latter — I think of how programming tools fail to use them on a daily basis!)”

In a way, this suggests that the whole system is not ready yet, as it’s indeed years and years behind several other engineering fields, and that’s a good reason, probably, to explain why it’s so easy to fail at being a good programmer. Let’s just try to get some insightful inspection points, in order to build better generation of programmers:

  1. Better education.

    The whole higher educational system should be improved in several way. Worldwide. Nowadays, it looks to me that in many countries graduation is just a direct consequence of applying to an University. Unfortunately, this kind of problem must be addressed on a country-basis, to properly identify the specific issues, but still the options that I would like to consider are worth mentioning. It all comes down to a single point: there should be less tolerance towards people that don’t learn. The thresholds for succeeding in a course should be raised to greater difficulty. Current models of testing should be seriously revised, so to ensure that students that really didn’t understand the subject are not going to make it.

  2. Better tools.

    Are we trying to make programming just like a building-chain or are we not? If we are, as it seems nowadays, then the tools are not ready yet to second our intentions. Programming is too error prone and too time-consuming.

  3. Better process.

    Software process that doesn’t conform to some standards, say ISO-9000 (sorry if it’s inappropriate, I’m not an expert on this kind of standards), shouldn’t be allowed to sell. Quality insurance committees should be taken more seriously as being part of the process. This might be against all principles of liberalism, I know, as bad software, you may say, will not sell anyway. I know many bad software that did sell well, for greatly different reasons than its (non) good quality.

  4. Better judgment when hiring.

    I’m not going to try to teach you how to run your company, nor how to hire your crew. But sometimes really crazy thing happen (again, is Paula around?). A very interesting post by Joel Spolsky (I’m sorry, I can’t find it anymore: does anybody know the link?) talks about only hiring “A”-people, where “A” means top class. If you’re ever hiring a “B”-person, he’s quite likely to hire a “C”-person, someday. After that, it’s chaos. I recommend anyone not to lower their canons of perfections. Here’s another great article by Joel, about hiring good developers, I recommend it.

Concluding, improving the quality of programmers seems really to be a tough issue, and the whole thing depends on so many factors that tracking a precise problem is impossible. Cultural and technical difficulties arise all the time, and getting clues is hard. I’ve tried to get around the problem and give some insightful opinions: what do you people think?


Get new articles via email

Related posts:

Why most programmers are lousy

by Salvatore Iovene on 8 March 2007 — Posted in Opinions, Coding, Articles

I’ve been in the IT field long enough to get to know many programmers, both experienced and just wannabies. During this time, I’ve realized that most of them are just bad programmers, simply said. I find myself agreeing with a brilliant post by Jeff Atwood, which alleges that programmers can’t program. What are the reasons for this? Many. Probably, IMHO, the main fault has to be addressed to the lousy education that people receive. But then again, the ability of giving education remains directly proportional to the ability of getting it, and where I see people complaining about low quality of education in University, I also see students with no interest in learning. Let’s see some of the reasons why programmers can’t really program.

  1. Young people study Computer Science just because it’s a trend. It sounds almost unbelievable to me, but I must admit it’s mostly true. The vast majority of my old University mates just applied to the Computer Science department because… well: everybody was doing so. They followed the rest of the sheep.
  2. Young people study Computer Science because they wouldn’t know what else to do. That’s really another strong source of applications to Computer Science. A lot of young people in their teenage years just don’t know what they want to do as grownups. Computer Science still seems to be a good career opportunity, so they just go for it.
  3. Young people study Computer Science because they think it’s a sure way of getting a job. 10-something years ago there was a big boom, and if you just knew some HTML, were thought to be a computer guru. These types of belief mark a deep footprint on popular sayings, hence the wave of people applying to Computer Science just because they can work, is still there.
  4. Many of today’s programmers, were doing nothing else than surfing the net or using Word till last year. Especially in small and vertical based markets, improvisation just rules. People learn something, and literally throw themselves on the field. Drawbacks for quality of their work are simply inevitable. This is not only a group of illiterate people that just jumped in to catch the big wave (what big wave, nowadays?), but people with no passion whatsoever. In other words, I don’t think it’s possible, nowadays, to become a great programmer if you didn’t start getting some interest in the field when you were very young, say about 10 years old (with the due exceptions, of course).
  5. Many of today’s Computer Science students have no interest whatsoever in what they’re forcefully studying. Just put together the previous items in this list and what do you get? A bunch of people who just don’t care, who want to get their piece of paper (the degree) as soon as possible, and have absolutely no passion in what they learn. That’s the worst. I strongly believe that programming is not just a job like many others, but you need passion to get best at it.
  6. A lot of programmers just don’t like to program. This goes for 100% of my ex University mates! Think of that: 100%. Of course it’s not the whole world but it makes a small statistics.
  7. A lot of programmers just don’t get it. Not even the easy things. I was asked, few weeks ago, by a friend of mine who’s been studying Computer Science for now 4 years, what the difference is between a private and protected method in Java. Apparently reading the books isn’t enough anymore, nowadays. Another guy asked me: “I’ve studied pointers in C, and I think I understood them. Still I can’t find any use for them… are they really used at all?”.
  8. Basically all of the programmers, or wannabe programmers, mentioned above, are miles away from the technical community. These people will totally ignore the existence of:
    • Slashdot and similar
    • RSS
    • Usenet
    • IRC (“Is that like MSN?”)
    • SVN and similar

As you can see, a really strong point, in my opinion, is the lack of care and passion for the subject of programming itself. Lousy programmers are bound to program to take a wage home; good ones are bound to program for the sake of programming itself. Or course you can do that but still miss to be a good programmer, but all falls down to numbers.


Get new articles via email

Related posts:

The ultimate guide for UTF-8 in irssi and GNU/Screen

by Salvatore Iovene on 6 March 2007 — Posted in Howtos, Articles

I’ve been having quite a lot of trouble, lately, configuring irssi to work well with UTF-8. Irssi’s documentation was quite incomplete, on the matter, or discouraging, and there wasn’t much on the Internet, so, after figuring out what the way is, I’ll share it here.

First of all, you’ve got to make sure that your system is configured for UTF-8 locales:

bash-3.1$ locale
LANG=en_GB.utf8
LANGUAGE=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=en_GB.utf8

If the output of the locale doesn’t look like that, you want to reconfigure your locales. On Debian, wha you have do is:

sudo dpkg-reconfigure locales

Here’s some screenies of what to expect:

dpkg-1.png
dpkg-2.png
dpkg-3.png

Generating locales (this might take a while)...
  en_GB.ISO-8859-1... done
  en_GB.ISO-8859-15... done
  en_GB.UTF-8... done
  en_US.ISO-8859-1... done
  en_US.ISO-8859-15... done
  en_US.UTF-8... done
Generation complete.

Perfect, now that our system is configured for UTF-8, we want to configure our terminal emulator. If you’re using xterm, you can invoke it with the -u8 switch, or just do uxterm, and that’s all that’s needed. If you’re using the gnome-terminal, go to the Terminal menu, then choose Set Character Encoding and then UTF-8. If UTF-8 doesn’t appear in the list, you may want to try to logout and login again. While you’re at it, in the GDM login manager, go to the Language option and choose UTF-8 there too, so that it will be default.

Now let’s take care of GNU/Screen. In order to enable UTF-8, all you have to do is launch it with the -U switch:

screen -U -S irc

irc is just the name I want to assign to that screen session. Notice that if you want to switch a living screen session to UTF-8, you could do it for each window, using the command CTRL-a : utf8 on.

Once your GNU/Screen is configured for UTF-8, you have to finally set up your irssi client. This was, for me, the tricky part, since the documentation is a bit unclear, and I didn’t realize that my irssi wasn’t built with recode support. To make sure that your irssi is, fire it up and give the command

/recode

If you get something like

Target                         Character set

then everything is alright, otherwise, if you get a No such command error, you will have to reinstall irssi with recode support.

Irssi UTF-8 support is made so that you are able to recode to different charsets, depending on the server or channel you’re chatting in. First let’s set up some general options:

/set term_charset UTF-8
/set recode_autodetect_utf8 ON
/set recode_fallback UTF-8
/set recode ON
/set recode_out_default_charset UTF-8
/set recode_transliterate ON

These options will be the default, unless overridden for specific servers or channels. What do they mean?

  • term_charset: this is the character set of your terminal emulator
  • recode_autodetect_utf8: irssi will recognize UTF-8 input automatically and treat it consequentially
  • recode_fallback: when we get some non-UTF-8 text from a chat peer, the text should be converted to this character set
  • recode: this enables the whole recode thing
  • recode_out_default_charset: this is very important: this is the default charset that you send out, unless differently specified by a server/channel rule (we will see that shortly)
  • recode_transliterate: this enables transliteration of the closest match: i.e. if someone sends you a character that’s not in your charset, it will be transliterate to the closest possible one, or with a question mark, if none found

Now, you probably need different recodes on different channels, because you may speak different languages on different channels. For example, I send out UTF-8 when typing on English speaking channels, and ISO-8859-1 or ISO-8859-15 when typing on Finnish or Italian speaking channels, so people on the other end will always get my characters right.

You need to add rules with the /recode command:

/recode add ircnet/foo ISO-8859-15
/recode add ircnet/bar ISO-8859-1
/recode add freenode/gee ISO-8859-1

Those command will make you “speak” ISO-8859-15 on #foo on IRCNet, and ISO-8859-1 on #bar and #gee in freenode. Everywhere else you will “speak” UTF-8.

And this is what we get: here I’m typing (er… I’m copy-pasting from Wikipedia) some text:

irssi.png

If you connect via SSH to a remote machine, where you run irssi inside screen, all you have to do is to set both systems to use UTF-8, as explained in the beginning of this article, and then set the terminal of the machine from which you SSH, to use UTF-8, as explained earlier.


Get new articles via email

Related posts: