preface
In my more than ten years of front-line development, I am very familiar with programmers who write code. A programmer’s ability level can be seen by looking at how he writes code. In my opinion, programmers can be basically divided into four levels of ability: linear level, logical level, architectural level and engineering level.
Programmers in the process of writing code often appear some bad habits, including myself is so stumbled all the way over, there are 8 bad habits very common, today to tell you about, let’s see if you have this habit!
The four skill levels of programmers
1. The linear stage
The linear programmer’s thinking is very simple, like building a house when writing a program, brick by brick to build, but he does not know what will be built, the more and more huge, behind the code organization, management and so on more and more chaotic, and finally lead to the modification and maintenance of a lot of programs is very troublesome.
2. Logic level
For logical programmers, I have mastered the theoretical basis of some algorithms, and have a clear grasp of the logic of the business world, and can write some good modules and functions, and the logic is more rigorous, less bugs such a state.
3. The architecture level
For architecture programmers, this is because in addition to understanding and mastering the programming language itself, it is necessary to have a clear grasp and understanding of the business logic to be solved in the real world.
In this way, the software can be structured and layered, and then the rest of the team can be guided to achieve consistent goals.
4. The engineering level
For engineering programmers, because software development is not just development itself, there are many other elements of project management involved.
For example, planning, organization, management, and control mentioned above, if there are some guidelines and principles of project management, then the process management of a software project will have a “small view” state.
8 Common Bad Programmer habits
Based on my previous work experience, I think these bad habits are one of the biggest obstacles to programmers’ progress.
1. The self –
So first of all, the programmer, because he is a mental worker, that is a very important characteristic, is very ego.
A lot of the time when you’re writing code, you’re basically not willing to listen to other people’s opinions and suggestions.
2. Enclosed
Some programmers are very closed, which means it’s not open enough.
If you interact with other programs with an open and communicative mindset, the mutual benefits can be significant.
3. The inertia
There are some experienced programmers will have some work inertia, often will say “I used to do so”, “I used to do so, I think you now do so wrong “…… In fact, this kind of inertia is also a big problem that hinders communication.
4. Communication problems
This is one of the more obvious types of bad habits, because programmers face computers all day and only interact with machines, so there are obvious barriers to communication with other product managers, other testers, and so on.
5. See the wood for the trees
This is the biggest problem, meaning that programmers often see only the work in front of them.
For example, when there are some teamwork tasks, it’s all about you. So for some requests of others, especially some interactive complex network interface development will often subconsciously reject others.
6. Workload estimates are optimistic
There is also the most important problem, which is that the amount of work is often missed.
For example, when I get a requirement, ok, I can do it in a week, but when I actually do it, it takes two or three weeks or more to do the task.
7. Resist change
For requirements to change, programmers have a large mentality of reverse psychology.
When I’m writing something and the requirements change, I have a block mentality to resist change.
However, the premise of rejecting change should be objective and reasonable analysis and judgment, and finally give an answer. It’s really a matter of carefully weighing itself does this change affect my current software architecture and architecture? How much is the increase in my workload? It takes a good measure to decide what to make of the change.
8. Refuse refactoring
The last and most important issue is that a lot of times we reject refactoring because it’s sometimes a tough one to choose from.
For example, I often think, oh, my original software architecture, with the whole implementation process, more and more changes, and when informatics, new requirements come in, I can not maintain a good such an architecture. So it’s always a question of, do I refactor or do I just go back and forth?
Whether or not to refactor actually depends on my actual situation. For example, especially for an Android game I wrote a few months ago, I was always in this mindset. I was wondering whether to refactor or not. Later a gnash teeth a closed eyes or reconstruction.
Reconstruction may take some time in the early stage, but it can ensure the realization of the goal of my software in the later stage, and it has a clear and complete architecture and system structure, and it will reach a state that is easy to maintain in the later stage.
These work habits mentioned above, in fact, are the nature of most programmers, we need to improve slowly in the work, first need to realize that this is a bad habit, consciously to constantly correct themselves, with a good attitude to avoid these problems.
