The Basic Tools
Good tools well-learning become an extension of the programmer's body to reach the end goal. They amplify our talent, help us learn more specialized tools when needed, but we can't be too limited by our tools. Be comfortable with a set of basic tools.
The Power of Plain Text #
A coder's power comes from knowledge, and the best expression for it is plain text. Plain text is a group of printable characters that can be read and understood by people. It can still have structure like most programming languages have, but don't divorce the text from its meaning and story it in compressed binary.
The benefits are human-readable data will outlive all other data forms and their applications. Almost every computing tool can operate and use plain text files, giving it lots of leverage. This also makes it much easier to test.
Plaintext may take more space or memory, but it's usually worth it unless specific requirements don't allow it.
Shell Games #
The center of a coder's work is the command shell, which lets you manage all your work and tools in any number of ways. GUI environments are great for simple tasks, but limit you from benefits like task automation, extra functionalities, or combining tools.
The shell lets you go beyond what you see and what the GUI designer intended. Using it has terse or obscure commands, but they pack a wallop. Learning it is daunting but well worth the effort. These commands can also be saved to script files, so you can save command sequences and automate more complex tasks.
Power Editing #
Text is the raw material of programming, so you need to add and edit it effortlessly.
It's recommended to learn one editor very well and use it for as many things as possible. Keep all the memorized and custom keystrokes to one place so you're not jumping between different ones. Otherwise, you'll resort to linear editing instead of saving time with your shortcuts by instinct. Make it so you can handle common tasks without your hands leaving the keyboard.
Aim for an editor with the following features:
- Configurable — from styling to keystroke bindings.
- Extensible — it can be used with new programming languages and environments.
- Programmable — make it perform complex, multistep tasks with macros or built-in scripting programming languages.
Some other good features to aim for are syntax highlighting, auto-completion, auto-indentation, code boilerplate, helper system tie-ins, or IDE features.
Being fluent in a text editor boosts your productivity many ways. The simple amount of time you save with shortcuts and keystroke bindings could give you an extra hour or two each day. They could alphabetize a list of statements for you and save you some cognitive energy. If you already have a favorite editor, dig deeper into its functionality to see how else it can save you time.
Source Code Control #
The undo key is vital in most interfaces, but coders may want to undo code they wrote weeks ago in different sessions. Source code control is a giant undo key, to the point where it's a time machine. No matter what the project is, always use it.
They track every change with important data about each one, like who made them and what the differences are. It's useful for tracking bugs, auditing, assessing quality, and many other important things.
Source control also lets you manage specific releases while building out new functionality and bug fixes in other "branches" that can be merged in later. Multiple users can also work on the codebase, at the same time and even on the same files.
A huge benefit is product builds that are automated and repeatable. It deploys on its own, checks for errors, saves coders lots of time and energy, and can run on set dates.
As of this note, the most popular source control tool is Git. Use that as a starting point if source control is new to you.
Computer programs are only as perfect as we write them, and no one writes perfect software. So removing issues or flaws in a program will always be a core skill.
There's a psychological element to it, since bugs stem from what coders have written. It's easy to deny responsibility or cast blame. But that doesn't change the fact it must be fixed, so don't waste energy on the blame. Try to turn off your defense mechanisms and don't panic. Take time to analyze its cause and don't just deny it could be happening or treat the symptoms but not the underlying problem.
Some good approaches to keep in mind:
- Make sure the code compiled correctly and without warnings, as they could find the bug for you.
- Verify the bug and its cause. Try to duplicate it locally and gather as much info about its cause (including what the user did to cause it). Replicate it in as few steps as possible so you'll know when it's gone.
- Visualize the data or the process that creates the bug, with a program or by hand, to better understand it.
- Add tracing statements on the process that leads to the bug. If a complex calculation gives the wrong result, log the answer at different stages to see where it goes wrong.
- Explain the bug to someone else, since having to say your assumptions out loud can bring you a new insight. If no one is around, use a rubber duck!
- More often than not, your application code will contain the bug, not the OS, database, or third-party library.
- If you just changed "one thing" and everything lit on fire, that one thing probably caused the bug, even if it seems unrelated.
The more surprising a bug is to you, the more work you'll need to do finding what wrong assumptions caused it and how to prevent this from happening again. Add tests that will catch it faster in the future. See if the same kind of bug could appear elsewhere. Discuss it with the team if needed.
Text Manipulation #
Text manipulation languages are powerful yet risky tools. As the name shows, they're languages that directly manipulate text in files, doing things like adding new lines, incrementing numbers, or running a search and replace. Some can also handle larger tasks like talking over networks, working with other programs, or going to web pages.
The book gives Perl as a preferred example. The authors give examples of using it to turn a plain database schema into the needed SQL statements, scripts to check its integrity, web pages with more info on them, and more. They also used Perl to include this book's code examples by pulling named segments from a source file, highlight the needed syntax, and converting the result as needed.
You can get a lot of mileage out of text manipulation. Including writing code generators.
Code Generators #
To cut down on repetition and mistakes in the face of a large-scale coding task, programmers can write code that writes other code. There are two types: passive and active.
Passive code generators create code for us once, and then we can do whatever we want with the result. They're like templates with some added parameters, and they then become regular source files. They can also make one-off conversions from one language to another. Since the resulting code is often edited afterwards, it doesn't always need to be perfect.
Active code generators are run multiple times, whenever we need their results. They can take one form of knowledge and convert it to other forms as needed. Since the result is disposable and can just be made again, it doesn't count as duplication. For example, generating structural code based on a database schema. You'll often need to make this generation progress part of the overall build process.
For either type of generator, simple input makes for a simple generator. The only complex part is usually the parser that tries to understand the input file.