11 Principles that every developer should follow
I am a person who tends to live by the principle. In fact, they are mainly the principles that I set for myself, but those are still principles. I find that creating the principles for myself helps me to live and work better, because I have decided in advance what I need to do instead of going anywhere or not.
For example, should I go to the gym (gym) this morning? Yes, my principle says that on Wednesday I have to go to the gym and today is Wednesday, so I'll go to the gym, that's for sure.
This week, I'm thinking about some of the principles that I impose on myself, I think it might be a good idea to create a set of rules that I think all developers Software should apply in work and life.
Now, I will have to admit, most of these guidelines are guidelines, and I will list them below:
1. Technology is the way you find a solution, it is not a solution
We can really get the latest JavaScript framework – cool, Angular – IoC container, programming language or even the operating system, but all of these are not really solutions to their problems. We are trying to solve them as programmers, instead they are simply tools to help us solve problems.
We have to be very careful not to be too extreme about a specific technology that we like or it is popular now, or we will risk thinking about all the issues like a nail, just because we are holding a shiny hammer that we just learned about it.
2. Intelligence is the enemy of clarity
When writing code, we should try to write code so that it is clear and easy to understand. The code clearly conveys its purpose much more valuable than obscure code – it doesn't matter how smart it is.
This is not always true, but in general, intelligence is the enemy of clarity. Sometimes we write code that looks "smart", but that code is not particularly clear. It is important that we remember this rule whenever we think we are doing something especially smart.
Sometimes we write code that is both smart and clear, but often it rarely happens. If you are interested in writing clean code, I recommend you read the book The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin).
3. Only write code if you must write
This new reading seems a bit contradictory, after all, isn't the work of our programmers writing code?
Yes, actually the answer to this question is both "yes" and "no".
Our work may involve writing code, but we still need to try to write as little code as possible to solve the problem we are having.
This does not mean that we should make our code as compact as possible and name all our variables using the letters of the alphabet. Which means that we should try to write only the code when really needed to perform the required function.
Often you are tempted to add all kinds of features to your code or make our code "strong" and "flexible" so that it can handle all different situations. But most of us are wrong when trying to guess useful features or anticipating problems that we think might be encountered in the future.
The code that we added to anticipate future situations may not add any extra value, but it can still cause a lot of harm. Writing as much code as possible involves more risks of errors and the code also takes time to maintain.
Good software engineers don't write code unless it's absolutely necessary. Great software engineers often delete as much code as possible.
4. Comment in most code is not good
I'm not a big fan of commenting in code. I also agreed with Bob Martin, when he said:
"Every time you write a comment in code, you should grimace and feel your failure to express."
– Clean Code: A Handbook of Agile Software Craftmanship
This does not mean that you should never write comments in code, but for most cases they can be avoided and instead you can focus on improving the naming of your variables and functions. so it can express meaning better.
Comments should only really be written when you cannot explicitly convey the intention of a variable or method through their name. Comments serve for the code parts are not easy to express itself to its purpose.
For example, a comment can tell you about some strange activity that takes place in code but not an error, but the intention of the code writer.
In general, comments are not only harmful because in many cases they are very necessary, but sometimes they do not properly describe what the code that comes with it is being done.
Comments that are not updated with the accompanying code result in these comments becoming really dangerous, because they will probably drive you in a completely wrong direction.
Do you often check all comments against the code to make sure that the code is actually doing what the comment says? If so, what is the purpose of having those comments? If not, how can you trust that those comments are true?
It's a double-edged sword, so it's best to avoid using it as much as possible.
If you disagree with my opinion, leave your "comment" in the comment section below the article, but I will not change my position.
5. Always know what your code should do before you start writing it
This looks obvious, but it is not so.
How many times have you sat down to write code without a thorough understanding of what the code you're writing really has to do?
I have to admit that I myself have fallen into this situation many times, so this is a principle that I need to re-read often.
Test Driven Development (TDD) can be useful in this case, because you have to know what the code will do before you write it, but it still doesn't prevent you from creating the wrong things, so It is important that you fully understand the 100% functional and functional requirements you are building before embarking on it.
6. Check your code before handing it over
Don't throw your code to the Tester team as soon as you have finished writing, because people will send you a new error, and you will lose your time and everyone in creating bug reports. and unnecessary resolution.
Instead, take a few minutes to test your test scripts, before you think you've finished the job.
Surely you will not catch all the errors before moving your work to the Tester team, but at least you catch some silly and shameful mistakes again and again this time. another time.
Too many programmers think it's just the Tester's work with their tools. But that is not true at all. Ensuring product quality is everyone's responsibility.
7. Learn new knowledge every day
If you do not learn new knowledge every day, then you are actually falling backwards, because I'm sure you'll forget some knowledge while technology changes every day.
It will not take too long to learn new knowledge every day. Try to save just 15 minutes or longer to read a book, I read a lot of books last year, I spend 45 minutes on average every day reading.
The little progress that you make every day over time will give you a lot of great opportunities in the future. However, you must start now if you want to reap the rewards.
Besides, today's technology is changing rapidly, if you constantly improve your skills and learn new things, you will be left behind very quickly.
8. Programming is fun
Yes. You may not have decided to follow this industry just because it has a very good salary. I mean, there is nothing wrong with choosing high-paying jobs, a doctor's career or a lawyer, which could be a better option.
Most likely you become a software developer, because you like to write code. So don't forget that you are doing what you love. Writing code brings a lot of fun. I wish I had plenty of time to sit and write code.
I am often too busy to maintain my business but less time spent writing code every day, which is one of the reasons why I remember very clearly the endless joys that work write the code to bring.
Perhaps you have forgotten how happy it is to write code. Perhaps this is the time to remember the joys you had, by starting a side project or just changing your mind and realizing that you can write better code and even Lice are paid for that job.
9. You can't know everything
Interestingly, the more you study, the more you will discover that there are still many things that I don't know. It is important to recognize this because you may be trying to know everything.
It's OK if you don't get all the answers. It's also normal to ask for help or ask others when you don't understand something.
In many cases, you can learn about what you need to know at a time when you need to know about it – believe me, I've done it many times already.
My point is, don't try to learn everything, it's an impossible task. Instead, focus on learning what you need to know and building skills that help you learn everything quickly.
10. The best practice method depends on each situation
Is Test-Driven Development (TDD) the best method to write code? Should we always apply pair programming ? Do you feel inferior if you don't use IoC containers?
The answer to all these questions is "up to date". It depends on the context.
People will try to push best practices down your throat and tell you that they always apply them – that you should follow them as well – but, that is simply not true.
I have followed a lot of best practices when writing code, but I also set conditions to know when to apply and when to not. The principle is forever, and best practices will depend on the specific situation.
11. Always towards simplicity
All problems can be broken down to solve. The best solutions are usually the simplest ones. But simple does not come easily. You have to work hard to make things simple.
The purpose of this blog is to make complex issues in software development and life more simple.
Believe me, this is not an easy task. Any idiot can create a complex solution to a problem. More effort is required and determined to refine the solution to make it simpler. Spend time, make great efforts and strive for simplicity.
What principles are you living with?
Yes, above are my principles, so what is your principle?
Which principles do you personally live with? Do you think it's important to remember every day and practice it?
Please share your principles in the comment section below!
ITZone via Techmaster