I’ve spend much of this week writing code for a fairly significant update to some software my team rolled out in May. Much of it was refactoring (from about 4,000 lines of Groovy script down to about 900), some of it was making things more efficient, and a lot of it was to make the code more supportable as time goes on. There were also a lot of important enhancements and bug fixes. Each day began with me sitting in front of code, disappearing into the code, and emerging only reluctantly to the world when my brain was too tired to continue.
Those of you who write code for a living know what this feels like. On Friday night, for instance, as I write this, I was completely spent. As much as I wanted to continue reading the (thus far) fantastic book by Joe Posnanski, The Baseball 100, I needed a break from reading. It was all I could do to pull myself back to the computer to write this. The family went out and I wanted to go with them, but I wasn’t feeling social. That happens sometimes after spending a week in code.
So what’s a fellow to do?
I think I found a pretty good solution: I discovered that The Show ’21 is finally available for the Xbox One. And I started playing it. I played my first game as the Los Angeles Dodgers facing Tampa Bay. And despite it being my first game, and despite the fact that my hand-eye-coordination could use some work, I played a full 9 innings and beat Tampa 6-5. It was blissful.
Either you are a baseball fan or you aren’t. I’ve rarely met someone in between. People sometimes wonder what’s so great about the sport. You hear all kinds of arguments from baseball fans (of which I am one), but the best line I’ve ever heard is simple: baseball is there to be enjoyed. And I enjoyed it tonight, even though it was in a video game. I love the dynamics of the game, the skills required not just on the athletic side, but on the mental side as well. I love the instincts that develop: flipping that grounder to second because you know without looking that there is already a running on first. I love the chess match between pitcher and hitter, each trying to outguess the other. And of course, I love the history.
It’s been many decades since I last thought that playing in the majors could be a reality (I think I might have been ten). But playing The Show tonight after spending my week coding made it feel like I was playing in the majors. It made me feel good, and that’s just about the best think a video game can do.
I played one game already, but it’s a beautiful evening for baseball. As Ernie Banks would say, “Let’s play two.”
Did you enjoy this post? If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!
What we really mean when we say, “people should know how to code” is that people should be able to use tools to deliver value.
I’ve been coding for most of my life. I saw my first BASIC on a Timex Sinclair. I loved the logic of coding. A year or two later, I got a Commodore VIC-20 and had everything I needed. It took a while before I mastered BASIC, and moved onto other languages, but I did, and today, there are a dozen languages that I can code in comfortably.
After reading Mike’s piece, I thought about what he said about what we really mean when we say people should know how to code. While I agree that it often means that people should be capable of using tools that deliver value, it is the question of value that stuck with me. What value has knowing how to code produced for me? It breaks down into two areas: practical value, and what I call “comments and clarity.”
The practical value of coding
Knowing how to code got me out of the dish room in college and into the cafeteria office, where I began writing programs to help the staff manage the cafeteria budget. That, in turn, led a job not long after graduating–a job and company that I am still with nearly 27 years later. So, yeah, knowing how to code got me a career, and there is obvious value in that. What else? If I have a problem to solve, I can often solve it though code. A few examples:
When we were looking for a house, I wrote code that would pull data from listings and filter the list down to the most likely candidates. Instead of manually searching through listings, I had the code do it for me, and we just had to look at the results.
When I wanted a better way to track my writing, I wrote my Google Docs Writing Tracker, which worked great for me (and quite a few others) for many years.
In order to automate my daily notes in Obsidian, I wrote a script to make it happen and save me a bunch of time.
I’ve written countless scripts to automate the repetitive tasks in my life. Some of these are a few lines of code, others are thousands. Together they free up time so that I can focus on the things that are more important to me.
The value of comments and clarity
Comments
It is incredibly difficult for me to hold everything that a big piece of software is doing in my head at one time. This is why comments exist in code. I use comments in code to remind myself why I did something in a certain way, or how a particular function works, or sometimes just a reminder to clean something up later. I’ve even written comments critical of my own code: “This is an ugly hack, but it works” used to be a standard refrain of mine.
Commenting helps me think about there things: (1) how the code works, (2) why it works the way it does, and (3) how it could be improved. Comments are both descriptive and introspective. They are a form of written observation. I have applied this concept to my life more generally:
I’ve kept a journal since 1996, which is just another form of commenting, both descriptive and introspective, and one in which I seek ways to improve.
In my day job, I am known for having exhaustive notes and documentation on just about everything I do: another form of commenting.
Commenting helps me to understand myself and what is happening around me. It preserves memory, while providing a space to “show my work” and learn from my experience. My comments–journal entries, daily notes, Field Notes notebooks–provide a baseline from which I can look back or ahead for improvement, failures, and learning.
Clarity of thought
A program compiles or it doesn’t. A semicolon in the wrong place, a mistyped variable, a greater than sign instead of a less than sign, a problem with the logic of a decision tree, a faulty data structure–any of these things can prevent a program from doing what it is supposed to. Repeated attention to the strict and unforgiving nature of coding helped to build a clarity muscle, one that strengthens my clarity of thought.
To me, clarity of thought is the ability to focus in on what matters in a particular situation. It is the ability to tune out the pieces that don’t play a role, and look more closely at those that do. It means to look at them from every angle, and then ask, are there other angles I haven’t considered. This is helpful in just about everything I do. What clarity of thought is not, is a Vulcan-like adherence to pure logic. It is not emotionless.
Nowhere has clarity of thought expressed itself more than in my writing. While writing fiction has always been a difficult, often tedious task for me, writing nonfiction rarely is. I began writing the same time I began coding. In high school and college I never had trouble with papers. That clarity muscle that coding helped develop seemed to do the job of organizing the writing for me. In my nonfiction writing, articles I’ve sold, and even here on the blog, I like to think that my style is clear and easy to follow. That clarity comes from the clarity of thought that coding nurtured.
(Often times this clarity comes after seeing a first draft. Case in point: the first draft of this post was 1,700 words and not as well organized. Upon reading it, I cut and restructured it, and hopefully, made it better and more clear than it was in its original form.)
Clarity of thought has been a good trait for problem-solving. It has also been honed enough to know when not to try to solve a problem. As Mike says in his post,
Rather than “learn to code” we should focus on “learn to solve problems”. Many of those problems will require tools. Some of those tools will be code.
For me, learning to code was the tool I used to learn to solve problems. It led to useful introspection and analysis (the commenting) and a gradual improvement in clarity of thought, both of which have been invaluable tools for problem-solving for me over the years, more than learning to code ever was.
P.S.: Seriously, go and check out Mike’s blog, The Waiter’s Pad. It is excellent.
Did you enjoy this post? If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!
In his recent column in WIRED, Paul Ford has a great metaphor for science, one that really resonates with me as a software developer. He writes,
After a while you realize that science itself is just an API to nature, a bunch of kludges and observations that work well enough to get the job done. The job being measuring reality and predicting what will come next.
The core of what I learned about science came from reading Isaac Asimov, and I always appreciated his apt metaphors that made things easier for me to understand. But I love the simple elegance of Ford’s description. It appeals to me both as a student of science and as a coder.
I’ve always enjoyed Paul Ford’s writings. His 2015 piece, “What Is Code” in Bloomberg is a must-read. I definitely encourage you to check out his column in WIRED.
Did you enjoy this post? If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!
Not long ago, I came across Ryan Holiday’s notecard system for remembering, organizing, and using everything he reads. It was instantly appealing to me, the way that reading about John Gadd’s journals changed the way I did my own journals back in 2017. You can read about Ryan’s methods at length, but the gist of it is that he puts everything onto 4×6 index cards which he then categorizes, files, and then uses for whatever he needs. As soon as I finished reading his post (which was originally written in 2014) I bought myself 300 4×6 index cards with the idea of testing out the method with my own reading notes. (A few examples that I used for this post are below.)
I enjoy reading, but I also read to learn. I mark up books, both paper and digital, and then I take those notes and capture them in Obsidian. After that… not much happens. It took a fair amount of time for me to write the scripts that I used to capture those notes and link them the way I wanted in Obsidian. I like being able to see the web of relationships that form, but the return hasn’t been worth the investment.
This seems to be a theme with me when it comes to digital systems. I find very cool tools, and then decide that they aren’t quite cool enough, that they need more. I’ll then spend a ton of time writing my own code to integrate, automate, and manipulate the tools to do something very specific for me–in this case, take my Kindle highlights and notes and move them into Obsidian. I spent years doing this with Evernote, only to find my use of Evernote scale back to basic document capture. I’ve probably spent more hours writing scripts to automate tasks around my writing than I have actually writing fiction. And I can’t even begin to quantify the amount of time I have spent investigating tools, switching to them for a period of time, only to find something else later.
A recent page from my “master” reading list notebook.
Thinking about this, it seems that paper systems are more effective for me than digital ones. There are a number of reasons for this, but they boil down to four things: simplicity, ease-of-use, effectiveness, and longevity
Simplicity
If I need to make a quick note, I simply pull out my Field Notes notebook and jot it down. I have yet to find an app that works faster or more reliably than that.
When I want to write in my journal, I pull it off the shelf and start writing. There is no need to log into a computer, or open a document, no need to worry about formatting or data syncing.
For me, the thing I want to do needs to be really simple, otherwise, I’ll eventually give up on it.
Ease of use
You can’t get much simpler than scribbling in a notebook or on an index card. There are no keyboard commands to remember, commands that often vary from one app to another. There is nothing to “save” or “open.” I don’t have to worry about syncing with cloud services, or whether a password has expired.
If the power is out, or I don’t have Internet access, my notebooks and note cards are still accessible and usable.
Effectiveness
These simple system work for me. I have little processes I’ve built up (how I number my journal entries for easy indexing) or how to Iabel post ideas in my Field Notes notebook so that I can easily identify them for later use.
But perhaps what makes these systems most effective is that I don’t get distracted writing code to try to improve them. Being on paper, they are already about as refined as they can get.
Longevity
I still have notebooks from college, and diaries from 25 years ago. I have school papers going back to kindergarten. Yet I have only a small number of digital files from college: a few papers, a few stories I wrote. Most notes I took on the computer back then are gone. I can’t begin to imagine how much digital stuff I’ve created that has been lost over the years, not by accident, but because I simply didn’t care enough to keep it. For me, if I can touch it, it seems to matter more than if I can’t.
There is always the question of how long digital media will last. We’ve only had it in the modern sense for about fifty years. But there are countless diaries and journals that have survived hundreds of years. Famous examples include John Adams1 and John Quincy Adams, Henry David Thoreau, Samuel Pepys, and of course, Leonardo Da Vinci. As Walter Isaacson wrote in his biography of Da Vinci:
His mind, I think, is best revealed in the more than 7,200 pages of his notes and scribbles that, miraculously, survive to this day. Paper turns out to be a superb information-storage technology, still readable after 500 years, which our town tweets likely won’t be.
But it is not just the paper of famous people that lasts. Currently, I am reading The British Are Coming by Rick Atkinson. In it, he describes the early battles of the Revolutionary War in great detail, often relying on the diaries of average citizens and militia on both sides of the fight. I’ve made it through the first three chapters as of this writing, and along the way, encountered the following citations:
…Lieutenant Frederick Mackenzie told his diary.
A physician visiting from Virginia told his diary…
…recorded in his diary
…Lieutenant Barker of the King’s Own told his diary.
…a parson told his diary
…a deacon in Brighton noted in his diary.
…Reverend Ezra Stiles told his diary…
Horace Walpole, ever astringent, told his diary…
There are about half a dozen more and that’s in just the first three chapters. You get the idea. There is a level of confidence in the longevity of paper systems that just doesn’t isn’t there with digital systems. Paper can burn, of course, but I treat paper with more care than I do digital documents.
One of the reasons I’ve put a lot of effort into digital systems in the past is to leverage their ability to do things faster than I can do them myself. Searching for something is a great example of this. Having my journals in digital form means that I could easily search for stuff in them. But when I have kept them in digital form, I’ve found that I simply don’t search them enough to make it worthwhile. Instead, I’ve developed a simple way of indexing my journals (on paper) so that if I don’t know immediately where to go, I can use the index as a guide.
Sample index page for August 2021. Number in parentheses represent journal entries on the topic
My reasons for building the scripts that take my reading notes and import them into Obsidian was to leverage Obsidian’s ability to link notes together. I thought I’d gain new insights from this. But this wasn’t how things turned out. The notes go in automatically, and I never look at them again. It has been different with the notecards. After finishing a book, I’ll go through it and make notecards from things I’ve highlighted in the book. I’ll organize them by topic or theme and them file them away. I do the same thing for anything I read: magazine articles, blog posts, etc. That means that some themes (say “Paper v. digital” — see the images above) contain cards from many different sources. That is much more useful to me. And there is something about the tactile use of paper, whether notebooks or cards, that impresses them into my memory better than looking at the same information on a screen.
More than any of that, however, is the time saved by not writing code to build all kinds of integrations that I won’t end up using. Instead, I can just read, or write, or jot downs notes.
This is not to say that paper is always better. I use Obsidian, for instance, for all of my work-related notes. I used to keep my notes in those marble notebooks you find for 50-cents at Target during back-to-school sales. But I do search work notes frequently, and often refer back to them. It makes much more sense to me to have those notes in digital form. I use Obsidian because underneath, it is just plain text and compatible with everything.
Calendars work better for me in digital form than they do on paper.
I prefer paper books to digital versions and paper magazines to electronic ones, but the fact that the latter take up no physical space is a big plus. So I read books on a Kindle in lieu of paper when it is convenient, and I read magazines mostly on my phone, except for a handful that I get in the mail each month, also because it is convenient.
But isn’t digital easier? Maybe, but maybe easy is not the point. In his post on his card system, Ryan Holiday writes:
I don’t want this to be easy. Writing them down by hand forces me to take my time and go over everything again (taking notes on a Kindle is too easy and that’s the problem). Also being able to physically arrange stuff is crucial for gettin gate structure of your book or project right. I can move cards from one category to another. As I shuffle through the cards, I dumb into stuff I had forgotten about.
This resonated with me. The ability to collect random bits and shuffle them and reshuffle them, that tactile feeling of manipulating the information, is important to me, and it is something that is much more difficult to do in digital systems that exist today. If you think of each “note” in Evernote as a card, how do you “shuffle” the notes into some useful order? How do you reshuffle them when needed? How do you easily “flip” to a random card? Ditto notes in Obsidian.
Paper systems are also cheap compared to their digital counterparts. Even my more expensive Moleskine Art Collection notebooks (about $28/each) cost less than half of an annual subscription to Evernote. And for the price of an iPhone or a MacBook, how many good notebooks, index cards, fountain pens, etc. could I buy that would far outlast the need for me to upgrade said phone or laptop?
A few days ago, I sat in my office with a 1996 diary in my lap, flipping through the pages and stopping now and then to read a passage. I wasn’t looking for anything in particular, just doing a bit of time travel. I could have done the same thing in a different way if that diary had been in digital form, but it wouldn’t have been the same. I wouldn’t have seen my own handwriting, and the cross-outs I’d made here and there. I wouldn’t have seen the color of the ink change from one day to another, or how I wrote in cursive one day and printed the next. I would have missed the blood stain on one page from a cut, or the corner I’d torn off a page to jot something down.
The lure of paper systems is about more than simplicity, ease of use, effectiveness, and longevity. The lure of paper systems, for me, is about history. The paper contains history. It yellows with age. It carries stains. It shows wear. It has a feel and smell and even a sound: pages riffling; that tap of an index card on your fingers; the whisper of a fountain pen across the page. Digital systems have none of these things, at least not to the extent that paper has. I can take a Field Notes notebook into the woods on a hike with me and not feel connected to the world. I can’t say the same when I have my phone and note-taking apps in my pocket.
Did you enjoy this post? If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!
Since I am on vacation and happened to find myself with an empty hour this afternoon, I managed to clean up my code enough to where I was willing to put my Obsidian daily notes automation script on GitHub. This is the script that I use to automate the creation of my daily notes in Obsidian.
I’m posting this software as-is. It works for me, and a number of folks have requested it and I’m happy to put it here to share it. But I have no time to support it. If I make improvements, I’ll try to post them, but there’s no guarantee there either. I realize that this may not work perfectly on non-Mac systems, but the whole point of posting the code is to let folks see it, fork it, and roll your own from it. Hopefully it works for you the first time. If not, the code’s there for you to mess with.
For those who choose to use it, keep in mind that I run my script on a Mac, and icalBuddy, which I use for pulling in my agenda, is designed for Apple’s calendar app. You may need to look for alternatives for other platforms.
I’m always eager for feedback and suggestions, but as I said, my schedule is such that I don’t have time to provide any kind of support for getting the script working for you.
While reading Walter Isaacson’s new book, The Code Breaker, I was particularly struck by some seemingly minor details. The book is a fascinating look into the modern process of scientific discovery, and there was some discussion of how a discovery written in a lab book and then signed by witnesses in order to document the dates of the discovery. When do scientists learn to do this?
I took AP biology, and AP physics in high school, as well as physics, chemistry and organic chemistry in college and no one every taught me how to properly use a lab book. Indeed, what was implied, at least at that level, was that what the teaching assistants and grad students who led the labs really wanted was nice, neat copy in our lab books with clear results that were easy to grade. I remember many of my fellow students had two lab books: the one they worked stuff out in, and the one they turned in after everything was cleaned up. I couldn’t spend the money on two lab books, so mine were messy.
It seems to me that the mechanics of a lab book–its true purpose and how it is used the real world–is a practical lesson that any burgeoning scientist should learn. But who teaches this? Are there upper division chemistry classes that focus on this? Certainly o-chem didn’t.
This got me thinking about other practical lessons that I would have benefited from, but was never formally taught. How to read a newspaper is one example that I’ve written about before. What about keeping a diary or journal? I don’t ever remember this being taught in school. I don’t ever remember a class in which the pros and cons of journals were discussed. I would have found these things very useful. Instead, I learned how to keep a journal by following (initially) the example Isaac Asimov described for himself in his autobiography.
Lab books are useful tools outside of the laboratory. For the first half of my career, I didn’t keep any kind of notes about the code I was writing. If I had to recreate something, therefore, it was often hard work. At some point, it occurred to me to keep notes as I worked. When I do something particularly complicated, I often list it out in my notes in high level steps, and then fill in the details as I work. I keep one simple idea in mind: a person new to the organization should be able to take my notes and reproduce my work. Technical debt is a big problem in I.T. People come and go and leave behind lots of undocumented code in their wake. You’d think lessons in keeping good notes would be part of the training process, but I’ve never seen it.
For that matter, how about something as simple as keeping a to-do list? I was never taught this in any of my classes.
There was one class I had–a 7th grade science class–in which our teacher spent quite a bit of time teaching us how to organize our work. We learned how to keep our science folder, and how to keep our notes and assignments organized in the folder. It was practical information that served me well through the rest of my pre-college schooling. Beyond that, most of the practical things I learned from books.
I can’t remember a teacher teaching how to take notes: how to identify the important points, and highlight them; what to leave in and what to exclude from the notes; tricks of shorthand to capture information more succinctly. All of this I had to figure out on my own. I read a book between my sophomore and junior years in college, and one chapter was all about note-taking. It changed the way I take notes and I use that method to this day.
I try to pass on some of these practical lessons to my kids. The Little Miss keeps a journal and I encourage that, and allow her to look at my journals in order to take ideas, but mainly so that she understands she can make it whatever she wants it to be. The Little Man could benefit from a daily to-do list, and I’ve tried on a couple of occasions to suggest it, even offering to help him get started by reviewing it together. He resists it, but he is at the age where he doesn’t think he needs it. (He does.)
It seems to me that in addition to classes in science and math and reading and English and history and art and physical education, there should be some practical classes on topics like these. Better yet, practical lessons could be merged into the existing classes.
In science, you could learn how to keep a lab book while you do your experiments. The lessons would be about the purpose–not to show you got the right answer, but to be able to reproduce your results, whatever they were.
In English, there could be a section on the literature of diaries and journals. There are plenty to choose from: John Adams, Samuel Pepys, Henry David Thoreau, Anne Frank just to name a few. Discussions could ensue about why to keep a journal, the practical value, and the literature can provide examples of what other people have done.
In home room, you might learn how to better organize your day, keep track of your work, and manage stress.
We need more practical lessons. I certainly would have benefited from them earlier than I did.
Author’s Note: This essay is the second in a series on how I learned to write code. You may want to check out Part 1 if you haven’t already done so.
By the time I got my VIC-20, the computer was already outdated, but I wasn’t complaining. There was only one problem: I didn’t know how to write code. At least, not beyond the few commands I’d learned the previous summer. Moreover, being in a new town, I didn’t know anyone who did know how to program a computer. I was on my own.
What I did, then, was get my hands on some computer magazines. In the 1980s, computer magazines were popular on the magazine shelves, even in the grocery stores. I ignore most stuff in the magazine and focused on the programming samples that they had. I have no memory of what any of these programs did, but I remember some of them spanned multiple pages. I would carefully type these programs into my VIC-20, line numbers and all, and then run them. Often, they’d generate an error as soon as I executed them. Usually, this was because of a typo I’d made. It might seem like an inconsequential thing, but I began to develop a lightning focus for these typos. Today, when I compile something, or run some code I’ve written, and it errors out, I can almost instantly see the problem (forgot a semi-colon at the end of a line; or, a bad indent on a Python script.)
When the programs worked, I was delighted. I also began to experiment. I would change lines of code to see how it changes the program, and slowly I began to deviate from what was on those pages to something different.
This was slow going, made slower by the fact that it took a long time to enter these programs, and the tape drive I had didn’t always save them reliably. If that happened, and I wanted to run the program again, I had to start from scratch. On the downside, this meant a lot of re-entry of code. On the upside, I gained a lot of experience and got more familiar with the code I was entering.
Still, it seemed a slow way to learn. I needed something faster.
Eventually, my VIC-20 was replaced with an Apple IIe, which in turn was replaced by an IBM PC. It was on these two computers that things began to speed up for me. For one thing, both computers used floppy disks instead of tape drives, which made saving the code I typed in much easier. For another thing, I discovered a more practical way to learn to code: by having a specific, concrete goal in mind.
It was on these computers that I first encountered text adventure games. There was the Zork series of game, of course, which had a multiword parser that was almost like typing English sentences. But what grabbed my attention more were the Scott Adams adventure games, which used a simpler 2-word parser. Until i discovered these adventure games, I didn’t even know what the word “parse” meant. It hadn’t come up in any of my English classes. And as it turns out, parsing, is a fundamental operation in both operating systems and computer languages. I didn’t know it at the time, but these adventure games were helping me learn some basics of computer science.
Scott Adams adventure games were like Choose-Your-Own-Adventures, but more elaborate. You were presented with brief descriptions and then presented with a prompt like:
You are standing in a dark room. There is a door on the north side of the room and a hallway to the east. A letter rest on a desk in front of you.
There was a prompt and you could type in two word commands, which would evoke different responses. For instance, you could type:
read letter
which might produce a response: “You don’t have a letter to read.” So you’d type:
get letter
and see: “You pick up the letter from the desk.” Then:
read letter
and see: “Do not open the door. It is booby-trapped.”
The games interested me as a unique form of story-telling. (I was just beginning to write my own stories around this time.) But I was intrigued and fascinated by the mechanics of the game, even more than the storytelling. I tried to imagine what the game looked like inside, like opening up a clock and peering into the elaborate gear-works within. Only, I knew this wasn’t just gears. This code, and I was becoming more familiar with code. It occurred to me that this could be my goal: to learn how to make my own adventure game by learning how these games worked inside.
Right off the bat there were three things about the game that interested me:
How the parser worked.
How the map for the game worked.
How the game knew when things changed within it.
Much later, I realized that through these three interests, I was learning three fundamental concepts about programming:
Parsing and interpreting data.
Storing data and relating data in useful ways.
Managing the “state” of a system.
In almost every piece of software I have created in my professional life, each of these three concepts place a significant role.
I had to really look around to figure this stuff out. There was no Internet at the time. There were bulletin boards, but I didn’t have a modem to connect to any of them, so I was mostly on my own. The computer magazines helped some. Do did the Granada Hills Public Library, where I could go and look at books on computer programming.
I remember I figured out how to write a 2-word parser entirely on my own, in much the way I imagine a person who can’t read music learns to “play by ear.” There was a lot of trial and error, but eventually, I managed to be able to split 2 word input into a “verb” and “noun”. I could compare those to lists and if the entries weren’t in the lists, I could return error messages.
Figuring out the map was much more difficult. Ultimately, I found a way to create a map using BASIC “data” statements. “Data” statements was how data that a program used internally was stored a part of a BASIC program. Imagine an adventure game with 4 rooms. There are 4 cardinal directions that are possible from each room. Suppose you have a map that looks as follows:
![[IMG_0662.jpeg]]
Sample adventure game map
The data statement for a map might look something like this:
DATA 1, 'You are standing in room with a door to the north and a hall to the east', 3, 2, 0, 0
DATA 2, 'You have entered a hallway. There is a room to the west.', 0, 0, 0, 1
DATA 3, 'You are in a cave. A door leads south and there is a sldie to the east.', 0, 4, 1, 0
DATA 4, 'You are stuck in a pit at the bottom of a slide.', 0, 0, 0, 0
The first number is the room number as shown on the map. The next item in the statement is a description of the room that is displayed when you enter it. The following four numbers represent the rooms you can get to for each of the cardinal directions, north, east, south, west. So from room number 1, you can get to room number 3 by going north, and room number 2 by going east.
Figuring out the “state” of the game was probably the most difficult. Consider the letter on the desk. If I tried to read the letter without picking it up first, the game would tell me that I didn’t have a letter. But if I picked up the letter, I could read it. The game had to know that I had picked it up before I could read it. Once I picked up the letter, the “state” of the game had changed. But a game could have dozens or hundreds of situations like that. Door that were closed or opened. Lights that were off or on. Puzzles in these text adventures were largely based on the state of the game.
Eventually, I figured this out, too, although it took a little help. For the first, and only time, I enrolled in a class on computer game programming that was being given at California State University Northridge. I think it was a Saturday class through their extension program. I do remember that I was the only “kid” in the class. That class was helpful in that it provided a useful structure for how to think of things like “state”. It also taught me how to create a game where the “monsters” in the game were taught to find you, regardless of your position in the game map. (Much later, I realized this was an algorithm, but I didn’t know it then.)
I kept at it. I created my own adventure games which, in their look and feel, seemed indistinguishable from Scott Adams adventure games. It was only in their story-telling ability that they flagged. I tried to make my games too complex, with maps with a hundred rooms instead of a few dozen. I was less interested in the storytelling and more interested in the mechanics. The more code I wrote the better I got, but it was almost always off-the-cuff. They were also always plain text games. I felt I needed to expand my wings a bit.
I began looking for practical applications for my programming, instead of just building something to see if I could. One thing I coveted was Microsoft Flight Simulator, mainly because I’d always wanted to be a pilot, and flight simulator was about as close as I could get as a teenager.
The opportunity came as part of a project in a computer programming class I took in either eighth or ninth grade. Don McLish was our computer teacher and our project was to built something using the concepts we had learned. I built a flight simulator. It was a fairly simple thing. I think there was a single instrument, and line that represented the “horizon” out the window. But it moved the way it should as the plane steered through the air. I remember it requiring programming using some trigonometry, which I was taking in math at the time. It impressed the teacher enough for him to sent a note home to my folks.
This encouraged me, and despite the occasional comments that I was “spending a lot of time” on the computer, I continued to practice writing code, more and more looking for practical applications. In high school, worked in a local pharmacy and was impressed by the software the pharmacist used to manage his customer database. I went home and tried to mock-up my own version of that software as a kind of personal “rolodex” program on the IBM PC that I had. It worked so well that I used that program for several years, including my first few years in college.
In college, things slowed down a bit as I was focused on classes and my interactions with computers was mostly for typing up notes and papers. But two things took place in college which would have a big impact on me and my programming.
The first was a computer class that I took with one of my roommates. I think we learned to program in Pascal, a teaching language. That class made me realize that most computer languages were more alike than they were different. It wasn’t a big deal for me to go from BASIC to Pascal once you knew the subtle differences. We also used NeXT workstations our labs for that class, and I was impressed by the NeXT, which was Unix-based underneath. It was a fleeting thing, because the class was just one quarter, but I didn’t forget the NeXT or that initial introduction to Unix.
The other thing that took place was a promotion I got. I’d been working in the dorm cafeterias for my entire time in college. I’d started in the dishroom (which I enjoyed) and worked my way up to a supervisor, and then, in my senior year, into the business office, where I ended up spending the year writing computer programs to automate the cafeteria budgeting process in Microsoft Excel. I was now being paid to write computer code, and as much as I enjoyed working in the dishroom, I enjoyed this work a lot more.
Recently, I passed a personal milestone. It is an arbitrary milestone, one for which I am the sole judge, but it is one that has been 37 years in the making. I have been a professional developer (coder) for about 27 years now. In that time, I’ve generally had no problem considering myself a professional. No impostor syndrome there. But there is one thing from which I have refrained referring to myself: an expert.
Until now, that is. Now, after 37 years of learning how to write code, I think I do it at a level which could be considered expert. Perhaps even by someone other than myself.
“Developer” sounds a little phony to me. I’ve read about people who are developers (land developers) and I’ve never really been clear on what that entails. I prefer referring to myself as a (professional–now expert) “coder.” It’s less formal, but despite its reputation, I’ve always felt there is something informal about coding. I’ve been wary of the term “expert.” It seems to me that it is overused to such an extent as to water down the meaning. I’ve seen all kinds of books about becoming an “expert” this or that in 30 days. Maybe I’m just bitter at being a slow-learner but it took me 37 years before I finally considered myself an “expert.”
One thing I don’t consider myself is a software engineer. An engineer has a specific meaning in my mind, and entails a certain kind of formal education in software development that I lack. I am not an engineer. I am immediately suspect when I see “software engineer” on a resume when I don’t see an engineering degree along with it. I’m much less suspect if I see “coder.”
I tend to be a slow-learner, perhaps because I dive in head-first and try everything at once. I’ve written about how it took me 14 years of writing and submitting stories, collecting more than a hundred rejection slips before selling my first story. It took me 11 years of teaching myself to write code, before I landed my first (and so far, only) professional gig. In that regard, it only took another quarter century or so before I felt I could call myself an expert.
So how does one learn to write code in 37 short years? For me, it began with hangman, and WarGames.
The first computer I ever saw was a Commodore VIC-20. I saw it in my 5th grade math class sometime in the late winter or early spring of 1983. There are exactly 3 things that I remember from that math class. First, our teacher was missing part of a finger. Second, one of our lessons was learning to read the stock pages in The Providence Journal. Third, was the Commodore VIC-20.
There was no math associated with our introduction to that computer. I remember it was wheeled into the classroom, connected to a television set. We spent the class using the VIC-20 to play Hangman. I didn’t see a line of code during that introduction, but I was intrigued by what I saw.
The summer of 1983 was my last on the east coast before I moved with my family to Los Angeles. It was the summer that WarGames with Matthew Broderick and Ally Sheedy made its debut. I saw the movie in New York with my cousins. I don’t recall the movie making much of an impression one way or another at the time. What I remember most about that day was going back to my cousin’s house after the movie, and being introduced to his Timex Sinclair 1000. It was the first computer I ever laid my own hands on.
My cousin turned on the computer and showed my how to write a simple program in BASIC. The program was:
10 PRINT "HELLO"
20 GOTO 10
The program doesn’t do much, but something in my brain clicked. It was like I understood the concept of programming in that instant. With a finite (even small) set of instructions, and some basic logic, you could make the computer do all kinds of things.
That evening, we made the computer break into a top secret installation. We didn’t have a modem or any kind of connection to the outside world. But using our memories of WarGames, and my quick absorption of BASIC, we wrote a program that made it seem like we were hacking into some secret computer system. I can’t remember what I program looked like, but it was probably something like this:
10 PRINT "WELCOME TO TOP SECRET INSTALLATION"
20 PRINT "Enter your password:"
30 INPUT x
40 IF x = "password" THEN GOTO 50 ELSE GOTO 60
50 PRINT "Welcome to Global Thermonuclear War"
60 PRINT "Wrong password"
Yeah, we didn’t have the logic quite right, but the idea that through some simple instructions you could make the computer to all kinds of things was a revelation for me.
At the end of that summer, we said goodbye to the east coast, and hello to Los Angeles. Any move is tough on an 11-year old, but moving across the country, away from all of your friends is particularly tough. But I had something cooking in my mind that I was looking forward to. I was going to figure out a way to get my own computer. I didn’t particularly like the keyboad on the Timex computer. What I had in mind was the VIC-20 I’d seen in my 5th grade math class. I thought about it so often that I’d dream about it. I remember a couple of occasions that I dreamed I’d gotten a VIC-20. I was so excited! Then I’d wake up, uncertain at first if it had been a dream, and then, crestfallen, that it had.
Until one day, I had one! My very own Commodore VIC-20. And it came with a tape drive! My real coding experience was about to begin…
I spent the entire day working on SQL stored procedures for importing data. Pretty routine work, but I did some innovative validation stuff, that should make it easier for a person to validate the data that gets imported into the database. I was in good flow and both the morning and the afternoon flew by.
I’m home now and setting my sights on getting my next assignment done for the writing workshop. Week three is on setting so I’m sitting the comfy chair in the family room, surrounded by dining cats, with my laptop and workshop book. Earlier today I had some insight into how the new version of the story will unfold and I think that will help with the writing of the next scene. But I’ve got some chapters to read first.
No mail when I checked a little while ago, but that may be because it hasn’t been delivered yet.
Nearly 130 pages through Vinge’s Rainbow’s End, and I’m finding myself both amused and entertained by it. It was tough not to use this hour or so before Kelly calls to just read more, rather than do workshop stuff.
Kelly and I planned for these to be a peaceful weekend–our first one in over a month, since moving to the new house. And for the most part, today was very peaceful. I went to bed early last night–by accident. I got in bed to read, and before I knew it, I just couldn’t focus on the page any longer. Kelly came to bed later. I managed to get 10-1/2 hours of sleep, which is remarkable for me.
We were still up before 8 AM. We lazed around for the first two hours, watching some TV. Kelly Tivo’d "Rock the Reception" on TLC, which was a lot of fun to watch, and really kind of addicting. We set the DVR to record it some more whenever it comes on. I worked on some wedding website stuff for a while. Finally, just after 10 AM, we headed out for breakfast. We walked a different route to Shirlington, through Park Fairfax. It’s a slightly longer walk but I like it much better. We headed to the Luna Grill for breakfast, where Kelly had eggs Florentine, and I had a bagel and lox. Then we walked back home.
We lazed around some more. Later in the afternoon, Kelly and I put together the new "kitty bathroom" that she ordered. I did a little reading and then we headed out to Pentagon City to do some shopping. We got some groceries for the dinner I was planning to prepare. We also got some bike stuff. We got a new tube for Kelly’s rear tire, and I got a new helmet and a mirror.
Back home and I started to prepare dinner. I planned on making Chicken Marsala with a side of Italian Pasta Salad. I prepared the pasta salad first, making the dressing, chopping up lots of veggies, and then refrigerating the whole thing. Then I started on the chicken. We used our new dishes and napkins and sat down to eat right around 7 PM. And guess what? For a wonder, it came out really good! The chicken wasn’t overcooked, the Marsala sauce was just right, and the pasta salad was great! This time, Icooked the chicken on a lower flame, but for a longer time than the cookbook said. I was pleasantly surprised by the whole thing!
After dinner, we booked the final excursion for our honeymoon cruise (this one, at Ocho Rios, Jamaica, takes us to some caverns and then some waterfalls), and then headed off to the gym. I got in a decent lower body workout.
Got the most recent issue of SCIENTIFIC AMERICAN in the mail today. Actually, it was delivered to a neighbor, but they kindly brought it by. It’s a special issue on privacy and looks like a good one. I’m somewhere around 220 pages through Old Man’s War, and expect to finish tonight or tomorrow.
Spoke briefly with stubiebrother today. Also with Mom and Dad.
Almost no one who reads this is a programmer of any kind, so this will mean very little to you. But I just have to say that I spent the last 2-1/2 hours trying to debug a type problem in a C# .NET application I am working on. I added a cool feature that allowed a table of dates to be edited inline from the browser, but when the date was submitted to the database, I kept getting an exception indicating that the string could not be converted to a datetime. I tried different approaches. I made little tweaks. I scoured the InterWeb. Nothing was working and yet I was confident that the value I was passing was a datetime value.
I was about to give up and go to lunch when a stray thought struck me. Maybe the value is a datetime, but maybe the parameter which I am setting using the value is not a datetime. I checked, and sure enough that was it. Someone, in the hours of frustration, I had swapped the order of two lines of code. That was all that was wrong and all of my frustration and fruitless attempts were for naught, if only I had recognized this change 2 hours ago.
There were some problems with the development server that I was using this morning. What made it worse is that the server is in Santa Monica and I can’t just walk up to it on smack it. I couldn’t even make a remote connection to it. Aside from other things, this server is our source control server for all of our source code and I was unable to check out some code I needed.
Fortunately, some folks were in the Santa Monica office this morning and were able to bounce the server and I am finally (after over an hour’s delay) able to get some productive work done.
RSS - Posts