Developer traps: how not to become “just another dumb programmer”

As time goes by, I can see some situations in wich developers get into are actually traps. That’s why I call those “developer traps”. The word “trap” was selected because those who are caught on one of these rarely scapes intact (usually the result is “just another programmer”).

Trap #1: Linguistic determinism

That’s my worst nightmare. For those who don’t know what it is, linguistic determinism is the idea that language shapes thought. Here is an example: we from Brazil know many types of bananas (nanica, serra dagua, caturra), but an english person usually can distinguish only one kind of banana: banana. Our vocabulary have many words to distinguish the kinds of bananas wich we have to deal. That’s the most basic example of all, but is enough to get us started on this issue.

How can we apply this to a developer? Simple: those wich only work on a single environment/programming language usually show huge difficulty in learning any other thing. Here is a good example: those who are used to work on a RAD environment like Delphi or VB (more specifically those wich only drag and drop some components on forms (nothing against Delphi or VB!)). When trying to learn some other language like Java or C++, their first reaction consist on the repetition of the same procedure that they are used to on their familiar environments. Obviously, with failure. It’s when we hear some of the most common complaints:

• “Language/Programming Environment X sucks!”
  Here we can see the guy trying to apply the same procedures of his original programming language on the new one. Of course it will fail! It’s not the same thing “genius”!
• “I’m more productive on language/environment X.”
  Here the problem is externalized. The subject is almost saying: “I can’t learn this new environment/language. It’s different from what I’m used to!”
• “Programming languages are all the same. Syntax is the only difference”
  Well, if that’s true, why so many languages??? Actually, in this case, there whould be only ONE programming language: the one the subject is used to work.

We can see an interesting aspect of who is caught on this trap: the arrogance. They use to blame the language/environment for all their problems, just forgetting one single fact: that language/environment had been used several times successfully on many projects around the world.

Trap #2: software = relational database management system

The subject don’t believe in development beyond CRUD. How to detect someone caught on this trap? Simple: just say anything about any data structure that is not a table or an index. You may go beyond on this experiment: ask the subject  to describe how any other data structure actually works (warning: you’ll create a new enemy). Even worse: ask this person if he can code anything without a database behind it.

Here is what happens: the subject works on an environment wich most of his demands consist on applications that are basically only CRUD. In this scenario, the most complex task consist on the creation of some kind of report. Actually, here we can see trap #1: linguistic determinism. But these two traps are slightly different: this trap is way more common (it’s a specialization of the above) and may create bigger losses than that.

The illusion is created because the feedback of a SQL query is instantaneous, the subject starts to believe that his job is finished on the creation of the forms wich displays the data. Things will only get strange for this guy when someone needs something more complex than that.  What is really amazes me is that these people are able to do incredible things using only SQL, but usually fails miserably when trying to do anything else.

Actually what we’ll see here is someone forgetting a very simple rule: data is the result of processing, not otherwise.

Trap #3: RAD evironments

The subject learn to code on a RAD environment and stick with it. It’s actually the result of traps #1 and #2 with one little addendum: the illusion that software development is easy.

I really hate how wrongly these tools are used. They are supposed to be used only for the execution of the boring and repetitive tasks, like GUI creation and basic CRUD, wich are only a small part of the process of software development, and not the bigger one. In this case, we can see the opposite: the subject can spend hours (sometimes DAYS) searching for new components to be added to his forms just to execute tasks that are beyond the simple CRUD, in this case ignoring completely other aspects of the process, like scalability, security, quality, etc.

How to detect someone with this problem? Just remove it’s IDE.

Trap #4: “donti speak english”

Sounds improbable, but the amount of developers wich just ignore the english idiom is huge! As a consequence, this crowd will never know what is being published at current time, just what will be translated (IF it will).

Trap #5: lazy readers

How can someone be good in something if it’s not reading about it? Simple as that.

Trap #6: fear of change

If anything changes around the subject, it just get crazy! Any change on a specification? Boom! A new crisis emerge! It’s what I use to call the autistic developer. This kind of developer can’t see the fact that change is what keeps his job! It completely ignore a basic fact about the world: everything changes. On V b.C Heraclitus was almost shouting: “panta rei (everything changes)”!!!

If things change in nature, why whould’nt they change on your work? Is it possible that after 2500 years people still can’t accept this fact?

In my opinion, this problem emerges from the false belief that software development is a kind of math when, in fact, it just uses some math to do the job. The other half of it is composed of human beings wich, as we all know, change all the time (sorry about that).

How to know if someone have this problem? Simple: change the color of his mouse or keyboard. He’ll go nuts!

Conclusions

These are the main traps I know. After discussing them, someone could ask me the following questions:

Why you didn’t mentioned any management traps?

Simple: how can you manage something you don’t know? These are the basic traps to be avoided to anyone wich have the slightly desire to manage anything related to software development.

How to avoid those traps?

Basically avoiding trap #1,  accepting diversity as a fact and, even more important: recognizing the fact that software development is a complex task.