Awesome chapter. Really enjoyed it. It talks about the tools you use on daily basis and how important they are. We are craftsman. The tools we use for developing must be an extension of our body; fully personalized/configured with the exact setup that works for you. We need to use tools for very different jobs, and they must be the very best options out there; and for the sake of productivity we must master them.
Is a human friendly representation of knowledge, easy to manipulate, share, track history of and that is an insure against obsolescence.
The good news is that everybody is using plain text for... everything. So we have tons of tools for manipulating it. From code editors, programs that have as input and output text (almost all *nix tools does), protocols, etc.
I think that there is a key advantage of using unix like tools instead of Windows-like environments (even Mac OSX). You have a terminal that provides tools to manipulate files really easy, to search thru the file system, etc. In other languages where the Operating System if your IDE you lack this tools, or, at least they are limited and not scriptable (not as easy as nix systems).
The IDE for me is a prison of already done decisions of how you are expected to work with some technology. When you start working on something probably this already made decisions help you on your productivity by hiding some of the underlying logic behind the programming process. Somebody defined once 'compile' as "the green button on VisualStudio". Once you are familiar with your environment, if you are using and IDE you'll lack some functionalities like automation. This is when you should learn to use more powerful tools such as command line tools. They have a higher learning curve, but your imagination is the limit of what can do with them.
While the book tells us that there are some ports of nix tools for Windows I personally thing that they suck and are a bad substitute for the real ones. Try to use nix-like OSs when possible.
Use a Single Editor Well
I would say that you must master it. Configure it to the max. Every 6 months try to learn new stuff that is native build or try to discover new plugins. See what other co-workers are using and what is more useful for them. Make the editor to be an extension of your body. Your configuration files is your most precious asset when it comes to an editor.
If somebody sees you using your editor its perfectly OK if they don't understand a thing of what you are doing and how you are doing it so fast.
About the editor itself, try to learn one of the "pro" ones. Search out there what are the best editors for programming, play a little bit with some of them and choose the one you like the most. And stick with it. After a while you may be tempted to try another editor; do it. But if you did the right choice the first time you'll go back.
Always. Use. Source. Code. Control.
My good friend IJ taught me everything I know about source control management systems, he really like them and I must admit he successfully transmited this passion to me; not being obssessed on how they work internally but rather how to use them and how to organize stuff.
The most important thing about repository is to use it, or not. If you use it wrong, its OK. You at least will have a history, a record of your changes overtime. You can learn how to use it better and introduce new workflows. If you don't use it because it adds overhead at your project you are probably going to pay the price of it in the future by having to debug strange bugs that were introduced at some point but don't know when or by who.
Again, merging divergent history can be a hell if you don't use it a source code system; I've never done it myself in the 'manual way' but it can imagine it.
One more thing you can do when using a repository is to automate builds; this way you have a automatic and repetable way of building your product.
Fix the Problem, Not the Blame
It is your work to fix the problem. Don't worry about 'who did it wrong' or the 'why it has failed'. Fix the problem. Prevent it to happen again.
A good approach is to find a way of reproducing the bug, isolate it from the other code or the context. Some times bug reports are not as good as you wish but try to retrieve as much information as you can about the problem when it happens, how to force it and for how long has been happening.
Remember, just in .1% of the cases the bug is NOT in your code, namely the OS, third party (serious) libraries, drivers, etc... Sometimes you'll think that the problem is not in your code. Probably you are not doing enough tests and you are assuming stuff (that your code works; and obviously it does not). Don't assume things. Prove it.
A common technique to find a problem is 'rubber ducking'; try to explain to somebody (even a rubber duck) all the process and the parts implied in the process. While explaining you'll find an inconsistency and the bug.