Aaron Stannard is the CEO of Markedup, a new venture.

Aaron Stannard, CEO of Markedup, recently spent a lot of time hiring, evaluating, and collaborating with many different programmers. In the process, he discovered and summed up the reasons why 10 of programmers were unaware of their potential, so that more programmers could discover their potential and become powerful programmers.

Aaron mentions that the technology used in his company is so complex that some large businesses are difficult to master, so the entry threshold is very high for programmers who want to join the team. So while they hire new people very carefully, it's hard to find talented programmers. He then summed up 10 behaviors that hindered the programmer's career and helped the ordinary programmers who wanted to improve themselves.

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

Programmers tend to cling to their favorite tools and not want to learn new ones, because they believe that years of experience will be lost when they leave the language and tools. Powerful programmers embrace those challenges and opportunities and actively learn new ways to work.

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

He called this behavior "hoarding commit hoarding" in the Markedup company. Some programmers do not have enough confidence to withstand criticism and scrutiny from other members of the team, so they will hide their work until the "completed" status is submitted.

This developer can damage the productivity of other people in the team because the team does not see what he does every day, and he does not seek help during normal development, resulting in a lot of "last minute" flaws that delay delivery. And powerful programmers will know that the code is not themselves, so the code is often confident in the presence of other team members to get criticism and advice.

3. Just "Know" is dangerous.

Here, Aaron. For example, the async and await keywords introduced by Microsoft in C # 5.0 Recently, these two keywords make it easy to create and manage asynchronous calls, but also cause context switching, and the cost of multi-threaded access to shared resources, Programmers who have a basic understanding of this are blindly using these features to encapsulate all I/O calls into Task objects in C #, creating dangerous, unpredictable, and very difficult to test code.

Good developers not only "know", but also understand why and what conditions should be used.

4. Analytical paralysis (analysis paralysis)

Analysis of paralysis refers to the early stage of the process of systematic analysis, often because too obsessed with the control of all possible changes and accidents, resulting in a large amount of time wasted, to be deterred. This is a classic problem that can affect a lot of ordinary programmers. It is often caused by excessive analysis, but Aaron believes the root cause is the fear of making bad decisions. The average programmer will worry about making mistakes and just trying to be successful.

Powerful programmers don't get scared, they write bad code, unit tests, and if they think they can't do it, they throw it away in 45 minutes. Powerful programmers actively limit the time they use to study because they know it's a trap--it seems to work, but it's often ineffective.

5. No inputs to tools and development processes

If you want to be a gifted programmer, you need to invest time to improve your skills and knowledge, and the ability to quickly write production-level code is what separates you from the average code worker. You can have good code and speed at the same time, but you need to first invest in the process you use to build.

The average programmer doesn't invest in tools, processes, and environments, and it only uses a lot of time to learn new language features and how the API works, but that doesn't change anything.

Often, the biggest improvement you can make as a programmer is not to focus on the code you write, but to optimize the process of writing your code.

6. Be ashamed to ask for help

The average programmer is shy or doesn't want people to know that they don't understand, so they pretend to know everything, but it's possible to submit some very scary code to the library. Say "I don't know how to do it." "Nothing wrong, powerful programmers know this, so they ask for help when they are stumped by a problem."

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

A significant part of the work of all technical teams is the parallelism of the people (Human parallelism), the ability of multiple people to work with the same code base at the same time. But for a team, it's also important to be able to work asynchronously, and I can modify your code when you're away, and vice versa.

General developers don't think so, they start writing code for a task and think they'll always have the code. A powerful developer knows the technical debt and tries to limit it by designing code to be as maintainable and as self explanatory as possible. (Recommended reading: "Using chickens to explain the process of technical debt formation", "the real cost of technical debt")

Writing readable code requires programmers to change their view-your code is longer than you have in your organization.

8. Do not know how to read other people's code (or do not want to read)

When a typical programmer sees a code base written in a language or framework that he is unfamiliar with, he wants to rewrite it immediately, regardless of business value or time taken to market. Powerful programmers accept the view that the business costs of rewriting are generally unacceptable, so this behavior should be avoided. They try to sit in front of the computer, understand, learn, and then modify the existing code.

Reading code is harder than writing code, but powerful programmers devote time to learning how to go beyond.

9. Cannot be encoded from the end user's angle (your range is too narrow)

There is a good saying: As a programmer, your job is not to solve technical problems, you solve technical problems to solve business problems.

The average programmer is stuck in a technical problem without knowing why the problem was first solved. More seriously, the average programmer cannot start from scratch to create something of business value. When asked to design new features based on simple users, they will be rigidly, according to the word to face the story or instructions to explain, so that the delivery of products users can not use. Because they don't consider the relevant use cases, the end-user experience is not considered, and the design is cumbersome when it comes to user-oriented content. This leads them to be unable to write business applications, only products.

Good programmers look at their code from the end user's point of view. How can I make it easier to solve the user's problem? What are some aspects of the story that will make this feature more profitable for users?

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

The problem is related to the previous one, and many highly skilled programmers are not aware of their potential because they don't stop and look at their work from the perspective of the business or the organization itself.

Powerful programmers can manage themselves and make good business decisions about how to invest their time, and they ask the question: Is this the most valuable thing I can do right now? How much time should I devote to it? Two weeks from delivery date, what can I do now to make it easier to meet that date?

The average programmer will not, they will only hold the instructions, and then blindly implement, until the end, do not care about their work and the company's business objectives have any relationship, as well as other teams and business groups will have impact. In this way, they will waste a lot of development time on the technical tasks with low business value.

Aaron concludes: If you want to be a better programmer, start by changing the way you look at code and coding. You need to understand the cost of the business behind each line of code written; you need to look at the job from the perspective of the customer or end user; you need to accept that the code will be longer than the one you have in the organization, so design in a way that other developers can inherit, and most importantly, never be afraid of new challenges, and don't be afraid to ask for help. , you can't live alone to improve your work, and software development is also a social work.