In 20 years, I’ve been asked to give my opinion of other developers many times. It’s very rare that I’ve rated someone
as a free electron. One thing that all of the outstanding developers I have worked with have in common is an excellent understanding of five basic tools. Learning these tools properly will seriously boost your productivity.

1. Text Editor

You write code for a living. You spend hours a day typing into a text editor. Do you know all the keyboard shortcuts for it, or do you have to reach for the mouse to navigate around? The choice of text editor is up to you – vi(m), emacs, Notepad++, Sublime, the Visual Studio built in editor are all fine choices. Good text editors have advanced selection tools ( select line/block/function ), search and replace, jump to function definition/declaration/start of block, code completion and syntax highlighting. You should be able to use all of these features without reaching for your mouse.

Time spent learning these features will pay back massively over time, as your can spend your time thinking about your code, rather than your editor.

You can touch type can’t you? I’ve seen developers with a two finger hunt and peck technique in the past. If that’s you, go and do an online touch typing course. Now. Read the rest of this article when you are done.

2. Compiler

You probably won’t have a choice of compiler. It will depend on the language you are using, and the platform you are running on. You should still understand how your compiler works. Can you run just the preprocessor to debug faulty includes? Do you know what all the command line options can do – what can be turned on and off without breaking the compatibility with other objects? If you are using the Visual Studio C++ compiler, do you know why you shouldn’t build code using the default Debug mode if you are linking to Summit API libraries? Do you know how to make useful objects for debugging anyway?

You should be able to answer these questions. If not, take a good look at your make output, and understand what all of those command line options are doing at every stage. Once you understand what your build does, go and read the rest of the manual.

3. Debugger

Do you debug by adding printf() statements to your code? Simple and easy, but it takes time to add all that code, add some more lines when it’s not covering the right code or printing the right variable, then you need to analyse the output and remember to take them out again. Maybe you don’t remove the print statements and bloat your code and output files instead.

Alternatively, just fire up the program in the debugger, insert some breakpoints and step through the troublesome part of the program, inspecting whatever variables you need to as you go along. You should be analysing crash dumps or core files rather than adding more print statements. You will need to master how to connect to processes that are already running, how to set breakpoints in libraries that are loaded into running Summit servers, and how to conditionally trigger breakpoints. You’ll need to make sense of the output – and that will really expand your computing skills.

When you’ve got your debugger working right, you’ll get to the bottom of bugs so much faster. If you must use the printf approach, go and learn about log4cxx or log4net and use those instead.

4. Shell

cmd, cygwin, Powershell, ksh, zsh or bash. Whichever you use, you’ll be running a whole heap of commands in your shell over the course of a day. You should know your shell capabilities. Aside from the standard stuff : command history recall, setting variables and navigating your way around, you should be able write shell scripts to automate your work, set up aliases and functions to speed common tasks and shorten your typing effort.

Watching a developer using his shell is the fastest way I know to form an impression of how efficient they are. Good developers have functions, shortcuts and scripts to make navigating directories, loading environments and launching processes a breeze.

5. Source Control

Why do so many Summit developers dislike source control? Probably because it’s been imposed on them by corporate standards, they don’t understand how it works, so commits and merges are an exercise in time wasting and frustration.

Learn how your source control system works by reading a suitable manual. There are excellent books online covering Subversion and git for example. Learn all about branching, remote repositories and how the internals of your system works. You should be able to set up administer a repository by yourself if you have to. Once you know how your platform works, your submitting your releases will become less of a frustration.

It’s not just about making releases painless. Once you have mastered source control, you’ll be able to quickly work out who introduced bugs, and when they did it. You can experiment with new features and throw them away easily without breaking anything.