How to become a powerful programmer?

Http://kb.cnblogs.com/page/171286/

 

Aaron Stannard is the CEO of markedup, a startup company. He recently spent a lot of time hiring, evaluating, and working with many different programmers. In this process, he discovered and summed up the ten reasons why programmers could not realize their potential, and intended to let more programmers discover their potential and become powerful programmers.

Aaron mentioned that the technology used in his company is very complex and difficult for some large enterprises to master. Therefore, it is very difficult for programmers who want to join the team to get started. Therefore, although they hire new people very carefully, it is difficult to find talented programmers. As a result, he summed up ten actions that impede the development of the programmer's career, and accordingly helped ordinary programmers who want to improve themselves.

　　1. Too scared to learn new tools, languages, and frameworks

Generally, programmers stick to their favorite tools instead of learning new ones, because they think that years of experience will be lost after leaving those languages and tools. Powerful programmers will embrace those challenges and opportunities and actively learn new ways of work.

　　2. It will not be submitted until the feature is "completed. (But it will never be done !)

In markedup, he called this behavior "commit hoarding )". Some programmers do not have enough confidence to accept criticism and review from other members of the team, so they will hide their work and submit it until it is "done.

This kind of developer will damage the productivity of other personnel in the team, because the team does not see his daily results, and he will not seek help during normal development, this will lead to many "last minute" defects, resulting in delivery delay. Powerful programmers will know that the Code is not their own, so they will present the code in front of other team members with confidence and get criticism and suggestions.

　　3. It is only dangerous to "know it ."

Here, Aaron takes the async and await keywords recently introduced by Microsoft in C #5.0 as an example. These two keywords make it easy to create and manage asynchronous calls, however, context switching and multi-threaded access to shared resources are also costly. programmers who only have a basic understanding of this will blindly use these features, encapsulate all I/O calls into task objects in C #. This creates dangerous, unpredictable, and hard-to-test code.

A good developer not only knows why, but also understands why and under what conditions it should be used.

　　4. analysis paralysis)

Analysis paralysis refers to system analysis at the initial stage of program development. It is often because you are too persistent in controlling all possible changes and accidents, resulting in a large amount of time waste. This is a classic problem that affects many general programmers. It is usually caused by excessive analysis, but Aaron thinks the root cause is that he does not dare to make bad decisions. Generally, programmers worry about making mistakes and only want to succeed once.

Powerful programmers will not be afraid. They will write bad code and perform unit tests on it. If they think they cannot achieve the goal, they will discard it within 45 minutes. Powerful programmers actively limit the time spent on research because they know it is a trap-it seems to be valid, but often does not work.

　　5. No investment in tools and development processes

If you want to become a talented programmer, you need to spend time improving your skills and knowledge. What distinguishes you from common code workers is the ability to quickly write production-level code. You can have good code and speed at the same time, but you need to invest in your construction process first.

Generally, programmers do not invest in tools, processes, and environments. They only spend a lot of time learning how new language features and APIs work, but that doesn't change.

Generally, the biggest improvement you can make as a programmer is not focused on the code you write, but the process of optimizing your code.

　　6. Be ashamed to ask for help

Generally, programmers are ashamed or do not want to let people know what they don't understand, so they pretend to know everything, but in this way, they may commit some terrible code to the library. "I don't know how to do it ." There is nothing wrong. Powerful programmers know this, so they will ask for help when the problem is hard.

　　7. Don't know how to make your code easier for other programmers

Among all technical teams, human parallelism is an important part of their work, that is, the ability of multiple people to work on the same code base simultaneously. However, it is also important for the team to work asynchronously. when you are not there, I can modify your code, and vice versa.

Generally, developers do not think so. They will start to write code for a task and think that they will always have this code. Powerful developers will learn about technical debt and try to design code to limit it so that it can be maintained and self-interpreted as much as possible.

Writing readable code requires programmers to change their views-your code is longer than it exists in your organization.

　　8. Don't know how to read other people's code (or don't want to read it)

When a general programmer sees a code library written in a language or framework he is not familiar with, he wants to rewrite it immediately without considering the business value or the time it takes to market. Powerful programmers accept this idea that the business cost caused by rewriting is generally unacceptable, so this behavior should be avoided. They will try to sit in front of the computer, understand, learn, and modify the existing code.

Reading code is harder than writing code, but a powerful programmer will spend time learning how to surpass it.

　　9. cannot be encoded from the end user's perspective (the scope you consider is too narrow)

As a programmer, your job is not to solve technical problems. The reason why you solve technical problems is to solve business problems.

Generally, programmers will only get stuck in technical issues, but do not know why the problem was solved at first. More seriously, programmers generally cannot create something of business value from the beginning. When it is required to design new features based on simple users, they will be rigid, follow the words to explain the story or instructions, so that the delivered product users can not use. Because they do not consider the relevant use cases; they do not consider the end user experience; and the design will be cumbersome when making user-oriented content. As a result, they cannot write business applications and can only make products.

Good programmers will look at their code from the end user's perspective. How can I make it easier to solve user problems? What other aspects of the story's text content will bring more benefits to users?

　　10. Unable to determine the business value of any programming task

This problem is related to the previous one. Many technically strong programmers are unable to realize their potential because they will not stop and look at their work from the business or organization perspective.

Powerful programmers can manage themselves and make good business decisions on how to invest time in the selection. They will ask the question: is this the most valuable thing I should do now? How much time should I invest in it? There are two weeks before the delivery date. What can I do now to make it easier to meet that date?

Generally, programmers do not. They only hold instructions and blindly implement them until the end. They do not care about the relationship between their work and the company's business goals, and the impact on other teams and business groups. In this way, they will waste a lot of development time on technical tasks with low business value.

Aaron concluded: If you want to become a better programmer, you must change the way you view code and code. You need to understand the business costs behind each line of code you write; you need to look at your work from the perspective of the customer or end user; you need to accept that the Code will be longer than you have in your organization, so you need to design it in a way that other developers can inherit. The most important thing is never to fear the new