Today ESSE I takes on the guise of the MythBusters duo, the iconic popular-science TV show whose hosts debunk common beliefs. We will do the same, but in the field of IT, and in particular programming.
Indeed, over more than a decade of experience, we have found that there are many myths about coding that can lead to misunderstandings, mistakes or bad habits that ought to be corrected. We have picked ten, the ones we consider most common and significant.
1) Code must always be commented
It is well known, and we stressed it in a previous article, that comments can help explain code, especially when it is complex. This widespread emphasis on the importance of comments might suggest that every single line of code needs one.
But that is not the case: code should be written so that it explains itself, which on its own would make any further comment unnecessary. In practice, comments are important but should be used sparingly and only when needed. Over-commenting code can make source files needlessly heavy and even risks making them harder to read.
2) Programming is only for the young
In IT circles – and elsewhere – there is still the idea that programming is only for young nerds and that after a certain age a programmer should stop, as if they were no longer fit for the job and were somehow obliged to hand coding over to the new generation.
This is a myth, because programming is a career open to people of all ages. There is no age limit for learning to program; in fact, the opposite may be true: a good programmer is often recognised by experience rather than by expertise alone (although the latter is very important). It follows that a senior developer (senior in skills, but also in age) tends to be preferable, from a company's hiring point of view, to a junior programmer.
If anything, we think that if today's job market hires more young people than older ones, it is because the former certainly expect lower salaries. But that is another matter (we would like to stress, though, that at ESSE I this matters little to us, because we hire anyone who is good, regardless of age: apply here to work with us).
3) Programming requires a computer science degree
Let's be clear: a degree in computer science can be very useful. The same goes for a degree in computer engineering (such as that of our CEO Massimiliano Aiello – here is an article where we had a chat with him). And it is certainly no coincidence that we recently hired Giorgia, who also holds an engineering degree.
But if we browse the public CVs (on LinkedIn) of many successful people in the industry, we will notice that they often have no degree at all.
We believe there are many effective online resources for learning to program without necessarily getting a degree, although we still recommend training at recognised, reputable institutions (perhaps not the quick 50-euro course bought online). And above all gaining experience, because beyond qualifications, that is what truly makes a good programmer.
4) Coding is an innate skill
How often do we say someone is "a natural" at something? Natural talent undoubtedly exists, but believing that programming is an innate skill is wrong.
So what does programming mean? Programming is the activity of creating a sequence of instructions written in one or more languages that a computer can understand and execute. It is therefore an analytical process that can be learned.
Of course it is not only that, because creativity and intuition play an equally important role, but these soft skills can also be developed and trained. In short, anyone can learn to program, and you don't need to be a genius to become a good developer.
5) Speed is everything
There is a widespread idea that when coding you should focus heavily on code execution speed, making it as lean as possible.
Writing code like this is certainly a good thing; the trouble is that it can lead to errors and code that is hard to maintain.
So what should you do?
In our view, speed matters above all where certain routines are executed many times, all the more so if the server load demands it or if the number of users running the code at the same time is significant.
But in a different context, for example software run locally by a few users with few resources, writing performance-oriented code can prove completely pointless and even counterproductive, given the reduced readability, clarity and maintainability that ultra-optimised code may have.
6) Copying and pasting code is wrong
Many still believe that everything written in a program must be entirely your own work.
Yet reality is very different, because it is well known that programmers reuse existing pieces of code or libraries. Let's face it, copy and paste is a very common practice, so believing that copying and pasting code is always wrong is not true: it is probably another myth to debunk.
What matters, rather, is understanding what you are doing, that is, how the code is being copied and pasted, and above all giving due credit to the original authors. Online there are many open source libraries and third-party source code that can be reproduced freely without needing to credit the author. But that is not always the case, and we would do well – not least to avoid penalties if we were found out – to respect the authors' wishes, citing and linking them in our credits where appropriate.
And then there is artificial intelligence, with generative AI tools such as ChatGPT that now churn out pieces of code (or even entire programs) in seconds when given the right prompts. Here too, copy and paste is far from wrong in itself, but it must be used with awareness and ethics if you don't want to harm others or yourself.
7) Programmers are loners and antisocial
The figure of the programmer has always been associated with the bespectacled nerd shut away in their bedroom with mouse and keyboard, and therefore with the idea of a solitary, antisocial coder. This idea rests on solid ground, since programming is an activity that requires deep immersion and concentration: it is hard to write good code without "shutting out the world".
However, we think that since this activity became social, this myth can be debunked too.
Communication and teamwork are now essential in software development: online collaborative platforms (which we discussed in this article on social coding) are bringing more and more programmers out of their bedrooms – or rather out of their offices or, if working remotely, wherever they happen to be – to program together.
And therefore to open up to the outside world much more than in the past.
8) Security is someone else's problem
Let's say it: for years many programmers wrote code worrying only that it worked, without considering security. A typical mistake was often not taking enough care over database connections, exposing systems to "SQL injection" attacks, in which an attacker injects malicious or manipulated SQL commands into a web application in order to access or alter data in the underlying databases.
Fortunately, in recent years, thanks also to growing awareness of the issue, most programmers have understood that cybersecurity is the responsibility of every programmer, not only of specialists in the field.
It has been understood that, although creating 100% secure code is pure utopia, prevention is better than cure, and that security cannot be added later but must be considered before even writing the first line of code.
9) All bugs can be eliminated
Obsessing over fixing bugs may be pointless.
Just as it is not possible to create completely secure software, it is not possible to create software that is completely bug-free.
The goal every programmer should pursue is rather to keep bugs to a minimum and handle them effectively when they arise. The next and final point can help with this.
10) Testing is unnecessary
Last but not least, we close this list of myths with a prejudice that is still widespread: the one that leads people to underestimate the code testing phase.
When software is finished, an inexperienced programmer, carried away by enthusiasm, might think it can go straight into production, but not testing your own code is a serious mistake, because testing is essential for detecting bugs (although, as we have seen, it is impossible to eliminate them all) and defects in the software.
Relying solely on fixing things afterwards based on users' feedback is a mistake to avoid, because it can damage the credibility of the software house, and therefore its brand reputation.
A bug can always slip through, but skimping on testing can lead to the discovery – with the public embarrassment that goes with it – of much more than a single bug.
By debunking these 10 myths we think we have suggested some good practices to correct as many programming mistakes (and mistakes of approach). We are convinced that in this world – the IT world in which we are totally immersed – there is still a lot to do, especially regarding awareness and ethics, but with our motto "harmony, not just bits" we believe we are on the right track.
What do you think?
Are there other common beliefs in the coding world that you think should be debunked? Let us know with a private message or a comment on our social channels! And if you enjoy our articles, don't forget to subscribe to our newsletter.
