As the chapter title implies, the authors went through the tools that they think should be employed in all software projects. There were a good deal of allusions to carpentry. I felt like this was an introduction to ubiquitous tools like the hammer and the phillips screwdriver.
Plain text is explained as being printable characters that can also be read and understood by a human. The authors mention the idea that data and code (you might argue that they are one and the same) are knowledge, and any knowledge that remains readable by humans will outlast any other data. Period. So use plain text when possible. Or, keeping in mind space and speed constraints, when pragmatic.
The tip here is "use the power of command shells." Command line applications are very specialized tools, with a great deal of depth, and they are inherently orthogonal, which means they can be combined in countless ways. They're also fairly universal (except on Windows), so knowing how to use them affords you a great deal of power in all kinds of environments. It was pretty interesting to see their sample use cases and their corresponding GUI alternatives. What a pain in a GUI! Speaking of which, this quote spoke to me:
"A benefit of GUIs is WYSIWYG - what you see is what you get. The disadvantage is WYSIAYG - what you see is all you get."
Though they don't recommend a single editor, Hunt and Thomas recommend that you become extremely proficient in one cross-platform editor.
"If you want to draw water you do not dig six one-foot wells. You dig one six-foot well."
- Reza Aslan, via various disputed sources
This editor should be configurable, extensible, and programmable. That is, every aspect of the editor should be customizable; it should be easy to extend, by which I suppose they mean by third parties; and you should be able to script and automate multi-step processes.
This chapter reminds me that my skill with my favorite editor, Sublime, is not very good. I should probably also learn vi because it's everywhere.
"Tip 23: Always Use Source Control"
At this point in my programming career, I feel as though the benefits of source code control, or a version control system (VCS), are obvious to everyone. But basically, VCS lets you save snapshots, or commits, of code along a singular path of development as well multiple divergent paths of development, should you want to explore different implementations. This gives you reversibility, should you want to go back to an earlier commit, and at least with git, orthogonality in that you can cherry pick changes from different commits. It also makes integrating changes from other developers far easier.
There is no reason not to use source control.
Apparently, debugging is deeply intertwined with one's ego - much of Thomas and Hunt's introduction to this chapter has to do with psychology and blame.
"Tip 24: Fix the Problem, Not the Blame"
Though I don't have much faith in my own code to begin with, and therefore have little problem accepting that my code has flaws, I have become very frustrated with fixing bugs in legacy code before. Many times, it was due to the work that we had outsourced to what ended up being extremely novice programmers in China. I know that I spent far more time blaming them than I should have. But there's also the internal struggle that I faced, staring at code that should have become obvious over time - and didn't. It probably would have helped if I had employed a strategy other than "stare and hope I get smarter," strategies like the ones the authors espouse in the book:
- Don't panic
- Don't waste time thinking "that's impossible"
- Always try to discover the root cause of the problem
- This was something I learned from my coworker at Aggrego, Dave Willkomm.
- Start with syntax - use the highest compiler warning settings
- Watch the user reproduce the bug
- Automate the reproduction of the bug
- Visualize data using a debugger or something like print statements
- Trace the control flow programmatically
- Check corrupt variables and their neighbors in memory for clues
- Use the rubber duck debugging method
- Use the process of elimination to identify where the bug lies
- Question everything - if the bug seems impossible, check your assumptions
Thomas and Hunt provide a far more concise debugging check list at the end, so check it out.
I didn't really understand this chapter. The gist that I got from it was "use scripting languages to get stuff done really fast." As a Ruby developer, this comes as either no surprise, or just plain confusion. What does it mean when a language is a "text manipulation language?"
Perhaps I am just too new to this software development stuff.
Here's another chapter that I wasn't exactly clear on, though I have used generators, such as the Rails generator, before. However, while the previous chapter was purely a haze of confusion, I am well aware of what generators are for, I'm just not sure when to use them or how to implement them.
Code generators are essentially code that generates other code. The example that sort of made sense to me was a bit of code that turns a database schema into various Structs. That kind of made sense - the structs model the data in the schema.
Otherwise, I'm not even entirely sure what a code generator is, to be honest. Going by the definition of a code generator in the book, which says all generated code is disposable, I'm not sure the Rails generator counts as a code generator. The code that it generates is generally not disposable. I'm thinking something like a templating language, such as HAML or ERB is a code generator because the markup is generated on the fly every time.
Anyway, I'll have to come back to this.
~
I think my inexperience is beginning to show. Any of the challenges at the end of the sections involving parsing, compiling, or implementation were immediately beyond me. The author described writing a DSL in the previous chapter with a nonchalant air, for instance, and I'm absolutely not at that level of comfort with programming.