June 23, 2015 at 11:01Why is programming so hard?
- Transfer
Hello, Habr!
In February, we published a translation of the cool article, “ Why is learning so damned hard to program? ”, Which we now show to beginners. Yes, learning to program is a whole story, long, with a bunch of different stages, with emotional ups and downs. We all went through this (or we still go through - keep it up!).
Unfortunately, there is no such moment when you can get up and say 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 hell ?!” even as a professional programmer with many years of experience.
Today we publish a translation of the note “Why is programming so hard?” Those who are still learning the basics of programming and development will find it useful to find out what awaits them in the future. And experienced developers will just be pleased to look at reality and nod.
Many years ago, I thought programming was easy, but years passed, and I realized that it wasn’t. This is all due to a misperception of what I considered programming and what kind of work a programmer does.
At first, I thought that programming was just telling 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 quite easy.
Definition 1 : A program is what transforms raw 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 some conditions to my program definition.
Definition 2 : A program is something that converts 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. A few typical scenarios suggest themselves.
Sometimes we write programs just for the sake of results. In this case, the source data and the program itself do not require support in the future, so they may not be excellent or detailed.
My book on Erlang is an example. Once 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 maintain.
Typos and corrections that were made in copies as necessary will only result in minor changes to the source 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 source data for the program and the program itself should be excellent and well-documented.
I recently 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 fine and the program works), the customer decides to complete the project, and the project managers assign it to the next.
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 forms it, be cleaned up and documented before starting the next project. This is for projects that require support in the future.
There are three things that make programming a challenge:
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 do not particularly understand in order to solve a particular problem.
In the best case, the program that I should use has convenient instructions for use. But it often happens that a program has no instructions at all or is poorly described.
What if the documentation says “do XYZ, then you get PQR”, you do “XYZ”, but “PQR” fails? If you are lucky and those who wrote the program are somewhere nearby, you can go and strangle them, but if it doesn’t work out, you can try to find the answer on Google or dig the code in search of an answer.
Using Google Roulette to fix bugs is terribly annoying. I google a little and very soon I find somewhere a sad post from an unfortunate person like me who ran into a problem completely identical to mine. My heart beats in anticipation. With trembling fingers, I introduce a magical formula that removes the curse, and ... nothing. The problem does not go away.
How can it be that the fix works for some people, but not for me. Is there somewhere a vile deity who is watching me, or am I in some specific place in the universe where the laws of physics have temporarily changed? No, it's just that the initial state on different devices is different, so what fixes a bug on one does not necessarily fix on another.
At times, I want to program in SmallTalk, so that we all start with the same program image - SmallTalk programmers must live in such heavens where this cannot happen, but one day their programs must talk to other programs, and then the fun begins .
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 figure out a broken LDAP server (my boss forbade me to use my own LDAP server), but after a week of fighting 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.
In truth, it was not a full LDAP server, but I didn’t want a full one. I wanted several teams to work, which turned out to be easy to fix.
Now I find no 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 can do a great job lounging. But when I want to chart in LaTeX, I don't want to read the 391-page instruction. I know that now you will accuse me of laziness and that I am mentally flawed, and I know that I must read the friendly instruction first, but I want to have a diagram in the document for 10 minutes, excluding the 391-page instruction.
When I solve problems, I resort to the quick fix method, but in the long run it 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 postscript, and then all that remains to be done is to take a deep breath and wait until this desire disappears.
I think Jambattista 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 that we have a lot more time, because we can get machines to do boring and dangerous work, we don’t have time to do something qualitatively.
I asked my boss if he wanted “cute slides” for the next presentation, he agreed, provided that I did them by tomorrow. But there wasn’t enough time to study TeX (and I think it would take a year or something), how was it left to apply your own layout language (which would take five to ten years) and in order to write it directly in PostScript (a week or so). So, apparently, PowerPoint ...
If you read up to this point, you will understand that I find programming damn complicated. This is why jobs are being designed to further complicate programming. We have open-type offices that provide a noisy environment for destroying 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 fall asleep, and wake up the next day, and some of the problems are resolved. Easy.
The second way : you post a problem on the Internet, or tweet about it before going to bed, and the next day someone sends you a solution by email.
To become a good programmer takes 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 the spelling. Emacs-Ispell mode decided to go on strike. He could not find aspell, the program I use for spell checking.
My emacs spell checker has faithfully performed its function on this device for several years. And now, just as I complained that I spend half my life fixing bugs that should not have been, emacs decides to break down.
I do not believe in vile deities, nor in the fact that the laws of physics are different in the left corner of the sofa in my living room, where I am typing 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 did not change 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 find out why.
I think there are things that we simply will never know about.
Translation: Natalia Bass / Hexlet.io
In February, we published a translation of the cool article, “ Why is learning so damned hard to program? ”, Which we now show to beginners. Yes, learning to program is a whole story, long, with a bunch of different stages, with emotional ups and downs. We all went through this (or we still go through - keep it up!).
Unfortunately, there is no such moment when you can get up and say 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 hell ?!” even as a professional programmer with many years of experience.
Today we publish a translation of the note “Why is programming so hard?” Those who are still learning the basics of programming and development will find it useful to find out what awaits them in the future. And experienced developers will just be pleased to look at reality and nod.
Many years ago, I thought programming was easy, but years passed, and I realized that it wasn’t. This is all due to a misperception of what I considered programming and what kind of work a programmer does.
At first, I thought that programming was just telling 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 quite easy.
Definition 1 : A program is what transforms raw 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 some conditions to my program definition.
Definition 2 : A program is something that converts the source data into a result and depends on the following conditions:
- The result of the program is excellent.
- The raw data is excellent.
- The program is excellent.
- The source data is well and clearly documented.
- The program itself is qualitatively and clearly documented.
- The program is well tested and runs correctly.
- The task at hand 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. A few typical scenarios suggest themselves.
Programs that do not need to be supported
Sometimes we write programs just for the sake of results. In this case, the source data and the program itself do not require support in the future, so they may not be excellent or detailed.
My book on Erlang is an example. Once 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 maintain.
Typos and corrections that were made in copies as necessary will only result in minor changes to the source data. They are easy to fix, even if the source data for the program is not well documented.
Programs you need to support
For supported programs, everything is the opposite of the last scenario. The source data for the program and the program itself should be excellent and well-documented.
I recently 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 fine and the program works), the customer decides to complete the project, and the project managers assign it to the next.
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 forms it, be cleaned up and documented before starting the next project. This is for projects that require support in the future.
What else complicates programming
There are three things that make programming a challenge:
- Correction of those problems that should not have been at all.
- Lack of 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 do not particularly understand in order to solve a particular problem.
In the best case, the program that I should use has convenient instructions for use. But it often happens that a program has no instructions at all or is poorly described.
What if the documentation says “do XYZ, then you get PQR”, you do “XYZ”, but “PQR” fails? If you are lucky and those who wrote the program are somewhere nearby, you can go and strangle them, but if it doesn’t work out, you can try to find the answer on Google or dig the code in search of an answer.
Using Google Roulette to fix bugs is terribly annoying. I google a little and very soon I find somewhere a sad post from an unfortunate person like me who ran into a problem completely identical to mine. My heart beats in anticipation. With trembling fingers, I introduce a magical formula that removes the curse, and ... nothing. The problem does not go away.
How can it be that the fix works for some people, but not for me. Is there somewhere a vile deity who is watching me, or am I in some specific place in the universe where the laws of physics have temporarily changed? No, it's just that the initial state on different devices is different, so what fixes a bug on one does not necessarily fix on another.
At times, I want to program in SmallTalk, so that we all start with the same program image - SmallTalk programmers must live in such heavens where this cannot happen, but one day their programs must talk to other programs, and then the fun begins .
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 figure out a broken LDAP server (my boss forbade me to use my own LDAP server), but after a week of fighting 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.
In truth, it was not a full LDAP server, but I didn’t want a full one. I wanted several teams to work, which turned out to be easy to fix.
Now I find no pleasure in using archaic and perverted protocols, but often the easiest way to change something is to reinstall them from scratch.
Solving problems without gaining new knowledge
I'm lazy. I can do a great job lounging. But when I want to chart in LaTeX, I don't want to read the 391-page instruction. I know that now you will accuse me of laziness and that I am mentally flawed, and I know that I must read the friendly instruction first, but I want to have a diagram in the document for 10 minutes, excluding the 391-page instruction.
When I solve problems, I resort to the quick fix method, but in the long run it 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 postscript, and then all that remains to be done is to take a deep breath and wait until this desire disappears.
I think Jambattista 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 that we have a lot more time, because we can get machines to do boring and dangerous work, we don’t have time to do something qualitatively.
I asked my boss if he wanted “cute slides” for the next presentation, he agreed, provided that I did them by tomorrow. But there wasn’t enough time to study TeX (and I think it would take a year or something), how was it left to apply your own layout language (which would take five to ten years) and in order to write it directly in PostScript (a week or so). So, apparently, PowerPoint ...
Bad atmosphere for programming
If you read up to this point, you will understand that I find programming damn complicated. This is why jobs are being designed to further complicate programming. We have open-type offices that provide a noisy environment for destroying 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 fall asleep, and wake up the next day, and some of the problems are resolved. Easy.
The second way : you post a problem on the Internet, or tweet about it before going to bed, and the next day someone sends you a solution by email.
To become a good programmer takes a lot of time: you need to get a lot of information, and know who to contact if you are stuck.
Surprising but true
When I finished this article, I wanted to check the spelling. Emacs-Ispell mode decided to go on strike. He could not find aspell, the program I use for spell checking.
My emacs spell checker has faithfully performed its function on this device for several years. And now, just as I complained that I spend half my life fixing bugs that should not have been, emacs decides to break down.
I do not believe in vile deities, nor in the fact that the laws of physics are different in the left corner of the sofa in my living room, where I am typing 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 did not change 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 find out why.
I think there are things that we simply will never know about.
Translation: Natalia Bass / Hexlet.io