[​​White Belt] You use your development tools every day. Take a mental step back—the choices you made years ago may not be the best going forward.

Let’s start at the beginning: when it’s time to work, what program do you start? Visual Studio, Emacs, a terminal window? Before you ever get to writing code, you have the environment you program in. Your environment includes your computer, text editor, compiler, debugger, and so forth.

Chances are you’re using only a fraction of the capabilities offered by each of these tools. You can make big gains in efficiency with just modest investment.

Text Editor

A co-worker of mine who’s a machinist taunts programmers: “You have the easiest job in the world; it’s just typing.” Indeed, we do spend a lot of time typing. There are some other details involved, of course—programmers have an odd aversion to vowels and a special fondness for semicolons—but sometimes your bottleneck truly is getting characters on-screen.

Given all the time you spend typing, if you could make the text editor do some of the tedious work for you—maybe save 10 percent of your effort—can you imagine how much that saves over the course of a year?

If you watch a master programmer at work, the first thing you’ll notice is not the wizardry of their code; it’ll be their wizardry of manipulating their code. The master seemingly types ahead of the computer, because even as they zap code from one place to another in an instant, they’re thinking five steps ahead and could, quite literally, close their eyes for a few seconds and let their fingers catch up.

The Programmer’s Editor

This ability to blaze through code requires, first, a programmer’s editor. There are plenty of these to go around, from primitive-looking vi to fancy-pants TextMate. No matter what generation you choose, common properties of a good editor include the following:

• Keyboard-heavy operation. The mouse is optional. Learn the keyboard shortcuts for common operations because it’s a lot faster than constantly reaching for the mouse. This is why the old-school Unix editors are still popular; they make very good use of the keyboard. (If you think this is just for programmers, consider that any graphic designer worth their salt knows the keyboard shortcuts for Adobe Photoshop and Illustrator by heart. They work with one hand on the keyboard and the other on a graphic tablet.)

• Complex movement and selection tools. A programmer’s editor is smart enough to move among not just lines and columns but also logical blocks of code. With the cursor on a block, you should be able to select the block and move it with just a few keystrokes. And again, hands off the mouse.

• Language-aware syntax highlighting. For some, this helps to see the “bigger picture” of the code that’s on-screen; others don’t care. If nothing else, it makes your code look a lot fancier so that snooty machinists think you’re doing something more than mere typing.

• Language-aware indentation. There’s no reason to hit the spacebar a bunch of times to indent each line; a good editor will assist you with indentation rules that match your programming language and preferred style.

• Text completion. Once you’ve typed a long variable or function name, there’s no reason to type it again. A programmer’s editor will allow you to type part of the name and hit a key to autocomplete the rest. (Where the part you typed is ambiguous, usually hitting the autocomplete key repeatedly will cycle through possible matches.)

The second key to blazing through code is simple: put in your time. Fancy editors take a long time to learn, so set aside a little time each week to learn a new trick. You can’t do it all at once, because you need to get the tricks into your muscle memory. This means it’s instinctive; your fingers do the actions automatically without your conscious mind involved—your conscious mind stays focused on the code.

Finally, watch some of your senior peers at their editors. Do some pair programming with them driving, and as soon as you think, “I didn’t even know you could do that!” take a note and figure out how they did it.

Editing Over SSH

It’s common in a programmer’s workday that you need to access a remote machine through a simple SSH, serial, or other text-only console. You need to learn the basics of one editor that can run in text-only mode. It doesn’t really matter how many tricks you can make your GUI editor do when you’re on another machine at a console prompt.

For this purpose, I recommend vi.^[17] vi is on any Unix-like machine you’ll walk up to. Others (notably Emacs) may or may not be there. Therefore, if nothing else, spend an hour learning enough vi to make simple changes. It’ll pay off the next time you have a server that’s half-dead and only bootable to a single-user console.

Language Tools

We’ll discuss programming languages in Tip 10, ​Speak Your Language Fluently​, but for the moment let’s briefly consider the tools that are part of your environment. These commonly include compilers, debuggers, or interpreters. In an IDE, there’s usually a button for build that invokes the build system, usually compiling code. Whatever it is, learn the keyboard shortcuts, and don’t go hunting for the mouse every time you need to build.

Some languages don’t have compilers; they are interpreted, and they often have a Read, Evaluate, Print Loop (REPL) that lets you type expressions and print the result immediately. The REPL is an essential time-saver because you can get quick answers to questions without needing to run your whole program. For example, if you need to do some fancy transformations on data, pop open the REPL and try them with some sample data.

Some environments integrate the development tools in novel ways. First, they may bring the REPL into your text editor and allow you to take the current line, evaluate it using the language interpreter, and print the results right in the same window. Talk about immediate gratification.

