Why programmers suck

A long time ago I wrote an article on the topic “Why computers are crap” (eventually called “Computers” and “ What's wrong with computers ” [ in the original link is broken, therefore a copy from the web archive - translator comment ] in two other versions, and the original name never appeared). The article was quite long, but the point was that the computer was a mess, because programmers create the wildest complex things that no one else can understand, and that complexity is based on more complexity, until everyone aspect of the program will not become unmanageable.

KDV from here

What I did not know then is why programmers do it. It was obvious that they were doing this; but why does the software industry create so much wild, complex, and unreadable code? Why does this continue even after the seemingly developers had to learn a lesson from the first negative experience? What made programmers not just write bad code, but keep doing it again and again?

Well, it was a mystery to me, but somehow I was not particularly worried about this at the beginning. The idea that “bad programs appear because of bad programmers” is so simple and obvious that it served as the basis for the whole research in the field of programming, which ultimately had good results (which are mainly described in this blog, and is also the subject book, which is now in the process of writing). The problem was identified (bad programmers who create difficulties), and, at first glance, she had a solution (to create software development rules that would prevent it), and that was enough for me.

But, as before, I was not bothered by the fact that world-famous universities, technical schools and educational programs produce such terrible programmers, despite decades of experience in teaching software development techniques. Of course, many of the principles of program design have never been kept confidential, and a lot of good advice is just there, and many of them are very general in nature. Even if people did not go to school, did they really not read a single such advice?

Well, the truth was beyond my imagination, and it took almost five years of work in the Bugzilla Project with the participation of a huge number of developers so that one day I suddenly realized the terrifying fact:

The vast majority (90% or more) of programmers have no idea what they are doing.

Not that they did not read about software development (although most likely not). Not that programming languages ​​are too complex (although it is). The fact is that most programmers have no idea what they are actually doing. They simply imitate the mistakes of other programmers — by copying code and typing more or less intelligent spells on a computer in the hope that it will behave like what they expect, without having a real understanding of either computer mechanics, software development principles, or value each individual word and character that they enter into the computer.

This is a bold, shocking and insulting statement, but my experience confirms it. I personally reviewed and evaluated the code of dozens of programmers. I read the code of many others. I have spoken to many, many programmers about software development, and have read articles from hundreds of developers. The number of those who really understand what they are doing is only about 10% of all programmers I have ever spoken to, worked with, or heard about.

Open source developers are the best of the best; these are people who want to program even in their free time. And even then, I would say that only about 20% of open source developers are really well versed in what they do.

But why is that? What is the problem? How can it be that in this industry there are so many people who have no idea what they are doing?

Well, it looks like they are kind of "stupid". But what is nonsense? People do not become stupid just because they do not know something . There are many things that not everyone knows. But that does not make them stupid. This makes them ignorant of certain things, but not stupid. No, stupidity, real stupidity - it means not knowing that you do not know something . Stupid people think that they know something, although they do not know it , or they don’t realize that the field of knowledge is much broader than they think .

This “nonsense” is something that can be found in almost any field, and software development is no exception. Many programmers simply do not realize that there may be some laws or general principles of software development, so they don’t even try to find them. Many software companies have not made any attempt to improve their understanding by the developers of the programming languages ​​they use. Perhaps this is because management believes that programmers should "and so know all this, once they were hired to do it."

Unfortunately, this view is harmful in software development, because if you want to be a really good programmer, you need to know a lot . Anyone who believes that he knows everything (or who has a “blind spot”, because of which he does not see what else there is something to learn) —means his ideal code in the absence of knowledge — knowledge, about the existence of which they don’t they know , and do not even know about the fact of lack of knowledge .

No matter how much you know, there is always something else in any field, and programming is no exception. So to think that you know everything - it is always wrong.

Sometimes it is difficult to determine what you need to learn. There is so much data, but where to start? To help with this, I came up with a couple of questions that you need to ask yourself or others to figure out which areas require additional study:

• Do you know everything you can about every word and every character on every page of your code?
• Have you read and fully understood the documentation for each function you use?
• Do you have an excellent idea of ​​the basic principles of software development - so good that you could explain it to novice programmers in your organization?
• Do you understand how each component of the computer functions, and how they work together?
• Do you understand the history of the development of computers and how they will develop further, to understand how your code will be executed on computers created in the future?
• Do you know the history of programming languages ​​in order to understand how the language you use evolved, and why does it work that way?
• Do you understand other programming languages, different programming approaches and computer types other than what you use to understand which tool is best suited for each task?
• Top down are the most important things for a programmer to understand what code he is writing. If you can honestly answer “yes” to all these questions, then you are definitely a great programmer.

Perhaps the length of the list looks depressing. “Wow, read the documentation for each function? Yes, it will take a lot of time! ". Okay, and you know what else will take a lot of time? Become a good programmer without reading the documentation. And you know how much? Eternity , because this will never happen.

You will never become a good programmer simply by copying someone else's code and praying that it will work for you. But what is more important is to invest time in learning and it means to become a good [ programmer - approx. translator ]. Time spent now will make you a much faster programmer in the future. If you spend a lot of time reading during the first three months of learning a new technology, you will probably be 10 times faster over the next 10 years than if you just rushed to use it without reading anything.

I want to clarify right away - of course, it’s impossible to just read for three months and become a good programmer. First, it’s too boring - no one wants to cram a theory for three months without having any practice. Few people will be able to do this long enough to become a programmer at all, not to mention the fact that he is immediately good. So, I want to immediately note that understanding comes from practice , and not just from theory. But without studying theory, understanding may not appear at all . So it is important to find a balance between practical programming and the study of theory.

I am not attacking any programmer here, with whom I worked personally, or at any particular programmer in general. I admire almost every programmer I've ever known as a person, and I expect to admire the others if I meet them. Instead, I urge all programmers to open their mind to the new, for the fact that there is always some new knowledge, that theory and practice are the key to mastery, and that there is nothing shameful in not knowing something - if you know about the fact that you don't know something. Just take the time to find out when you need it.

From the translator: I tried to translate in a literary style, so perhaps some of the statements or ideas from the original were distorted because of the desire to make the translation more readable. If so, please do not drive with pissing rags, and write in a personal.