Is it hard to be a good programmer? All it takes is these 10 habits

In this world, there are millions of people who are passionate about software development and they have many names such as Software Engineer, Programmer, Coder, Developer. After a while, these people may be able to become a good coder and they will be very familiar with how to do their job in a computer language. However, if you want to become a good programmer, you can also need to have a few things you need to pay attention to, if you can make the following ten entries become your habit, then you can really be considered a good programmer.

The original content of this article came from phil’s blog online, but unfortunately the original link is no longer open. The following content comes from my experience in the process of practice and redescribes the 10 articles in my own words.

1. There is no end to learning.

Even if you have more than 10 years of experience as a programmer, you still have to make the effort to learn, because you are in the field of computers, which is full of a creativity, there are many, many new things appearing every day. You need to keep up with the times. You need to get to know new programming languages, as well as learn about programming languages that are in development, and some programming frameworks. You also need to read up on industry news and participate in online discussions in popular communities so that you can understand and appreciate the overall trends in software development. In China, some famous communities such as CSDN, ITPUB, CHINAUINX, etc. In foreign countries, it is recommended that you often go to digg.com to see the aggregation of various BLOGs.

2. Mastering multiple languages.

Programming languages always have areas for which they are best suited. When you are faced with problems that need to be solved, you need to find a language that is best suited to solve those problems. For example, if you need performance, C/C++ may be the first choice, if you need cross-platform, Java may be the first choice, if you want to write a development program on the Web, PHP, ASP, Ajax, JSP may be your choice, if you want to handle some text and interact with other applications, Perl, Python may be the best. So spend some time exploring other programming languages that you are familiar with to broaden your horizons, because you are better armed and you think more holistically, which will be good for yourself and your project.

3. Be rational about the different operating systems or technologies.

Programmers always have their own incomparable technologies and operating systems in mind, some prefer Ubuntu, some prefer Debian, others prefer Windows, and FreeBSD, MacOSX or Solaris, etc. Only some of the best programmers understand the advantages and strengths and weaknesses of different operating systems so that they can be truly objective and fair when it comes to system selection without letting their emotions get the better of them. The same goes for languages. too many programmers always like to dwell on the comparison of languages, such as Java and Perl. which freshly minted programmer has not argued to similar topics? For example, VC++ and Delphi and so on. Arguing about these things only shows one’s superficiality and flakiness. A good program doesn’t stick to these, but can analyze and face them rationally so as to make the right choice objectively.

4. Don’t box yourself into a single development environment.

Again, as mentioned above, every programmer has their own favorite tools and technologies, some like the old ones (I like Vi for editing programs), while some like the new ones like gedit or Emacs. Some like to use GUI debuggers like VC++, while I prefer GDB command line modulators. And so on and so forth. Is there much debate about what tools programmers use? It’s all over the place. It doesn’t matter what tool you use, as long as you can achieve your goals better and faster. But there is one thing that good programmers should know — that is, they should try other work environments. Without comparison, you’ll never know who’s good and who’s not, and you’ll never know what you don’t know.

5. Don’t tell me you don’t know about source code versioning.

If your team is developing source code without a versioning system, then I’m telling you that your software development is still in the stone age. CVS is a bland-looking versioning tool, but it is the most widely used versioning system, Subversion is an updated version of CVS that is starting to take over CVS territory, and Git is a different kind of versioning tool. There’s also Visual SourceSafe and others. Depending on the size and geography of your team, you may be using the most or least efficient tool to manage your source code. But a good programmer will always use a source code versioning tool to manage his or her code. If you want me to recommend one, I recommend the open source git.

6. Be a good team player.

Unless you like to play solo, unless you’re a lone wolf. But I want you to know that today, there may be no proven software that you can do alone, and you may be the biggest bully on your team, but that doesn’t mean you’re a good team player. Your abilities can only be put to use if you put them into a team. Do you have manners in your communication with your team members? Do you communicate with them regularly, and does everyone enjoy being with you to discuss issues? Think about a soccer team, are you a good member of that team? When others see you running down the field, when others see your passes and catches and snaps, can your group members be inspired by your actions?

7. Turn your work into documentation.

This entry certainly includes writing comments in your code, but that’s not enough, you need to do more. Well-commented code is the foundation of a document that makes it easy for you and your team to understand your intentions and ideas. Writing down documentation is not just a way to communicate offline as a team for fear of forgetting what we were thinking, but also a way to transfer knowledge. It’s a good habit to write down everything you know. Because, I’m sure you don’t want people always interrupting you to ask questions when you’re at your busiest, or getting calls from the company asking you questions when you’re on vacation. And if you yourself are always keeping to yourself, the result is only likely to be that you will keep yourself deep within the piece for a long time, and you will be even less able to do more. Including upward promotion. You may think that “teaching the disciple can starve the master”, but I’m telling you, your conservatism will make you lose more and better things, please believe me, I’m not sensationalizing here.

8. Take care of backups and security.

Maybe you think this is a “crap shoot” and you already understand the importance of backups. But I’m here to point out that losing things is part of our life, you will always lose things, you can never avoid it. For example: your laptop is stolen, your hard drive is damaged, your computer gets a virus, your system is hacked, or even the whole building is burned, etc., etc. So, it is very, very important to do a good backup job. Hard drives are not trustworthy, so burning CDs or tapes on a regular basis might be a good way to go, and the internet is not trustworthy, so beware of viruses and hackers, and not only use a security strategy in terms of software, but you need a sound management system. Also, try to keep your data in as many different places as possible and have a regular (daily, weekly, monthly) backup strategy.

9. The design should be flexible enough.

Maybe your requirements will only ask you to implement a dead thing, but, as a good program, you should always be thinking whether this dead thing can have a flexible side, such as making some parameters configurable, forming some common things into your function library for later reuse, whether to provide plug-in aspects of the function? Do your modules have to be assembled like building blocks? If there are modifications, can your design cope with them immediately? Of course, flexible design may not mean reinventing the wheel, but rather using standardized things whenever possible. The so-called spirit talk design is to let let consider more things beyond the requirements, to take into account all the problems of this category in the requirements, rather than just dealing with that particular thing stated in the requirements. For example, if the required screen resolution is 800×600, can your design be flexible to other resolutions? Programming always requires us to deal with different environments, as well as future trends. We need to think about things with a dynamic perspective, rather than carving out a path. Maybe one day, the program you write today will be ported to another environment, and then you can really understand what is flexible design.

A little look into the future says that maybe one day you who are reading the article will design a system yourself, and if you can see things from a system perspective, then flexibility is even more important. For more information on the design principles of system architecture, refer to this article of mine, Recommended System Architecture Principles, on Medium.

10. Don’t pick up a stone and break your own feet.

Programmers always have a bad habit of trying to finish their work quickly. But the situation is often the opposite of what you want. The more you want to do fast, the more likely it is to go wrong, the more you want to do fast, the more likely it is to miss the problem, and ultimately, the program changed over to change the past, press the gourd up the ladybug, and finally spend more time and effort. The desire for speed is not achieved. A good programmer’s habit is to spend more time up front doing more research, experimenting with different solutions, and if time allows, a good habit is that for every 4 hours of programming, you need an hour of rest, followed by another 4 hours of coding. Of course, this varies from person to person, but its purpose is to make you look back from time to time and make you think about three such questions: 1) Is it right to do so? 2) Is it right to do so taking into account all the circumstances? 3) Is there a better way? Think about it, look back from time to time to see how far you have come, from time to time to summarize the past events, will help you a lot.

These are ten habits or behavioral norms of good programmers, I hope its can be helpful to you.

(end)