When you’re going to modify existing records of a database table it is common to first SELECT them to see how they are and only then UPDATE them with what they will be.
When I get to a new project the system administrator generates a development key for each development system assigned to our SAP username. Usually it’s sent to me by e-mail. Usually I lose track of it.
Picture yourself as a monkey hanging from a tree branch. You want to jump to another branch but it’s so far away that you cannot see it. If you jump you’ll probably fall to the ground. That’s bad.
In the last years of the previous century, an SAP project manager stubbornly opposed to upgrading the SAP system. Instead, he decided that all the SAP notes belonging to that upgrade were to be manually implemented. All 1000 of them.
When ABAP programmers run into a LOOP they like to use it to get as many things done as possible. Even if that LOOP ends up having hundreds or thousands of lines.
ABAP evolves (even though it stood mostly still for too many years). And as it evolves, it leaves behind some commands and syntax constructions which are replaced by better ones.
Besides learning what’s new it is also important to learn what becomes obsolete.
When a program is bad because it has duplicate code, it usually becomes shorter once we rewrite it to make it better. But, if its problem is not being properly structured into several classes and methods, if we rewrite it according to the best practices, it will probably end up longer.
Unfortunately that is not what happens in most of the Z code I have seen in my life as an ABAP programmer. Both IFs and LOOPs tend to grow bigger than anyone can deal with. I recently ran into a LOOP with over 1500 lines.