I had a few requests for at least one article geared towards those just beginning to learn about development. I want to clarify: I don’t mean beginning computer science, I truly mean development. The distinction being one of “implement this boilerplate alongside some custom validation” and “implement operations on this red-black tree.” So this will be the first installment in what undoubtedly will be a very sporadic series aimed at those beginners. Though, there may be useful information for the general audience, maybe even non-developers as well! If you’re further along in your career, maybe this will be useful for you if you’re looking at teaching someone else or assuming a mentor role.
So to start it off, I wanted to tell you about my favorite and potentially most important tool. I rate this as more important than a compiler, computer, linter, documentation reference, etc… Because with this specific tool (well, two really), you can still perform the important parts of software development without much trouble. In fact, you can perform it in the abstract and not even worry about things like language choice and implementation concerns. Pure development!
I’m talking about a notebook and pen. Very specifically a pen. More on that later, but for now let’s suffice it to say that we want something permanent.
This discussion was prompted by feedback from someone I’ve been working with and teaching. I kept stressing the unique usefulness of doing some of the complicated work in a notebook with a pen first, and he didn’t believe me. However, trying it for a while got him to understand the importance of the notebook, but without being able to articulate quite why. So, let’s articulate!
First, using a notebook for untangling problems demands you slow your thinking down and externalize it. I sometimes find myself thinking incomplete thoughts, but I’ll try to act on them in a “Ready! Fire! Aim!” approach. It creates frustration as you end up midway through an implementation of your incomplete idea and realize that there was a problem that you overlooked, and now your implementation has a huge hole where something just won’t work as planned. These are the times where slowing down and thinking carefully pays off. The kind of thinking facilitated by a notebook. Let’s be clear: this isn’t any kind of formal analysis either. Even something as mundane as describing what you’re up to, as though you were trying to explain it to someone else (like the world’s most boring pen pal), will allow you to clear up your thinking. You can also see if you made a staggeringly ignorant assumption because in the midst of writing you may ask yourself “What… am I doing?” If you experience that moment, congratulations: you’ve just mined up a gem. Enjoy the extra time you now have, as a few minutes of writing just saved you potentially hours of coding.
Secondly, you’ll remember that earlier I stressed the importance of a pen over any other kind of writing utensil. You’ll also notice that I stressed a notebook over just using a word processor or other kind of software. I should go so far as to say a tablet and stylus don’t count. Unless it’s a clay tablet and stylus. Then… maybe. Part of it is the tactile effect of just using real paper, but also it’s got to do with permanence. Plus, if you begin this process at the computer, you’ll eventually slip into just writing the code for the half-baked implementation in your head and we’re back to square one. Also, you can take a notebook to, say, a lake, and stare out over the water moodily and look all poetic when in reality you’re just figuring out what properties your user model will need. There’s an advantage there, somewhere, but not really related to development. I think.
Oh, right, the point. I was going to make a point about permanence.
The point is that the permanence of pen and paper allow you to have a record of your thought process over time as you work through a problem. This will give you useful insight into how you approach problems, and that’s great since your job, as a developer, is pretty much solving problems all day long. But it also keeps you from retreading old ground. If you begin to make the same assumptions that you’ve already discarded, having an indelible record of that has great value. You really, really don’t want to be able to erase the trail that led you to where you are.
There are also benefits that stem from the fact that a notebook, an actual paper notebook, is not an internet connected device. It has a pretty limited set of functions. As you work through a problem, you’re undoubtedly going to reference something on the internet. This is the way of things. That’s fine, and encouraged! But that information could be confusing if you haven’t developed the necessary mental framework to fit that information in and contextualize it. Taking a step back from the machine and spending some time being unable to look stuff up will accelerate you towards a holistic understanding of what you’re grappling with. I don’t really want to make it about productivity, because maybe you’re building something useless for your own amusement. So let’s not make it about productivity.
Finally, and maybe most obviously, it’s paper. You can draw on it. You should draw on it. Constantly! A bunch of problems in this discipline are represented well by pictures. In fact, that was one of the go-to methods a former professor of mine had. He would introduce a problem, discuss it for a bit, and then suggest that a reasonable way to get one’s head around the issue was to step back and draw a picture. He’d then struggle with the perpetually-out-of-ink markers for the whiteboard for a bit before finding one that worked. Such is life.
Frankly, most applications I’ve worked on have had a useful picture hiding somewhere. Is your login service subject to certain checks beyond whatever login framework you’re (hopefully) using? Got something well-represented by a state diagram? Working on a graph traversal algorithm, or a set of tables that have an above-average complicated relationship schema? Trying to get some tables beyond 3NF? Each and every one of these benefits from some degree of sketching out the problem. I can almost guarantee that you’d have an easier time working your way to a solution. It’s not a coincidence that, when looking these things up, you often find them explained alongside a detailed diagram.
Personally, I’ve filled up several hundred pages at my current job. I have my own little organizational schema for them so that if I end up having to look back over old notes it doesn’t take long for me to find what I’m after. It’s proven to be very valuable over the years because as old projects get dredged back up for maintenance or feature requests, I can remember what I was up to pretty quickly. This is because everything is supported by a myriad of notes, diagrams, and pictures.
You probably have some sort of project management software, or bug trackers, or feature request trackers. Or just a bulleted list in an email about stuff you have to get done. This is fine. It may seem redundant that you’re going to be generating a lot of information on a medium that is significantly harder to share, and then probably regenerating that information in one of those other mediums. That’s because it is redundant. However, it’s acceptable redundancy. You want this information passing through the parts of your mind responsible for processing it as many times as possible. Slowing down and really digesting it as you record it on lined (dotted or unlined is fine, too, I guess) paper encourages clarity as you transfer it elsewhere. You don’t swallow your food without chewing it, right?
I will say that a bunch of the insights you get from this will be subtle. You might not notice them until you’re several pages deep. You might have one or two big insights right away, and that would be exciting! But maybe treat yourself to a nice pen and notebook and give this a try.
Joe Writes Software 