Know How to Use Command-line Tools Today, many software development tools are packaged in the form of Integrated Development Environments (IDEs). Microsoft’s Visual Studio and the open-source Eclipse are two popular examples, though there are many others. There is a lot to like about IDEs. Not only are they easy to use, they also relieve the programmer of thinking about a lot of little details involving the build process. Ease of use, however, has its downside.

Know Well More than Two Programming Languages The psychology of programming people have known for a long time now that programming expertise is related directly to the number of different programming paradigms that a programmer is comfortable with. That is not just know about, or know a bit, but genuinely can program with. Every programmer starts with one programming language. That language has a dominating effect on the way that programmer thinks about software.

Know Your IDE In the 1980s our programming environments were typically nothing better than glorified text editors… if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes.

Know Your Limits “Man’s got to know his limitations.” — Dirty Harry Your resources are limited. You only have so much time and money to do your work, including the time and money needed to keep your knowledge, skills, and tools up-to-date. You can only work so hard, so fast, so smart, and so long. Your tools are only so powerful. Your target machines are only so powerful. So you have to respect the limits of your resources.

Know Your Next Commit I tapped three programmers on their shoulders and asked what they were doing. “I am refactoring these methods,” the first answered. “I am adding some parameters to this web action,” the second answered. The third answered, “I am working on this user story.” It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus.

Large Interconnected Data Belongs to a Database If your application is going to handle a large, persistent, interconnected set of data elements, don’t hesitate to store it in a relational database. In the past RDBMSs used to be expensive, scarce, complex, and unwieldy beasts. This is no longer the case. Nowadays RDBMS systems are easy to find — it is likely that the system you’re using has already one or two installed.

Learn Foreign Languages Programmers need to communicate. A lot. There are periods in a programmer’s life when most communication seems to be with the computer. More precisely, with the programs running on that computer. This communication is about expressing ideas in a machine-readable way. It remains an exhilarating prospect: Programs are ideas turned into reality, with virtually no physical substance involved. Programmers need to be fluent in the language of the machine, whether real or virtual, and in the abstractions that can be related to that language via development tools.

Learn to Estimate As a programmer you need to be able to provide estimates to your managers, colleagues, and users for the tasks you need to perform, so that they will have a reasonably accurate idea of the time, costs, technology, and other resources needed to achieve their goals. To be able to estimate well it is obviously important to learn some estimation techniques. First of all, however, it is fundamental to learn what estimates are, and what they should be used for — as strange as it may seem, many developers and managers don’t really know this.

Learn to Say “Hello, World” Paul Lee, username leep, more commonly known as Hoppy, had a reputation as the local expert on programming issues. I needed help. I walked across to Hoppy’s desk and asked, could he take a look at some code for me? Sure, said Hoppy, pull up a chair. I took care not to topple the empty cola cans stacked in a pyramid behind him. What code?

Let Your Project Speak for Itself Your project probably has a version control system in place. Perhaps it is connected to a continuous integration server that verifies correctness by automated tests. That’s great. You can include tools for static code analysis into your continuous integration server to gather code metrics. These metrics provide feedback about specific aspects of your code, as well as their evolution over time. When you install code metrics, there will always be a red line that you do not want to cross.