How to become a star programmer

Andrew C. Oliver is the president and founder of Open Software integrators, a company that works primarily with open source companies, especially those startups, dedicated to providing course development, training, consulting and support to clients. Partners can focus on the core business areas, and the company provides professional services. Recently, Andrew wrote about what it means for programmers to become a star programmer and give a very pertinent 10 suggestions.

Many developers will think that what is needed to be a star programmer must be related to programming skills, but the idea is completely wrong. Good code is great, but to get a better job, getting a higher reward requires more people to know who you are. In other words, you need to sell yourself, here are my 10 tips for becoming a star programmer based on my work experience over the years.

1. Write a blog

Take a blog and write articles for one months. Do real research to make sure you're not writing something very simple. More seriously, it's about learning how to write articles. Follow the way your school's English teacher teaches you: Create an outline, narrate, check grammar, and pinyin. Next, simplify what you have just written, so that the people who read your article can quickly master the gist of the article. Now the Internet is to achieve excellence.

2. Open source

Don't trust the lies about open source. Those of you young people may not remember the situation in which developers would have lost their jobs in the past, but even in a bad economy, all the developers of the open source projects I created will still not be laid off. Make sure that the open source code you develop will reflect your work. I want to use the simplest solution to solve the problem, but I interviewed a lot of developers, they all have simple problems to complicate. Whether you believe it or not, there is a market for this, but make sure that the code you write reflects the market you are in.

3. Not 6 months, not 10 years

Don't change jobs every 6 months. Seriously, a lot of people in a company will be leaving, and there will be new entrants. In other words, do not do the same thing in the same place for more than 10 years, otherwise you will be insulated from the market and form inertia. For example, if you're working at IBM, you can't just be content with IBM's technology stack to write code to maintain your own value. I have never hired anyone who has worked in a similar company such as IBM for more than 2 years. They often gave me the impression that they did a good job in the interview, but they failed in the actual programming.

4. Look at new technologies and focus on reality

In particular, some young developers are fond of using new technologies. Ruby is one of my favorite programming languages, but on average, Ruby pays me less than Java, and Ruby's market is smaller. This is not always the case, Scala looks very strong, but do not forget its market share, in fact, is still very small. On the other hand, don't use the same technology for a long time, such as COBOL or PowerBuilder developers.

5. Writing your own documents

When I am involved in developing a project, I often get pulled out to attend meetings because they read the documentation or presentations I've written, and I can understand that this is happening too many times. I always start with an overview map, followed by a description of its various details. The question is: What do you know about a very busy person? What most managers want to know. Please follow this idea to write a document.

6. Simplicity is the soul

For management, those who know what they are saying often give more concise answers. If the answer is long and complex, it means that the person answering does not know what the answer is. In addition, tones are usually inversely proportional to the importance of the subject. If there is bad news, then when people walk into the office, they will walked softly, close the door, and then whisper. Make sure you know what you're talking about, how to summarize, and how to describe the details, but please do not introduce everything in every detail. Make sure that your team members are well thought out and clearly articulate which ideas are better than others.

7. Public statements

Know how to make speeches and learn how to speak in public. Study a subject and then make yourself an expert on the subject. If you have some sense of humor, you will have a better speech in public. To master this skill, you need to spend a lot of time and effort, but also to endure the ridicule of others, but for the engineer, if you can use English to explain to the manager of the problem, but also can make a professional speech on a topic, then his salary is generally higher than those who do not have the ability of the developer.

8. Some real

You like Erlang very much, but Erlang's market is not that big. You should know a lot of different languages and you should be aware of the "new" topics, but please don't say this immature phrase "if it's not Erlang, I'm not going to write code" unless you really understand the business problem. Doing so may make you an expert in a narrow field, but even if it comes at a price, if your skills are outdated, the results are not fun. Of course, NoSQL is better suited to your own small projects, but the company doesn't invest in that one-off system, in which case the RDBMS fits.

9. Troubleshoot problems and learn about tools

Take some time to learn about tools that most people don't understand. Do you know the tools that few people know/use/understand to make you more efficient than the people around you? For example, aspect4j is not suitable for everyone, but it suits me. I've written some. class file operations to run normally under Tomcat, replacing WebSphere, and I fixed a memory leak for private software. Every experience has made me more than anyone else, because I've used tools that other people rarely know to solve important problems, while others are waiting for a vendor's solution. Of course there are others, but these simple tools can solve complex problems and make you surpass other developers.

10. Stay Humble

Few developers have the trait of humility. Sometimes, this means you need to do some very specific work. The prestige of the geek will come and go, but remember, it is your actions that make you reap that prestige. The next week may be all gone. In other words, "You don't have anything special."