The longer you spend around the programmers at your IT company, the more you understand their endearing sides: geeky or cute, upright or sleazy. If you happen to be a programmer, you’ll find that your excellent colleagues always share some common traits. The original author, ROY VAN RIJN, summarized the 6 common traits he found in his excellent programmer colleagues:
- Curiosity
- Love of sharing
- Community awareness
- Pride in being a programmer
- A bit lazy
- Code visualization
1. Curiosity They always keep a curious mind. Whenever they hit a problem, the first thing is: Google! No Google, no right to speak. Then they search StackOverflow for related questions, browse mailing lists, read online documentation, and so on. This sounds obvious, but some people first ask their colleagues sitting next to them. The original author thinks this habit is not good: Google returns far more information than your colleagues around you know, so there’s no need to waste effort on a busy coworker when such a great resource is available.
Of course, most of the time the first Google search may not return what you want, but don’t give up! Keep searching, try different keywords, or just read the source code. If none of that works, ask in communities like mailing lists and newsgroups.
2. Love of sharing Once you find a solution to your own problem, do you just stop there and that’s it? No! A good programmer can’t do that. Right now there’s a group of programmers on Earth facing the same problem you are, and they’re trying to solve it too.
Organize your thoughts and write a blog about it: what pitfalls you hit and how to avoid them. Where you once searched for the problem, if it’s still unsolved, help answer it, post your solution, and accept the admiration of those who come later. Of course, you might “ask and answer your own question” — in which case prepare to be looked down on by those who come later.
3. Community awareness If you hit a bug while using some open-source software, what do you do? Generally there are 2 reactions:
- Complain and look for an alternative
- Download the source code and patch it yourself
Neither of the above two approaches is very wise. The reason open-source communities are communities is that everyone voluntarily fixes problems, so the first approach clearly isn’t suitable. Then why is the second approach wrong? We don’t encourage directly downloading source code to patch it; you should first contact the software’s maintainer. A famous example is that Linus Torvalds once refused to merge a piece of code that could greatly speed up the Linux kernel, simply because its author had worked alone for 6 months. Remember: first discuss your improvement with the community, then do it together!
There’s a witticism that goes: an open-source project didn’t die because no one came to fix your bug; because no one fixed your bug, the open-source project died.
4. Pride in being a programmer Good programmers are all proud to be programmers. Once you’ve finished some feature, you can’t wait to show the result to the client, and nimbly implement the client’s ideas.
If you find a possible problem in your own code, what do you do? You might be “arrogant” — because you wrote it, you feel code review is unnecessary; or you insist on finishing it yourself rather than collaborating. A good programmer should learn to share with the team, keep the passion at all times, but not just for yourself, but for the team, the product, and the project.
5. Hmm… a bit lazy Almost all excellent employees in any profession are diligent and hard-working, except programmers — those excellent and outstanding programmers are all a bit lazy. This may be the only profession that treats laziness as a virtue (testers may be an exception). Perhaps the most famous example of this excellent trait is that “First Lady of Computing” Grace Hopper invented the compiler in 1952. She explained that she made the compiler precisely because she was lazy, and wanted programmers to be able to become mathematicians. If a programmer is asked to regularly do something, he/she will insist on figuring out a way to avoid doing it. “Write once, run anywhere.” If a client keeps talking about tedious, repetitive work, a good programmer will always try to automate that work. Bill Gates also said, “I always choose a lazy person to do a difficult job. Because he will find an easy way.” Programmers, embrace “laziness” — automate repetitive work, don’t repeat yourself! Tip: lazy people should quickly learn keyboard shortcuts~ This is also what good programmers should do!! 6. Code visualization For the entire codebase, you need to build a model in your head. This is what we call “code visualization.”
To achieve “code visualization,” first we need to understand the entire codebase. When you need to modify or add/remove part of the code, you need to know where to look. Where does the problem appear, how do the objects/routines in the application work, what is the relationship between each module — all of this needs to be clear.
Second, you need to understand the code environment you’re working in. Most of the time we switch back and forth between multiple files; a good programmer knows the environment they’re currently in and won’t feel lost. Just by looking at the code framework and structure, they can quickly find the source file they need. Of course, this requires a full grasp of the entire code. However, the ability of male and female programmers in code visualization does differ; according to current research, it seems the navigation features in IDEs are more beneficial to male programmers.
Original: 6 common traits of good programmers / Translation: Wang Dianjin