I am a software engineer who has been developing software in java for more than 25 years. I think by now I have acquired some experience and I would like to share what I think are the 5 rules for a good programmer. I’m talking about rules of behavior, I’m not talking about patterns, best practices, techniques, but what a programmer must do for ensure that his work experience is positive for himself and for his colleagues.
Rule number 1: write neat code.
Writing neat code means writing code that is beautiful to look at, even before it works! That it is indented well, formatted well, with meaningful variable names. This helps yourself develop working code and helps your colleagues maintain your code.
And It also help yourself to maintain your own code because even just a week is enough to forget why, for example, you wrote a function that way.
And having tidy code speeds up the remembering process and reduces bugfix anxiety.
It seems trivial but it is not because you are often caught up in haste, tiredness, not having understood the bug correctly, the boss breathing down your neck, the customer angry that he wants the fix in no time. Neat code helps the mind to relax and understand how to intervene to carry out the task assigned to you.
I have rarely seen neat code from my colleagues. But the few times I’ve seen neat code, the author of the code has always turned out to be a very good programmer. Then of course there are some good programmers who write messy code, but that doesn’t make his colleagues’ job easier.
Rule number 2: respect the conventions.
Complying with conventions speeds up the search process of a thing in the project. It means respecting the naming conventions of the entities (variables, methods, classes, packages), the use of packages, the structure of classes.
For example, if I’m developing a web application with MVC patterns and the CRUD controllers have the methods named createForm and create, if you need to develop a new CRUD, your controller will also have createForm and create methods.
If I have to develop a utility class and the utils package is there, where will I put my new utility class? In the utils package… of course!
If in all classes the static methods are at the end of the class, also in my new classes the static methods will be at the end of the class.
If there are any conventions that are obviously wrong, talk to your boss about them to see if they can be refactored, otherwise you still have to abide by them.
Rule number 3: avoid unsolicited refactoring and bugfixes.
It often happens that looking at the code to do maintenance, you find some badly written code or you find a bug, in parts of the code that have nothing to do with the task you have to do carry out.
Avoid engaging in unsolicited refactorings and bugfixes. This is especially true for projects that are already in production.
The rule is that any modified line of code, even the simplest one, can hide the insertion of a bug. So if you find badly written code, repeated, buggy, in parts of code that have nothing to do with what you’re doing, report the matter to your boss but don’t intervene directly.
Rule number 4: don’t be a know-it-all and a complainer.
The more complex a project is and has been in production for years, the more likely it is that over time the code has become a mess. Many people have worked on it, with tight deadlines, with unclear requirements, without the necessary experience.
So arriving on a project, finding problems (almost always…) and complaining, doesn’t help anyone. It’s not useful for yourself, it is not useful for your colleagues who most of the time are not responsible for the messes that are there.
Nor openly declare that you never would something like that, that’s not the right way to develop, etc etc etc, doesn’t help anyone. Indeed the next time you will be the author of a buggy code (and sooner or later it certainly happens…), you will only increase the hatred towards you.
Your boss is definitely aware of the problems. Unless he asks you for an opinion himself, don’t complain about the mess you find!
Rule number 5: Communicate with respect.
If your boss asks you to do a task a certain way and you disagree for various reasons, tell them so, but respectfully. What does it mean? That you can repeat yours disappointment at most 3 times. But if your boss insists you do something his way, the third time you tell him about your displeasure, do it his way.
If you really aren’t convinced of what he’s telling you, there are two cases: either your boss is stupid or you are the stupid one. In any case you have a problem! If you can you are 100% sure that your boss is wrong and he doesn’t want to understand, better change boss (looking for another job)!
Being a developer is really a tough job.
You either love it or you hate it. But even if you love your job, with these 5 rules you can turn your experience into a success! If despite respecting these 5 rules your work will be a disaster, the only thing to do is… change job!
Giancarlo Parma 