Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. The Power of Plain Text

As Pragmatic Programmers, our base material is knowledge. The best format to store knowledge persistently is plain text, so that we can manipulate it with different tools. Example of plain text: "milk" (my favourite drink 😉).

Plain text doesn't mean it's unstructured: HTML, JSON, YAML and so are all plain text.

Human-readable forms of data, and self-describing data, will outlive all other forms of data and the applications that created them.

2. Shell Games

For a programmer manipulating files of text, that workbench is the command shell. Yes, it's the tool that you see a lot in the blockbuster movies when someone's hacking the enemy base.

For programmers raised on GUI interfaces and IDEs (like me!), this might seem an extreme move. After all, can't you do everything equally well by pointing and clicking?

The simple answer is "no". A benefit of GUI is "What You See Is What You Get", and the disadvantage is "What You See Is All You Get".

Gain familiarity with the command shell, and you'll find your productivity soaring. Once you do, you should customize your shell to suit your needs. Some common customization:

• Setting color themes
• Configuring a prompt
• Aliases and shell functions
• Command completion

3. Power Editing

Choose and use as many editors as you want, and Achieve Editor Fluency. You may gain more time to spend if you improve your code editing process.

What does "Fluent" mean? Find your way if you can code without using a mouse/trackpad because you can keep your hands on the keyboard with all the shortcuts you know to navigate around.

To move towards fluency, check if you are doing something repetitive, get into the habit of thinking "there must be a better way". Then find it, and practice it to become your muscle memory.

Grow your editor by digging into the extension that may help you. If not, try to write it yourself.

4. Version Control

Version control systems keep track of every change you make in your source code and documentation.

It does far more than undoing mistakes. It can also track changes in detail, such as the code author, the time, the files, the lines of code. They are invaluable for bug-tracking, audit, performance, and quality purposes.

One of the most powerful and useful features is the branch, to isolates your work until it's ready to be merged into the main code.

With version control, you can always roll it back if something happens. Learn them now, not when the disaster strikes and you are under pressure.

5. Debugging

No one writes perfect software, so it's a given that debugging will take up a major portion of your day.

Embrace the fact that debugging is just problem solving, and attack it as such. It doesn't really matter whether the bug is your fault or someone else's. Fix the Problem, Not the Blame.

The first rule of debugging: Don't Panic.

Always try to discover the root cause of a problem, not just the particular appearance of it.

To improve the accuracy of the bug report, you may actually need to watch the user who reported the bug in action to get more detail.

To discover the bug better, you must brutally test your application with a realistic end-user usage pattern. The best way to start fixing bugs is to make it reproducible.

The most important rule of debugging: Have the failing test before fixing code.

To isolate the bug, look at the problem. Read the Damn Error Message (yes, the book highlights it clearly).

You can eliminate the culprit faster by doing the "binary chop". Choose a stack frame somewhere in the middle and see if the error is manifest there.

(personal tips: With git, you can use bisect to do the "binary chop")

Diagnosis your code with Logging and/or Tracing, by adding custom messages around the suspected codebase to print the valuable information in your screen or development console.

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. By explaining, you need to think step by step and you may gain new insights into the problem. If you're alone, use the rubber duck.

When faced with a "surprising" failure, you must accept that one or more of your assumptions is wrong. Don't just assume the cause, but prove it.

6. Text Manipulation

Learn a Text Manipulation Language. These languages are important enabling technologies.

Using them, you can quickly hack up utilities and prototype ideas, which may take five or ten times longer with conventional languages.

Some examples of Text Manipulation Language are Perl, Python, and Ruby.

One of the challenges: Write a program that converts YAML to JSON format.

7. Engineering Daybooks

Pragmatic Programmers use daybooks to take notes in meetings, to jot down what we're working on, note debugging process, leave reminders, wild ideas, or just doodle.

Three main benefits:

• It is more reliable than memory.
• Store ideas that may not immediately relevant.
• It acts as a kind of rubber duck.

Use paper, not a file or a wiki. There's something special about the act of writing compared to typing. Try a month and see if you're getting any benefits.

---

What do you think of your current programming tools? Please share your thoughts in the comment and I'll be happy to respond!