Why is programming so hard?
Hi, Habr!
In February, we published a translation of the cool article " Why Learn to Program So Damn Hard? ", Which is now showing to newbies. Yes, learning to program is a whole story, long, with a bunch of different stages, with emotional ups and downs. We all went through it (or even go through - keep it up!).
Unfortunately, there is no such moment when you can stand up and declare that “I have finished my studies and now I am a programmer!”. You will have to study all your life, and all your life you will encounter unknown problems, face completely incomprehensible situations and ask “what the fuck is this ?!” even being a professional programmer with many years of experience.
')
Today we are publishing a translation of the note “Why is programming so hard?”. Those who are still learning the basics of programming and development will find it helpful to know what awaits them in the future. And experienced developers will just be nice to look at reality and leave their heads.
Many years ago, I thought that programming was easy, but years passed, and I realized that it was not. All because of the wrong perception of what I thought was programming and what kind of work the programmer does.
At first, I thought that programming was just to tell the computer what to do, this part of the process is relatively easy. After more than twenty years of experience, I really came to the conclusion that this part of the programming is fairly easy.
Definition 1 : The program is what converts the source data into a result.
A programmer is a person who writes a program, and programming is the process of writing this program.
Now let's add a few conditions to my program definition.
Definition 2 : A program is something that transforms the source data into a result and depends on the following conditions:
With these additional conditions, programming becomes extremely difficult. For a specific task, some of these conditions can be relaxed. Several typical scenarios suggest themselves.
Sometimes we write programs just for the sake of result. In this case, the source data and the program itself do not require support in the future, so they may not be excellent or described in detail.
My book on Erlang is an example. As soon as the book was published, support for the source data and the program that produced the book were no longer necessary. The result looks great, but the source data is a mess of XML files and small test programs that you never need to support.
Errata and corrections, which were necessarily made in copies, will only lead to small changes in the original data. They are easy to fix, even if the source data for the program is not well documented.
For supported programs, everything is the opposite of the last scenario. The baseline data for the program and the program itself must be excellent and well documented.
Recently, I spoke with a specialist who develops web applications. He said that as soon as the result of the program looks correct (that is, the website looks normal and the program is working), the customer decides on the completion of the project, and the project managers assign it to the next one.
They have neither the time nor the understanding that it is necessary not only to make the website look good, but also the code that makes it up has been cleaned and documented before the next project begins. This is for projects that require support in the future.
There are three things that make programming challenging:
Let's look at these difficulties - the real thieves of time.
Often I have to use software that is not written by me and which I don’t really understand in order to solve a specific problem.
At best, the program, which I should use, has a convenient instruction for use. But it often happens that the program does not have instructions at all or is described poorly.
What if the documentation says “do XYZ, then you get PQR”, you do “XYZ”, but “PQR” does not work? If you are lucky and those who wrote the program are somewhere nearby, you can go and strangle them, and if you fail, you can try to find the answer in Google or dig through the code in search of an answer.
Using Google Roulette to fix bugs is terribly annoying. I google a little bit and very soon I find somewhere a sad post from someone as unfortunate as I, who has run into a problem that is completely identical to mine. My heart beats in anticipation. With shaking fingers, I introduce a magic formula that will break the curse, and ... nothing. The problem does not disappear.
How can it be that the fix works for some people, but not for me? Is there a vile deity somewhere that is watching me, or am I in some particular place in the universe where the laws of physics have temporarily changed? No, just the initial state on different devices is different, so the fact that fixing a bug on one will not necessarily fix on the other.
Sometimes I want to program in SmallTalk, so that we all start with the same software image — SmallTalk programmers have to live in such a heaven where this cannot happen, but one day their programs should start talking to other programs, and then the fun will begin .
This problem, by the way, is the very thing that takes away my maximum time, I think, 60-70%. Once I spent about a week trying to deal with a broken LDAP server (my boss forbade me to use my own LDAP server), but after a week of battles with a broken server, badly documented and written in C, I had a memory failure, so I forgot what the boss told me and accidentally installed the server on Erlang from scratch during the lunch break.
Truth be told, it was not a full LDAP server, but I didn’t want a full one. I wanted a few teams to work, which turned out to be easy to fix.
Now I can’t find any pleasure in using archaic and perverted protocols, but often the easiest way to change something is to reinstall them from scratch.
I'm lazy. I'm great at messing around. But when I want to make a diagram in LaTeX, I do not want to read the 391-page instruction. I know that now you accuse me of being lazy and that I am morally corrupt, and I know that I must first read friendly instructions, but I want to have a chart in a document within 10 minutes, excluding the 391-page instruction.
When I solve problems, I resort to the method of quick solutions, but in the long term - this is a disaster.
Take, for example, the creation of documents. I could not choose between TeX / LaTeX and XSLT-FO and my own Erlguten.
About once every three years I have a strong desire to write all my documentation in a postscript, and then all I have to do is take a deep breath and wait until this desire disappears.
I think Giambattista Bondoni, when he created his Manuale Tipografico in 1818, was not particularly concerned that the layout of one page would take several weeks. But now, when we have much more time, because we can force the machines to do boring and dangerous work, we have no time left to do something qualitatively.
I asked the boss if he would like “cute slides” for the next presentation, he agreed, on condition that I make them by tomorrow. But there is no time left to learn TeX (and I think it will take a year or so), as it did not remain to use its own layout language (which would take five to ten years) and in order to write it directly in PostScript (for a week or so). So, apparently, PowerPoint ...
If you've read this far, you will understand that I find programming damn complicated. That is why jobs are designed to make programming more complicated. We have open offices that provide a noisy environment for breaking down concentration, mobile phones to bother us and the Internet to distract us.
Fortunately, we have a place where we can go so as not to be distracted. Sleep. Many software problems are solved while you sleep.
There are two ways:
First : you load the brain with problems, then you fall asleep, and the next day you wake up, and some of the problems are solved. Easy.
Method two : you post a problem on the Internet, or write a tweet about it before going to bed, and the next day someone sends you a solution via email.
To become a good programmer you need a lot of time: you need to get a lot of information, and know who to contact if you are stuck.
When I finished this article, I wanted to check spelling. Emacs-Ispell mode decided to strike. He could not find aspell, the program that I use for spelling.
My emacs spell checker has faithfully performed its function on this device for several years. And so, just when I complained that I spend half my life correcting bugs that shouldn't have happened, emacs decides to break.
I do not believe in vile deities, or that the laws of physics differ in the left corner of the sofa in my living room, where I type this text, although there is indirect evidence that this is so.
I see no reason why my spelling controller could break - everything is in order, I have not changed anything. Well, I installed a new version of Erlang and Julia, wrote several lectures, after the last time I checked the document for errors.
Fortunately, eleven minutes on Google Roulette helped. The second post on how to fix my problem worked, and I still do not know why emacs could not find aspell, and life is too short to figure out why.
I think there are things that we will never know about.
Translation: Natalia Bass / Hexlet.io
In February, we published a translation of the cool article " Why Learn to Program So Damn Hard? ", Which is now showing to newbies. Yes, learning to program is a whole story, long, with a bunch of different stages, with emotional ups and downs. We all went through it (or even go through - keep it up!).
Unfortunately, there is no such moment when you can stand up and declare that “I have finished my studies and now I am a programmer!”. You will have to study all your life, and all your life you will encounter unknown problems, face completely incomprehensible situations and ask “what the fuck is this ?!” even being a professional programmer with many years of experience.
')
Today we are publishing a translation of the note “Why is programming so hard?”. Those who are still learning the basics of programming and development will find it helpful to know what awaits them in the future. And experienced developers will just be nice to look at reality and leave their heads.
Many years ago, I thought that programming was easy, but years passed, and I realized that it was not. All because of the wrong perception of what I thought was programming and what kind of work the programmer does.
At first, I thought that programming was just to tell the computer what to do, this part of the process is relatively easy. After more than twenty years of experience, I really came to the conclusion that this part of the programming is fairly easy.
Definition 1 : The program is what converts the source data into a result.
A programmer is a person who writes a program, and programming is the process of writing this program.
Now let's add a few conditions to my program definition.
Definition 2 : A program is something that transforms the source data into a result and depends on the following conditions:
- The result of the program is excellent.
- The baseline is excellent.
- The program is excellent.
- The source data are well documented with high quality.
- The program itself is well documented with high quality.
- The program is well tested and executed correctly.
- The problem to be solved is clearly detailed.
- The task is clearly detailed.
With these additional conditions, programming becomes extremely difficult. For a specific task, some of these conditions can be relaxed. Several typical scenarios suggest themselves.
Programs that do not need to be supported
Sometimes we write programs just for the sake of result. In this case, the source data and the program itself do not require support in the future, so they may not be excellent or described in detail.
My book on Erlang is an example. As soon as the book was published, support for the source data and the program that produced the book were no longer necessary. The result looks great, but the source data is a mess of XML files and small test programs that you never need to support.
Errata and corrections, which were necessarily made in copies, will only lead to small changes in the original data. They are easy to fix, even if the source data for the program is not well documented.
Programs that need to be supported
For supported programs, everything is the opposite of the last scenario. The baseline data for the program and the program itself must be excellent and well documented.
Recently, I spoke with a specialist who develops web applications. He said that as soon as the result of the program looks correct (that is, the website looks normal and the program is working), the customer decides on the completion of the project, and the project managers assign it to the next one.
They have neither the time nor the understanding that it is necessary not only to make the website look good, but also the code that makes it up has been cleaned and documented before the next project begins. This is for projects that require support in the future.
What else complicates programming
There are three things that make programming challenging:
- Correction of problems that should not have been at all.
- No time to learn new
- Bad atmosphere for programming
Let's look at these difficulties - the real thieves of time.
Correction of problems that should not have been at all
Often I have to use software that is not written by me and which I don’t really understand in order to solve a specific problem.
At best, the program, which I should use, has a convenient instruction for use. But it often happens that the program does not have instructions at all or is described poorly.
What if the documentation says “do XYZ, then you get PQR”, you do “XYZ”, but “PQR” does not work? If you are lucky and those who wrote the program are somewhere nearby, you can go and strangle them, and if you fail, you can try to find the answer in Google or dig through the code in search of an answer.
Using Google Roulette to fix bugs is terribly annoying. I google a little bit and very soon I find somewhere a sad post from someone as unfortunate as I, who has run into a problem that is completely identical to mine. My heart beats in anticipation. With shaking fingers, I introduce a magic formula that will break the curse, and ... nothing. The problem does not disappear.
How can it be that the fix works for some people, but not for me? Is there a vile deity somewhere that is watching me, or am I in some particular place in the universe where the laws of physics have temporarily changed? No, just the initial state on different devices is different, so the fact that fixing a bug on one will not necessarily fix on the other.
Sometimes I want to program in SmallTalk, so that we all start with the same software image — SmallTalk programmers have to live in such a heaven where this cannot happen, but one day their programs should start talking to other programs, and then the fun will begin .
This problem, by the way, is the very thing that takes away my maximum time, I think, 60-70%. Once I spent about a week trying to deal with a broken LDAP server (my boss forbade me to use my own LDAP server), but after a week of battles with a broken server, badly documented and written in C, I had a memory failure, so I forgot what the boss told me and accidentally installed the server on Erlang from scratch during the lunch break.
Truth be told, it was not a full LDAP server, but I didn’t want a full one. I wanted a few teams to work, which turned out to be easy to fix.
Now I can’t find any pleasure in using archaic and perverted protocols, but often the easiest way to change something is to reinstall them from scratch.
Problem solving without new knowledge
I'm lazy. I'm great at messing around. But when I want to make a diagram in LaTeX, I do not want to read the 391-page instruction. I know that now you accuse me of being lazy and that I am morally corrupt, and I know that I must first read friendly instructions, but I want to have a chart in a document within 10 minutes, excluding the 391-page instruction.
When I solve problems, I resort to the method of quick solutions, but in the long term - this is a disaster.
Take, for example, the creation of documents. I could not choose between TeX / LaTeX and XSLT-FO and my own Erlguten.
About once every three years I have a strong desire to write all my documentation in a postscript, and then all I have to do is take a deep breath and wait until this desire disappears.
I think Giambattista Bondoni, when he created his Manuale Tipografico in 1818, was not particularly concerned that the layout of one page would take several weeks. But now, when we have much more time, because we can force the machines to do boring and dangerous work, we have no time left to do something qualitatively.
I asked the boss if he would like “cute slides” for the next presentation, he agreed, on condition that I make them by tomorrow. But there is no time left to learn TeX (and I think it will take a year or so), as it did not remain to use its own layout language (which would take five to ten years) and in order to write it directly in PostScript (for a week or so). So, apparently, PowerPoint ...
Bad atmosphere for programming
If you've read this far, you will understand that I find programming damn complicated. That is why jobs are designed to make programming more complicated. We have open offices that provide a noisy environment for breaking down concentration, mobile phones to bother us and the Internet to distract us.
Fortunately, we have a place where we can go so as not to be distracted. Sleep. Many software problems are solved while you sleep.
There are two ways:
First : you load the brain with problems, then you fall asleep, and the next day you wake up, and some of the problems are solved. Easy.
Method two : you post a problem on the Internet, or write a tweet about it before going to bed, and the next day someone sends you a solution via email.
To become a good programmer you need a lot of time: you need to get a lot of information, and know who to contact if you are stuck.
Amazing fact
When I finished this article, I wanted to check spelling. Emacs-Ispell mode decided to strike. He could not find aspell, the program that I use for spelling.
My emacs spell checker has faithfully performed its function on this device for several years. And so, just when I complained that I spend half my life correcting bugs that shouldn't have happened, emacs decides to break.
I do not believe in vile deities, or that the laws of physics differ in the left corner of the sofa in my living room, where I type this text, although there is indirect evidence that this is so.
I see no reason why my spelling controller could break - everything is in order, I have not changed anything. Well, I installed a new version of Erlang and Julia, wrote several lectures, after the last time I checked the document for errors.
Fortunately, eleven minutes on Google Roulette helped. The second post on how to fix my problem worked, and I still do not know why emacs could not find aspell, and life is too short to figure out why.
I think there are things that we will never know about.
Translation: Natalia Bass / Hexlet.io
Source: https://habr.com/ru/post/260949/
All Articles