Second, some environments include language-aware refactoring features that let you (for example) rename a method and also rename all calls to the method. Behind the scenes, the environment is constantly compiling or interpreting your program so it refactors with real smarts—not just a global search and replace.

Debuggers

Many environments include a source-level debugger. This allows you to stop program execution—by crash or by choice—and inspect the state of the program, such as the call stack or values of variables. In a language like C where a crash is typified with the unhelpful message “segmentation fault,” a debugger is essential to getting even basic information about a crash. Fancier languages will usually dump the call stack, which may be all you need to identify the problem.

Debuggers tend to come with a price—they slow down execution of the program. This can cause timing-related problems to pop up or go away. These are affectionately known as Heisenbugs, bugs that you can either experience or try to debug, but not both at the same time.

Depending on your platform, the debugger may be helpful in doing post-mortem analysis, too. With C programs on Linux, for example, a crash can generate a core file, which includes a dump of system memory. The debugger can load the core file and tell you the state of threads and variables at the time of the crash. (The term core refers to magnetic core memory, an early form of RAM that hasn’t been in use since the 1970s. The term is still used to refer to RAM in general.)

If you’re good at writing unit tests, chances are you won’t need the debugger much; you’ll catch most bugs with your tests. Bugs of the simple duh! variety are easy to test. However, some classes of bugs—especially those dealing with timing of IO or threads—are extremely hard to catch with automated tests. For those, hope for a good core file or stack trace.

Profiling

What about situations where the program is technically correct but too slow? Knuth wrote, “Premature optimization is the root of all evil.” To this end, write your code to be correct first. If you have a performance problem, measure the problem before trying to fix it.

This is what a profiler does: it tells you how many times each function is called and how much time is spent in each function. The results will often surprise you. For example, I profiled a toy Sudoku solver of mine and discovered it spending most of its time iterating over its list of cells. A small bit of caching made it run 3,000 times faster.

The most baffling performance problems are when your program is just sitting there and doing nothing most of the time. This can occur when there’s contention for a resource; the profiler will show your program spending a lot of time in the function used to lock the resource. Or it may show that the problem isn’t in your program at all—perhaps it’s a network resource that’s slow, and the profiler will show your program waiting in the network receive function.

Actions

Fortunately, you won’t have any problem trying development environments—you use one every day. However, focused practice can help you get more out of your environment.

Text Editor Tricks

As mentioned, you need to do this one over time so you can build muscle memory. Commit to learning one new trick a week.

• Learn to move between files with only the keyboard. Bonus points if your environment is smart enough to know some relations between files, such as hopping between application code and its unit tests. Then learn to navigate quickly within a file: by page, by function, by block of code. Then within a line: beginning and end, word by word.

• Learn to select the current line and current code block. For editors that have multiple clipboards, learn to cut and paste more than one thing at a time. (In Emacs this is known as the kill ring.)

• You can usually spare some typing with autocomplete features. These may be language-aware; for example, your editor may know the standard library functions and allow you to select one from a list as you start typing. Others will allow you to complete a word based on other text in the file, which is just as handy. Learn these shortcuts; they’re a tremendous time-saver.

• Most editors can auto-indent your code. Turn this on, configure it for your style, and say goodbye to your Tab key.

Compiler/Interpreter Tricks

• The first trick is turning on warnings, a feature offered by most programming compilers or interpreters. These warnings aren’t always bugs, but you should check each one to be sure—then fix the code to eliminate the warning. (In legacy code this isn’t always an option, but try when you can. “Warning spew” just causes programmers to ignore warnings, and you could miss something important.)

• For projects with a build/compile step, learn the keyboard shortcut for building your project.

• When there are compile warnings or errors, they come with a file and line number. Learn the keyboard shortcut to hop to the source code indicated by the current error.

• If your language has a REPL, learn the keyboard shortcut to start it.

• If your environment has refactoring features, learn the keyboard shortcuts for renaming a method, renaming a class, and extracting a block of code into its own method.

Debugger Tricks

• Learn the keyboard shortcut for starting your program in the debugger.

• Get a stack trace from a program crash. This shows the nesting of functions and answers the essential question, “How did I get here?”

• Set a breakpoint in your source code, and then run the debugger and get there. Breakpoints are essential when investigating a problem before the program crashes.

• If your platform supports core files, learn how to turn them on. Force a crash to generate a core file, and then load that into the debugger.

Profiler Tricks

You don’t need the profiler often, but you should know how to run it and interpret the results.

• Programmers love sorting algorithms. Implement a couple of list sorts—don’t forget bogosort^[18]—and run them with 10, 100, and 1,000 (or more) elements under the profiler. As the number of elements increases, you should be able to clearly see the difference in execution time between the algorithms. (Bonus points if you can determine the order of growth—Big-O—for each algorithm based on your data for number of elements vs. execution time.)