Gentleman Developer Code
Most of the projects are developed by the development team. As a rule, the quality of the result of teamwork depends on the atmosphere prevailing in the team. To maintain harmony, every developer must always be a gentleman. Therefore, I want to present the main, in my humble opinion, the rules of the iOS gentleman's code.
I am an iOS developer myself and am part of the team. The rules are quite general, so they are suitable for any direction in software development and not only.
The gentleman developer is always polite
Your bad mood or megalomania is not a reason to spoil the mood of other people. I think no one will like it if he is rude. Therefore, try not to be rude yourself.
Lack of culture and rudeness spoils the relationship between team members, and in teamwork it is very important to work together. Resentment against each other or personal hostility can not only slow down progress, but also introduce additional problems.
Always and under any circumstances you need to control yourself and try to be polite.
A gentleman developer always respects his time, and therefore also respects the time of others
If you have an urgent problem that a colleague can help with, this does not mean that you need to distract the colleague from his work. Perhaps a very important thought process is going on right now, and if you interrupt it, then your colleague can waste a lot of time rebuilding the whole picture of the problem he was solving.
It is worth politely asking if the person you need can take the time and help you. If he is very busy, then most likely he will be able to help a little later.
A gentleman developer respects the code and technical solutions of his colleagues
You should always remember that each block of code is the best solution that the author could come up with at that point in time and under the circumstances when this code was written. Therefore, you should not once again arrange to find out why the code is written so badly. This applies to the moments when there is no need to change anything at all.
I think everyone can remember the moment when they tried to rewrite the code, which looked terrible. At the same time, I came across previously unobvious problems that this code solved. And in an attempt to solve these problems in a more elegant way, I wrote even more terrible code.
This should be remembered before ruining someone's mood with inappropriate criticism and refraining from such actions.
A gentleman developer does not edit another developer's code without their knowledge
Even if you know how to do it better, don't silently rewrite bad code. First, the author of the code, who, in the opinion of others, is responsible for this piece of code, may lose the thread of understanding in updates. And when trying to change something, he will find himself in a difficult situation.
Secondly, you yourself, most likely, do not know all the features of the functionality that you are going to rewrite. As a result, neither the author nor you fully know the code that was updated.
Thirdly, if the author of the code does not find out that he did something badly, then he will continue to do as he did. And as we know in a team, the result of each participant's work affects the entire team.
In such cases, you should first contact the author to clarify his opinion. Perhaps you are mistaken and your solution, which seemed more suitable to you, is not. And if you were right, then you will help your colleague and, accordingly, will help the common cause.
A gentleman developer does not criticize someone else's code without arguments and without alternatives
When it comes to criticism, and this is inevitable in teamwork, then it should be done correctly. First, you can criticize the code when the solution to your problem depends on the quality of this code. Secondly, you can only criticize if you know exactly how to do it better.
Pointless criticism only leads to discord in the team, which does not greatly affect the result.
A gentleman developer also knows how to take criticism with dignity
Nobody is perfect and nobody writes perfect code. We are constantly learning and improving our skills, including in software development. Criticism is one of the most effective learning mechanisms. And you need not only to be able to submit criticism, but also to accept it with dignity.
You should not react aggressively to someone else's criticism. This will only alienate those around you. And in the future, your errors in the code may not be detected in a timely manner only because a colleague did not inform you, not wanting to provoke a scandal.
If criticism is really useful, then you should thank the person who pointed out your mistakes.
If the criticism is not justified and you are absolutely sure that your solution in the code is good enough, if not even the best, then you should calmly argue your case. Give reasons to refute criticism.
A gentleman developer writes code in a generic style
I think everyone will understand the allegory that if there are several rowers in the boat and one of them row in the opposite direction, then this will only negatively affect the speed of the boat.
The same goes for projects. Try to always adhere to generally accepted rules and standards, even if you don't like them, but the commands follow them.