* Foreword: The original author George Fekete is a web developer with a 10 client and server, specializing in PHP, JavaScript, dedicated to a wide variety of large Web applications, Primal Skill founder, CTO.
This article is based on how-to-be a good developer translation. *
As a hard-pressed programmer, you need to constantly improve yourself in this changing industry, learn and practice, become a successful developer, in order to find their place in this great pressure of competition.
So the question is, what are we talking about as successful developers, who are bloggers who know a variety of languages and tools? Or do you think of coding practice as an art artist?
From this article, you will learn how to use "Programming etiquette" to become a better developer, and even to preach this knowledge to others.
How to become a professional talent?
No matter what kind of work you do, you should start from the professionalization. As a professional talent, the most important thing is to have their own distinctive personality and characteristics.
In any field, a professional developer will often be respected by everyone. Let's witness how you become one of them.
I have worked in a large team and when I practiced my "programming etiquette" in this team, the first thing I learned was that the team had to be closely connected to the collaboration.
In a team, most of your time should be used to learn from each other, and a team must live in an environment where stress and benefit sharing coexist.
If you do not want to share your work and knowledge, you will find that your arrogance and selfishness will make you struggling in such a working environment.
There is no need for professionals to be responsible for their work.
Responsibility is left to the superior, only need to complete the designated work, when the 5-point horn you can forget all the work trouble.
This is a must for a professional developer. Can you laugh one day when your bug brings a huge loss to the company?
This problem also depends on the management of the company's methods to solve. Each company should motivate programmers to be more responsible for their actions rather than just writing a few lines of code.
If your bug is unfortunate enough to affect the service of the product, then there is no doubt that you can make up for it and even spend the whole night. This is also the point of separating you from the hanging oil bottle, and it is also a precondition to bring you a more lucrative salary.
There is no perfect thing in the world, and software is the same. It is always inevitable to make some foolish mistakes when we are working.
And the way we deal with other people's criticisms is a reflection of how we look at developer work.
From all the criticisms we can learn and learn, it is the best way to improve yourself, especially from those who are stronger than your experience and ability.
Have a passion for work
As a professional is a work without stopping the key, learning can not only be between nine to five.
Continuing to learn, practice and improve yourself is an investment, and it's your responsibility, not your boss's.
It's not just work, it's so ¬--in life. You can never blackmail your boss to squeeze time to see the latest version of Segmentfault's instructions (relax, man!). )
Perhaps you would say that I have so much time? Of course you didn't! But you need to think. If you want to do your job well, first of all, you have to take your job seriously.
Just taking half an hour before and after work means that there will be 5 hours of extra time a week, that is, you will have more than half a workday, and the time will always be squeezed out.
How to write good code?
If you don't train your reading ability, you won't be able to do Yimushihang. In the same way, the programmer's job is to be able to write good code, but if you do not know what the good code is not to train it is all useless.
Most programmers just blindly use third-party libraries without touching the source code. This is possible for general work, but if you want to figure out how that library works, you need to dig deep and understand its source code, if you can, run tests (if it has one).
Reading the code can also help you find other developers ' errors quickly, which can help your review or repair a lot.
Treat new technologies, always keep an open mind, and then think about how this new technology can help you become a better programmer.
Keep curious about new things, not because you think they have no potential but rather miss the real trend. Everything is cyclical and unchanging is the wealth of knowledge you gain from being open-minded.
A good developer will not stop learning even if they have 15-20 years of practical experience.
Slowing down means spending more time evaluating the problems you need to solve. Speed is not something you have to fight for at this time.
I have encountered some novice to the task after the thought of the fastest speed to complete, and then delivery code, the result is a lot of bugs in the code, they have to spend more time to solve these problems, in fact, they just need to stop, think about the pain point of this problem, it can spend less time and energy.
Advanced developers are lazy and slow, which seems like everyone's hobby, because a good programmer doesn't want to do a job again.
For advanced developers, they spend one-third of their time writing code to complete tasks, and the rest of the time they think about how to do it the best way.
This is not a TDD or TDD debate, but keep in mind that testing of any nature is important for submitting high-quality code.
Do not test how to know if there will be problems arise? Do you know what you did a few months ago in a particular code base?
By testing, you can clearly understand how the code actually works. This is like a catalogue of books that guides the developer on how to do it. You can know where to start and what to do.
It's hard to get started when you write a test, but it turns out to be good if you do it for a long time.
Know what tools you can use to help you solve problems. Most of the tools are chosen, but in the end they all fall into preference, but remember, a good tool can help you a lot.
Think about how much time you spent on the compiler, it's a full IDE or just a syntax-highlighting text editor.
At the same time, you need to decide whether to use a specific library, is it worthwhile to use the PHP framework? What are the pros and cons? Is it possible to use a cumbersome CMS in the project?
These are the questions you need to think about before you move the keyboard.
How to not go fruitless?
Beating the code over and over again, this cycle of life is actually a dull thing, and most developers will encounter a career-weary moment in their careers.
This happens with long hours of work called Imposter syndrome (impostor syndrome), because developers constantly increase the intensity and time of their work because they want to become better. But too much work is not necessarily better.
The best cure for this is to get out of the loop and do something else, to go on a journey and do your favorite thing. Give yourself a few days off, if only for a few days.
Another way, and an increasingly popular way to fight fatigue, is to find a team member to work with you to write code. Social is a very efficient way to solve.
Maintaining a stable state also means ensuring a clean code base. Not just for others, but for yourself. The code without testing and documentation is like a Russian roulette.
Imagine what to do if you need to revisit some of the features in the next few months. You'll spend more time figuring out what you're doing rather than the task itself.
I've seen clients approach developers countless times to refactor their projects because the previous team gave up on the project, and almost all the new teams thought the project needed to be written from scratch.
This happens because the previous team failed to maintain a clean, stable code base. Practice takes a lot of time to read this article Critical oversights in WEB development, this article focuses on how to maintain the purity of code, as well as other practical practices.
Estimation is a very sensitive topic for many programmers and managers, which is also necessary. I can be sure that everyone has heard a similar example, and managers often ask developers how long it takes to complete a task, and they need a clear answer. But the tasks that are generally evaluated will take up to twice times the initial estimated time.
And most people don't realize that the so-called estimates are just guesses, not promises. As a better developer you always need to know that estimating is never a promise, and once you commit to something, that means you need to be responsible for it.
It is an intrinsic essence of estimation that an estimate is never and will not be a promise. People tend to be afraid of estimating the time to complete a given task, and if your boss asks you to do so, you have to tell him it's not a promise, and you can't guarantee that 100% will finish it on time.
In any case you can make a guess, but don't make a commitment.
How to become a guru?
Communication is an essential thing, and some projects or companies die because the team members lack communication.
The communication needs to be simple and direct, remove the middle person. Be aware that every "node" in your communication line can cause almost exponential growth of difficulty and distortion.
Companies tend to suffer greatly because of this, which is why it moves so slowly, every decision needs to be more than 10 people, and that's where agile teams stand out.
The simplicity of communication means you can act faster than others, and you can clearly understand what you are going to do, and that will be your personal advantage. So friends put down your shelves and don't be afraid to ask or question directly.
In addition to being a good communicator, you need to be a great co-operative, admit that programmers are not too adept at socializing.
You need to collaborate not just with other developers, but also with your boss, and perhaps with your customers.
Co-operation lets you know what the current crisis is so you can do your job better and play a good team member.
If you find it difficult to work effectively with others, try pairing the programming. The essence of pair programming is cooperation.
This article can teach you how to make good use of other people's Code
Wikipedia gives us the definition that the knowledge curse is a cognitive bias that makes it very difficult for the informed party to consider the problem from an ignorant side.
In general, it is very difficult for a senior developer to articulate a problem in a simple way to a novice developer. This is because they are already very familiar with the problems and methods of the hand, but when they try to explain to others, they tend to be reactive, because this explanation is only a summary of the knowledge in their brains.
Simply put, but when you know something, it's hard not to get to know it. To solve this problem, you have to explain a problem in an easy-to-understand and even interesting way, because your state of mind and the state of mind are not equal.
If you think of yourself as an expert in the field of programming, then you should be good at it. You need to have a thorough understanding of what you are doing, and don't be afraid to say "no" until you really understand it.
Very simply, the process of becoming an expert is to say "no" to others, because you have to defend your truth and establish your authority in front of your peers, because most of the time you are right.
It's not that you have a CS degree that means that you know your field, it only shows that you have the relevant knowledge and practical experience. In addition to general programming and computer engineering you also need to improve other skills.
As an expert, you are trying to find the best solution for a problem, and writing code is just a means of accomplishing it.
If you don't understand your business problems and what your code needs to address, you'll never be able to create a good software.
It is necessary to be interested in your business because it will reflect your work status. If you don't have a clear goal and a specific problem, your code is just a piece of junk, which is what you should do first in writing your code.
You need to know what features to use to achieve your needs, especially how to achieve them, and you must clearly understand the business value of your needs.
If you feel that your expertise is not consistent with your business goals, then do yourself a favor by refusing the job. Cherish your time, because it is priceless.
To continue to improve yourself, first you must know what level you are currently at.
It's a great way to improve your skills by practicing code and constantly looking for better problem solving methods.
You can use these examples to try out the code practice Project Euler, codekata or Topcoder.
TopCoder even set a special award for finding the best programming solution.
Summarize
Programming compared to other skills is a social skill, to become a good programmer, if you find yourself very introverted, first change your personality, and then to master the principles of programming.
To be a step ahead in the game, you need to constantly improve yourself and continue to learn. To achieve specialization, you need to understand your business and the problems that really need to be addressed.
The code is just a byproduct of the whole solution, and he's just a small piece of the plan. Problem-solving ideas, cooperative skills and tools to solve problems are key to your ability to become a respected professional.
Personal supplement
I am not a typical programmer, but I am working in a typical technology company, Cloud BA.
Inyumba is a small team of companies, but in just a few years to achieve the leading level of IoT communications, inseparable from the team's elite culture and management methods.
There is no fixed working time, in the effective time to do the most effective thing, with the results of the output-oriented.
With the problem-solving method and thinking as large, there is a problem, the team will open a meeting, each member of the exchange of ideas and propose constructive methods.
If a member learns a new technology or has a good idea, the team will also organize a learning exchange.
Every programmer wants to be a famous Daniel, and I think it is not enough to rely on personal cavity blood, which requires the whole team to progress together. Cooked to say that one side of soil and water to raise a person, I would like to put this principle in the relationship between the team and the same applies.
How to be a good developer