This translation from Ravi Shankar Rajan of 5 Toxic Habits That Will Make You a Bad Developer., Please read against the original.
You can not change your future, but you can change your habits, your habits will certainly change your future.
"Shackles of habit too light, so that they become heavy and can not be broken."
--- Warren Buffett
When our own bad habits because you feel unwell, we will be looking for solutions. We will go to the open book or turn to others, expect to know how to get rid of it. However, the reality is that any bad habits to break depends only on the "person in the mirror (the man in the mirror)". You expect to get better, do something different. Once you have mastered the change of paradigm, get rid of bad habits, it becomes very easy.
As in life, there are good programming habits and bad habits. You can become a good programmer, depending on your ability to effectively control the encoding bad habits. You repeatedly do will affect your behavior, you have to believe in something and think of the whole world. In short, to develop good habits or bad habits, depends thinking.
If you are not aware of his actions are destroying your work, so it is difficult to eliminate bad habits. You still feel good, and will continue to fall into inefficiencies and poor code quality quagmire.
As a self-taught developer, I indeed experienced the consequences of bad habits caused. But now I know what he had made mistakes and learned to avoid the same mistake in the future. I am still learning, and with each passing day.
Here are some harmful habits, these habits will make you a bad developer.
No plans coding
"I always found that plans are useless, but planning is indispensable yet."
--- General Eisenhower
Unfortunately, many developers (myself included) have often thought: "I can easily do that", but the end result is very poor. We did not seriously consider it to work, the final deadline to the project, there are a bunch of demand did not finish, and the code is a mess.
And if the analysis needs to be able to take some time before the coding, the decomposition module needs manageable, and some brainstorming with colleagues and business analysts, and so propose a progressive plan, you can help us create high-quality code. The use of pen and paper, or whiteboard, and even a small yellow duck talk, and then put forward a plan orderly traceable.
Remember, you can not plan everything. The first plan to solve the problem could be completely wrong, but that's okay. It is important, when you complete the first draft, you can clearly know where the gaps, and the need to fill in how these gaps. Planning is important, but the plan will vary between inadvertently.
Harbor alert for code review
"The problem is that most of us, we would rather be destroyed praise, do not want to save the subject of criticism."
--- Norman Peale (Norman Peale)
Criticism may be unacceptable, but it is necessary. It is the same with the physical pain, allowing attention to an unhealthy state of their own. You might think the world's best developers, but the performance of your code do not. The sooner you realize this fact, the sooner you can become a good programmer.
You need to be humble to a fault or defect is detected in the code review process and to ensure that follow-up will not make the same mistake. Developers bad this did nothing, it will eventually harm harm already.
Good developers are willing to come up with their own code to open discussion, and continuous improvement. They are not blinded by his fast hardware solutions, willing to accept their own ignorance, and constantly learning new things.
Behaved omniscient
I do not understand all things, and sometimes a good thing
--- Neil Gaiman (Neil Gaiman)
Bad developers do not recognize there are many reasons for our ignorance. Fear of being laughed at, inflated ego, afraid of being condemned and so on. But for whatever reason, they eventually get on the knowledge and reputation will be the losers. Behavioral economics of the bestseller "fanatical economics" Stephen · J · · D · Dubna and Steven Levitt make such a point of view: the hardest words to say there is not "I love you", but "I don 't know ".
Keep in mind, he said "I do not know" is entirely possible. This is more than cover up your lack of certain knowledge / skills much better. The key here is to know how to solve the problem - or others may be further investigation by asking.
Utopian dream to its dedication to be omniscient, as the world as a basis for learning. You should receive anywhere new, different or varying perspectives and problem-solving ability to adjust to changing circumstances.
The number of lines of code to measure progress
"Programmed to measure progress by the number of lines of code just to measure progress by aircraft weight."
--- Bill Gates
"I can write 10,000 lines of code in a night job."
"Did you see that project? That is mine. For this reason I wrote 30,000 lines of code."
"I have my own coding style. No matter what others do, I'll encode their own way."
Sound familiar? This is called self-programmer. His own way of doing things and rewrite existing code may satisfy your ego, but it certainly can not meet the needs of the project.
As a developer, your job should be to write as little code as to meet demand. When getting a new functional requirements, you should first ask yourself: "Someone has to do it I can reuse it??" Borrow ready-made solution there is no shame, because the results are usually created any software teamwork . You should always want the whole team as hard as chime stone, not just individual patchwork.
Eliminating the need for their trouble. Do not repeat yourself. Do not repeat the same or almost the same in the program code. But we can handle the code in a class or function in many cases. If someone has already done it for you, then shamelessly to use it.
Shirk responsibility
Good people are good at self-examination, self-esteem of people blaming others
--- Don Shula (Don Shula)
Software development is a team sport. Agreed
Software development is a collective collaboration. Agreed
So I liable for my code. Not OK
Some arrogant and haughty attitude among developers is not a secret. Therefore, acknowledge a mistake and confirmed by the production problems is the code you write cause, which requires very humble and unselfish attitude. The problem is easy to blame others. But look past the code and find out the cause of the error to solve the problem would be more efficient.
Everyone will pay attention to those who are responsible for their own code and to ensure that he would not make the same mistakes developers. Software can not always be perfect. Defects will always be there. The key is to control deficiencies, and the pursuit of excellence.
From now on, you should try to make themselves and others as much as possible readable code. Remember, if you do not open your heart to admit their mistakes, and that in fact not grow.
As Walt Whitman said the same:
Be curious, not judgmental.
Android video learning PDF + Architecture + + source code documentation interview notes
Thank you for the ability to sit through
Xiao Bian here also share a copy of your collection of finishing Android studying architecture PDF + Video + Interview + document source notes , as well as advanced technical architecture Advanced Brain Mapping, Android interview with thematic development, advanced materials advanced architecture to help you learn ascended into order, saving everyone time online in search of information to learn, you can also share with close friends studying together
If you have a need, you can point like + comment , concern me , and then add my VX: 15388039515 I sent you
(or concerned about micro-channel public number "Android Development House" reply [information] for free to receive)