Have you ever seen THIS famous image?

The above hilariously realistic picture is what people will not tell you about software development because it is very difficult for people who are not developers to understand what it depicts.

Of course, the above image shows what the situation is when every single person involved in the process happens to be utterly incompetent. In reality, this is not the case (although it might be), but even so… having just enough incompetency can ruin your day.

And one incompetency that you cannot avoid is that of the customer not really knowing what they want and even if they do know that, they are usually incapable of describing it effectively. The first, last and second segments are almost unavoidable. This is not because the customer is stupid. This is because the customer is - usually - not a software engineer and/or the idea of what exactly they need is not really well formed yet in their head. So if you go with whatever the customer (sometimes that is you) is telling you without critically evaluating what that means or whether there is any need for that, you will likely end up with this:

The tricky part of this whole process is once the customer describes to you the first segment, you realize that what they need is the last segment, and describe it to them, convincingly enough for them to accept it. The convincing part is VERY difficult. The so-called feature creep is just pure evil…

Also, note that often as I said earlier, the customer is… yourself (say building in-house tools that you will need).

Often convincing yourself about what you really need is the hardest task of all.
In any case, if you can go from this:

to this:

you can avoid much of the ridiculousness of the in between.

Note that plenty of times, you were not involved in the above process whatsoever (or you were involved EONS ago, say, a week ago). You were hired to maintain the code of the project and then inevitably you have to confront the reality of this:

The lack of documentation along with the next thing that I will mention will probably consume the vast majority of your time. From personal experience, I can attest that you might be in the above position (looking at something incomprehensible that does not have a single comment anywhere whatsoever) even when you are looking at your own code. This is because sometimes, you are stuck for hours trying to find and then fix some bug, and eventually, you fix it with some sort of ridiculous half ass hack that you are half sure of what it does exactly.

Then since it works, the ugly “instant gratification” monster shows its face and you move on to what you REALLY wanted/needed to be doing in the first place. So the infamous temporary solution is there to stay:

eventually, you will DEFINITELY end up in a situation like the one below :/

No software developer will tell you that they are wasting their time trying to understand someone else’s code, especially when that someone else is their own self of the past.

You may be picturing developers typing code as if they are Hollywood hackers when in reality they are simply staring stupidly at the screen going: “WTF is this shit…”

Now you may wonder why if and when one finds the time don’t they actually DO something about it. Two reasons: first there is more than likely the case that they will never get the time. Second and immensely more probable is this thing depicted below:

So it is not as if there are no real reasons behind these VERY realistic situations that I am describing. There are plenty of reasons but of course, they are not good reasons. The time you saved doing this ugly shenanigan to fix that bug and the time you saved by not documenting it, will inevitably find you or someone else down the road - you do not get the time for free. But the point here is that these things are not glamorous. These are not the stuff that a developer will be talking about at a party when they talk about their work.

Now another thing that they will not tell you and which I personally hate with every fiber of my being is this badly defined recursive ridiculousness:

If you are not dealing with the lack of documentation that resulted from somebody else’s or your own short-sightedness or later-ism then you are dealing with the situation described above.
It is, of course, the reason behind all this aversion that developers have for changing code that works in the first place.

Usually, the bugs are neither obvious nor easy to fix once you realize what is causing them. I mean if it were an easy task, then having software with bugs would not be such an omnipresent situation. “Let he who has created software without bugs throw the first stone” is what Jesus would say if he were a software developer. This is what makes developers excruciatingly risk-averse. If it works their natural instinct is:

But in any case, often they HAVE to touch, and then you will have to debug

and while you are debugging and fixing stuff you will experience these feelings:

and WAY MORE OFTEN than you want to admit you will experience this:

Finally, one other thing that developers won't tell you is that during bug fixing tons, and I mean TONS of googling takes place. Like, literally after a certain threshold of frustration googling will be pretty much the only thing you will be doing. AND OMG IS THE FOLLOWING SITUATION FRUSTRATING:

Again, no software developer will be talking about the desperation that one can feel once you find people with the same exact issue, and NO answers or… the OP returned just to say “oh I fixed it… all is good”. They are giving you the finger from the past.

Now let me show you some real-world examples of the above, taken directly from code which was shipped with CA’s Total War Warhammer II. It is in Lua, but it does not matter whether you know Lua or not, you will understand anyway:

Let me zoom in a bit :

Note that much of this code is sort of ctrl-c ctrl-v generated and plenty of functionality is identical to that of previous games, all the way back to probably Shogun 2. Apparently, they keep waiting to get a better interface.
In their code you will find commented methods like this:

Which is a real-life example of this:

And another one of those that are so often randomly encountered into some constantly evolving code:

Here is some of their code with its documentation:

am, bm, being locals, being globals, having the most descriptive names possible…. we are talking about sheer beauty. This is probably an example of this:

It is called documentophobia.

And you can tell that different parts of the code were done by very different people. For example, compare the previous code picture to the following one:

We go from not even a single character of comments to more documentation than code (which is good).

There are tons of examples like that to be found in Creative Assemply’s code and they can demonstrate almost all of the examples I have talked about.
Note that I did not mean to pick on these guys, in fact, if you go over their code you will find it remarkably… not very frustrating.
Here is some code of mine… WITH comments from the past (in Java)

I do not have the slightest idea as to what I am talking about even though I have commented extensively as it seems. Also, it seems that not only I was reluctant to change code, but I was also reluctant to change comments. I took it to the next level. This last example demonstrates how difficult it is for developers to get into the mindset of someone else (or their future self’s) who is not familiar with wth is going on. Quite clearly all these comments made much sense to me at some point. However today, they could be written in Mandarin (which I cannot read or speak) and it would make no difference.

So these issues, that I have discussed are the issues consuming the vast majority of a developer’s time… and yet, NO developer will ever start talking to you about these things. They will be quite content to let you believe that what they do is something like this: