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
5) Programmers spend approximately 30% of the time surfing the source code
People who program know that most of the time relies on a editing source code tool. However, how time is divided between the editing tasks remains unclear from the scientific point of view. According to an important study, it was found that approximately 30% of a programmer working time is not spent editing the text (by including, editing ou deleting), but surfing between multiple files along the source code. The navigation involves research, observation, information gathering, memoring and other activities. That is, you could say that programming is an activity whose third part is just contemplative.
Reference: Andrew J. Ko et al. An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks. Journal IEEE Transactions on Software Engineering archive Volume 32 Issue 12, December 2006 pp. 971-987.
6) Remote programmer productivity is lower than the productivity of local programmers
This claim about productivity is controversial, especially when routines such as home office, remote working and global software development projects had become increasingly high. Anyway, there are concrete evidences based on several metrics of software that, in fact, remote programmers do not produce as much as programmers working together in the same place.
But it does make sense to think this way if we analyze the other facts of this list, for example, the preference for the lack of communication with other people. In fact, informal communication is a major factor that influenced the results of this research, because asking that hint in the meeting during a coffee break is very important according to what was found alone.
7) Costs of fixing bugs after implementation are 10 times higher than construction phase and 100 times larger than design phase
This fact is a classic of technology field and led to the evolution of traditional software development processes until what we have today. The main point here is the identification of high costs when there is a lack of attention to construction and design the software.
8) Peer code review can discover up to 60% of bugs
Code review made by other people, either in the form of pair programming or not, is really effective. There are many studies on this, but one of the key of them indicates that up to 60% of bugs can be discovered (but not necessarily fixed) when more than one person reviews the source code.
This study is relatively old and can be said that it is one of the key influencers of techniques involving agile process and other ways of developing software whose main focus is on activities, steps, organization and other skills not as technical as programming.