5 Facts About Programming You Probably Did Not Know

The task of programming is becoming increasingly common, but there are still many facts that people do not know about programmers and programming itself. This post features 15 little known facts about programming.

Like other intellectual activities, the task of programming and how people learn to program computers is well studied. In fact, with more and more people learning to program regardless of language, tool or platform used, it is natural that few people actually know about certain important facts about programming and software development.

From an academic standpoint, the areas of software engineering and education bring forward several very interesting studies obtained by experiments whose results are presented in masters’ and PhD theses. And based on these results I chose the facts mentioned in this post along with appropriate references. By the way, if you got interested to know more about each of the points discussed here I strongly recommend seeking the complete reference for more information.

Based on this context, I will present 15 important facts that, unfortunately, are little known by whom programs. But before, a warning: these facts present results of experimental and empirical research that have specific contexts. What I mean is that there is some room for discussion of the applicability and generalization, but knowing what has already been discovered and studied is important and, at least, can instigate discussion and how close that information is to the reality of the reader.

1) Developers slow to ask for help when facing problems

This is related to the way people learn how to program; basically, the act of teaching follows the line of learning Mathematics: a little theory, one or two examples and many exercises. This format takes learners to try hard on exercises and, quite often, to solve everything themselves without asking for help. This attitude is not bad and is even recommended, but you need to know to what extent should stop trying and ask for some form of help.

2) Programmers have a tendency to report their problems incompletely

This fact is related to Psychology field research. The results indicate that when a person has a problem he/she does not report complete information about the problem, especially when it is responsible directly or indirectly. This result has been confirmed experimentally with programmers and one of the main reasons is the following: to fully report a problem is seen as a sign of weakness that can lead to some kind of judgment of skill and proficiency by whoever is listening to the story. This situation is more common when it comes to a fundamental error committed by novices.

3) Developers seek other forms of help before talking to coworkers

The fact of communication with other people do not have priority when a programmer needs help again is related to the sense of judging of what other people do when they know the difficulty. However, sites like StackOverflow has flourished exploring this type of behavior by aggregating help in various aspects of communities for developers.

4) Progress in programming can be classified into 4 stages

The classification of a programmer progress is important to support multiple metrics involved in software development and also help project managers and other professionals to evaluate how good the project is as a whole.

Moreover, it is also important to know in which phase of the progress the developer is to, among other things, offer some kind of help so that he does not spend too much time stuck in a specific task to the point of delaying any deliveries. An interesting classification identified (automatically) four possible states of progress:

a) Complex Programming

b) Making Progress

c) Slow Progress

d) Stuck

5) Developers find beatable and unbeatable barriers

This may seem obvious, but it is very important to be detected, since a programming barrier can lead to serious term, team morale and confidence problems. One of the main difficulties of detecting barriers and classify them is the fact that this information may be subjective. In other words, asking directly to the programmer if he/she is with some beatable or unbeatable barrier already affects the result, as it can not always be sincere. There are also some implications in terms of ego and moral just by identifying this type of barrier on programming.

Share on Google Plus

About Unknown

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.