Barbecue and Project Management

As I begin to write this article, it’s 8:30 on the Saturday morning of Memorial Day weekend, the de facto start of the summer season in the United States. In most parts of the country, and especially in the South where I live, that means it’s also barbecue season.

I take my barbecue seriously, so I awoke at 4:00 this morning to start smoking a pork butt for a party this evening. I’m also rather old-fashioned about preparing barbecue, so I use a barrel smoker with a firebox rather than an electric smoker or an automatic pellet feeder. Not only do I like the end product better, but I also enjoy the process of smoking with an actual fire.

Preparing barbecue this way isn’t easy, though. There’s a lot of craft involved. I have to select the right kind of wood, with the right amount of seasoning (not too green, not too dry). I have to keep the fire just low enough to keep the temperature in the smoker in a narrow range. I also have to keep the fire burning and not smoldering to impart the best flavor to the meat.

Going through this process got me thinking about a few parallels with project management, particularly in the field of software development.

The temperature trend is more important than the current temperature.

Keeping the fire in the right range isn’t just about the current temperature. It’s about knowing which way the temperature is headed. If it’s headed up, I need to prepare to open the vent to let out a little more heat in case it gets too high. If it’s headed down, I might need to add a bit more wood. That’s not the whole story, though. I need to see where the temperature might settle before I do anything drastic. If it’s above 300° F or below 200° F, it’s clearly in a bad place, but I still need to know where it’s heading before I get too excited.

Parallel: It’s difficult to jump into a project and know just how it stands until you get a sense of what kind of progress, or lack of progress, is being made. A metric may tell a story, but multiple metrics tell a more complete story.

Should I add wood, open the vent, or leave the fire alone?

Have a stack of wood chopped, split, and ready to add to the fire.

I started working on my stack of wood yesterday afternoon, and even this morning I’m chopping, splitting, inspecting, and sourcing more wood. I don’t want to get caught with a dying fire and no prepared wood to add to it.

Parallel: When a project is critically understaffed, that’s the wrong time to start recruiting, interviewing, hiring, and training. A well-tended talent pipeline is critical for handling staffing disruptions on a long-running project.

Add wood to the fire before you need it, not after.

If I add a perfectly seasoned, quarter-split piece of wild cherry log to a dying bed of coals, the temperature in the smoker is going to drop precipitously, and I’ll find myself furiously blowing on the embers to “inspire” the fire to light so it can cook the meat.

Parallel: Adding an qualified, experienced hire to a staff that is overworked (and, like an ember, “burned out”) will not yield as effective a result as adding the same hire to a staff that is fully engaged. The new hire can get up to speed on the project more quickly when the team can take the time to train the hire and share their unique team culture.

Add the right kind of wood, in the right amount.

Different kinds or cuts of meat call for different kinds of wood. Hickory will impart a strong flavor to a couple of racks of ribs smoked for an afternoon. A large pork butt or brisket may call for a little bit milder smoke flavor, since those have to be smoked for several hours. Poultry may call for an even milder smoke. Even with the right wood, too little may not keep the fire going, and too much may either smother it or overheat it.

Parallel: Staffing a project, at the start and especially when it’s in-progress, calls for the same kind of care. Most of us probably have seen a project with too many bodies thrown at it, or without the right amount or mix of talent at inception.

Messing with the fire makes the temperature go down before it goes up.

Whenever I lift the lid on the firebox to check on the fire, I lose about 20° F of temperature in the smoker. It’s better to watch the trend on the thermometer or peek inside the firebox vent to see if it’s burning properly. Even so, I do have to open the lid to stoke the fire or add fuel. I can’t get too worked up when the fire’s “productivity” drops immediately after I’ve taken action to improve it. I have to trust that I’ve made the right change and let it take effect.

Parallel: Whenever a project is in trouble, managers tend to institute process changes and add status meetings and reports to track the effects of the changes. It’s not uncommon for those new reports to show that productivity has actually worsened. This can happen if there is overhead in learning the new process, or if the staff has to be trained on a new technology, or if there are additional meetings that initially take away from time that could be spent doing actual work. If the right changes have been made, however, productivity should eventually increase. A little trust and patience may be required.


Scheduling Every Minute, Revisited

Note: I originally posted this article on LinkedIn.

 “Planning is bringing the future into the present so that you can do something about it now.” —  Alan Lakein

Late last year, I published an article entitled “How I Plan Every Minute of My Day to Stay Productive,” where I described my personal daily workflow of planning the tasks that I need to accomplish and then adjusting that plan as necessary throughout the day. I have a new job now, so I want to post an update on how well the approach is working in a new environment with new responsibilities, and how I’ve made a few tweaks to the process.

I’m now working in a vendor role embedded with the software-development team of a client company, and it’s easy to get pulled into many different directions. As with my previous position, I’m still working across time zones since my new employer is headquartered in the Pacific time zone and I’m three hours away in the Eastern time zone. There are also several more standing meetings and conference calls in this job, so finding large blocks of time for deep work is even more challenging.

Dealing With Email and Instant Messages

I still have a lot of email to read and respond to every morning, most of it having arrived late the previous evening from the west-coast team. As before, I schedule time to dig through it in the morning and respond to whatever’s urgent, but mostly I flag items for review or response and schedule time later in the day to deal with them. One thing that I’ve started doing is taking a little more time between tasks to deal with emails, like peeking at my inbox to see if there’s anything urgent to be dealt with before I dive into the next task. I did this because I’ve disabled email notifications, both on my laptop and my phone. That way, I don’t have a constant barrage of bells and popups drawing my attention away from what I’m working on, like sirens calling me to the shoals of low productivity.

My new company makes more extensive use of instant messaging, which brings its own challenges. I usually prefer IM over phone calls, but again, I don’t want to have notifications popping up all the time. I’ll check my messages between tasks and give a quick response before starting the next task. If I’m working on a task that requires concentration over a long stretch of time, I’ll set my IM status to “busy” or even “do not disturb” to discourage frivolous interruptions.

Scheduling Time for Recurring Tasks

Besides dealing with email, I now make a weekly plan to set aside time during each day to deal with other recurring tasks. These tasks are usually at the end of the day (in the case of code reviews) or just before daily meetings (updating status). Once all the recurring tasks and meetings are scheduled, I fill in the open spaces with either important daily tasks or ongoing tasks that need to be chipped away.

The image below shows what my calendar looks like for the coming week, which will be particularly busy since I have a deliverable due (I’ve blurred some sensitive details). The first task of the day is 15 minutes spent on planning. The gold tasks are recurring tasks that need to be dealt with every day. I start by working through my email backlog, and I finish with code reviews. The brown blocks are meetings or meeting-related tasks, gray blocks are personal items such as lunch or commuting, and green items are administrative tasks unrelated to the customer.

The orange blocks represent tasks related to the larger deliverable that is due by the end of the week. These are the items that I need to spend as much time on as possible, for as long a stretch of time as I can schedule. Some of the blocks are two hours or longer, which is a long time to sit at a laptop, so as I plan each day throughout the week I will probably break these down into one-hour chunks to give myself a chance to stand up, walk around, get a cup of fresh coffee, etc.

Multi-Desktop Approach

There is a risk to this approach. As I described in my first article, I will re-arrange tasks throughout the day as priorities change and new tasks appear. This can create a distraction of it’s own, with the temptation to switch to Outlook throughout the day and constantly fiddle with my schedule. To fight this, I create a new desktop in Windows 10 and keep my Outlook calendar window there. This way, I’m more likely to only change the schedule in between tasks.

Scheduling Serendipity

During weeks when there are not quite as many urgent tasks to be managed, I’ll schedule time for serendipity. This may sound like a contradiction, but finding innovative approaches to software development is a big part of my job and my career. A lot of these discoveries happen when reading articles linked from a few favorite web sites (lately, Hacker News has been a great source of these). If I allow myself to sneak a peek at these articles in between tasks, I run the risk of being pulled into a half-hour or more of link chasing. Instead, I’ll schedule time to peruse headlines or read articles that I’ve saved.

Serendipity may also derive from chance encounters with colleagues, so if you work in a field that tends to keep you chained to your desk (like software development), make a point of getting up and moving around periodically to connect with others around you. Schedule such time, if it helps. Besides, it’s good for you to get up from your desk and move.

Moving Toward Deep Work

My earlier article mentioned Cal Newport’s research into what he calls “deep work,” and I’ve been trying to move my schedule toward that model. Anything I can do to reserve large blocks of time throughout the day to get completely engrossed in my work helps with this goal.

The modern work environment, with its open floorplans and tendency toward meetings and conference calls of little value, seems almost designed for shallowness. Look for ways to adjust your schedule and your environment so that you can get completely engrossed in a task. You’ll get more done, and the work you produce will be of a higher quality.

Applying It To Your Schedule

Here are a few ideas that have helped me with this approach:

  1. Schedule at a finer resolution. For me, it’s fifteen-minute increments. Thirty minutes is too coarse for squeezing in everything I want to do. If I plan a thirty-minute block for a fifteen-minute task, I’ll be tempted to waste the remaining time or to expand the task to fill the reserved block.
  2. Use a calendar that works for you. I happen to like Outlook for a number of reasons, but you should use something that fits your style and your approach to your work. Maybe it’s a paper notebook, or a smart phone, or a different calendar application, or even a bare-bones text editor. As long as it’s something you can use easily that lets you make changes quickly, it’s good enough.
  3. Start on time – especially meetings! The biggest uncontrollable time sink I have every day is dealing with meetings that don’t start promptly. That topic is probably worth its own article, but starting tasks and meetings on time, and then finishing them on time or even earlier than scheduled, might net you an hour or more over the course of a day.
  4. Schedule flexibly, but not too flexibly. No schedule will remain perfect over the course of a day unless you’re able to work in isolation, and that’s a rare gig, indeed. Leave space in your schedule to deal with distractions and randomization, and allow yourself the freedom to adjust your schedule throughout the day. This is why I like to use Outlook, since I can drag and drop tasks around during the day with ease. This can be dangerous, however, if you let yourself get pulled into constantly tweaking your schedule. Be firm, and let your colleagues know when you have time scheduled for getting things done. Don’t be afraid to say, “No.”
  5. Review your schedule. Looking back over your schedule, especially if you carefully adjust it during the day to reflect what you actually did, is a great way to learn about your working style and adjust it to be more productive. Look for random items that crept in, and try to find ways to move those to a block of time where you can deal with them together so that you have more large blocks of time for concentrating on what you really need to do.

I’d love to hear from you about how you plan your day, and what tips and tricks have worked for you.


On Recruiting

I’ll have more to say about this later, but I want to get this quote out there now so that technical leads, engineering managers, engineering directors, and vice-presidents of software engineering can have it embroidered on a pillow, printed on a t-shirt, and taped to their bathroom mirrors:

The quality of your company’s software will never exceed the quality of your company’s software developers.
— Paul M. Parks

If you’re not recruiting the best developers you can possibly afford and training the ones you have, you’re losing to the companies that are.


Conway’s Game of Life in JavaScript

I realized yesterday that I had never implemented Conway’s Game of Life, which is something of a rite of passage for young computer-science students. As I opted for a more non-traditional path to the software profession, I somehow missed that fun, even though I’ve made a point of implementing other computer-sciency things like it.

Here are some links to interesting board layouts:

The basic page, which implements a glider.

A Gosper glider gun

A Gosper glider gun running at top speed, probably faster than your screen’s refresh rate.

A set of cells that devolves into a single spinner.

A pair of gliders which follow each other endlessly.

A large board with a long-running pattern


Updated Barcode Generator

I finally got around to making some updates to my Barcode Generator. Try it out and let me know if you have any problems.


How I Plan Every Minute of My Day to Stay Productive

Note: I also posted this article on LinkedIn.

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” — Dwight D. Eisenhower

Over the years, I have progressed from being a software developer who focuses on code all day, to a designer who designs and codes, to a technical lead who communicates a design and technical strategy to a team of developers, to a technical and project lead who leads developers in the implementation of a project while communicating with customers and other stakeholders. At each level the demands on my time have increased, while the expectations of improved productivity and reliable delivery have also increased.

I’ve played with various ways of planning and scheduling, but the method that has proven to be most effective so far is a variation of  Cal Newport’s tips for scheduling, particularly what he discusses in the article “Deep Habits: The Importance of Planning Every Minute of Your Work Day”. The idea is to lay out a plan for my day in my calendar, at the start of each day before I’ve jumped into any other activity. The plan isn’t rigid, but rather a guide for what I tasks need to accomplish and how I would like to get them done.

To show you how this works, I’ll walk you through a typical working day for me. While the tasks described are entirely fictional, they are still quite representative of what you would find in my real OneNote and Outlook files.

I usually start my working day just before 6:30 AM, after I’ve made breakfast for the family and I’ve wandered upstairs to my home office with a large mug of coffee. I’ll take a few moments to look over my OneNote file, where I keep meticulous notes on everything that happens on a daily basis: what meetings were held, what decisions were made, what questions are open, and what actions need to be taken. For my own actions, I use OneNote’s CTRL-1 keyboard shortcut to put a check box by each action so that I can easily see what needs to be done. Any actions that aren’t due on the current day end up at the top of my file, under the heading “The Future”, and as I create a new entry in the file for each new day, I’ll move the items I need to accomplish under that day’s heading.

For example, by the end of the previous day my general notes file in OneNote might look like the following:

As you can see, I’m in the middle of a particularly busy week where a lot of to-do items have piled up. Some are little more than annoying administrative tasks, while others require some deep work and concentration to complete. When I create an entry in OneNote for the new day, I’ll use the ALT-UpArrow and ALT-DownArrow keyboard shortcuts to move the most important to-do items to the current day, and then I’ll review notes from the last few days to see if any unchecked or unidentified actions were lurking in those entries. When I finish, the OneNote file might look like the following:

Now I’ll open my Outlook calendar and start blocking off time during the day for the various tasks I need to accomplish. Since I work on several concurrent projects, I put a project identification code on each task, and I even color-code the tasks by project so that I can see at a glance where my time is going. There will probably already be some entries for pre-scheduled meetings and conference calls, so I also need to be careful to plan my day around those fixed items.

Next, I block off time for the annoying tasks that just need to be cleared out. For me, mornings are the best time to do this because that’s the noisiest time of my day, and I can move these items around as needed. They usually don’t require a lot of concentration or other resources, so it’s no big loss to reschedule them or to be interrupted while doing them. Consequently, you’ll notice that most of these tasks are shown as free time in Outlook, in case someone needs to schedule me for a meeting during the times that I’ve blocked off to complete these tasks.

With that done, I start my day. The first half hour or so is usually reserved for dealing with email. Currently, my customers and project managers are in the UK, and my development teams are split between the Philippines and India, so I usually wake up to a bulging inbox in Outlook. I read and respond to what I can, and I flag the items that need to be dealt with later, perhaps creating a calendar entry for them.

One of the emails sitting in my inbox is from the QA lead, saying that she has some questions about the spec and how it relates to her test plan. I had already reserved some time later in the day to drop in and chat with her, so I expand that entry in the calendar to make time for what needs to be discussed.

Next, I have a conference call scheduled with the development team from 7:00 to 8:00. Then, I start to look over a customer requirements document, after which I plan to finish a code review that’s been assigned to me in Crucible.

Most of the way through the requirements document, however, I get a call from the programme manager in London asking if I can participate in an urgent discussion about some changes that a customer stakeholder requires in a PowerPoint slide deck that we sent last week. “No problem,” I say, and soon I see a meeting request appear in my calendar from 9:00 to 9:30. That’s when I had planned to knock out the code review, but that’s okay. I just drag the code review to another part of the day and do some quick shuffling of tasks, taking no more than a minute or two to do so. The review moves down, the time I plan to drop in on the QA lead moves, and some less urgent tasks get pushed to later in the day or maybe even to tomorrow. The large block of time I reserved for the development task, however, stays in the afternoon, since that’s when my distractions usually diminish and I can concentrate on difficult tasks.

The meeting with the customer ends with an urgent action to update the slide deck and get that back to the customer, so I do a little more shuffling and start that task right away. By the time that task is complete, I’ve finished the portion of my day that I usually spend at my home office, so I get cleaned up and drive to the real office. That’s the time I have blocked off from 10:30 to 11:30 as “Out of office” so that nobody tries to schedule me for that time.

Once in the office, I get the code review done, hop onto the intranet travel-booking web site to reserve a hotel for an upcoming trip, and then make a cup of tea and go find the QA lead. It’s a productive meeting, and some of the outputs dovetail nicely into my next scheduled task to update the dependency table for an upcoming project. Now I’ve cleared out most of my “busy” work, so I make another cup of tea and spend the rest of my afternoon getting lost in code.

My Outlook settings automatically generate a 5-minute reminder for upcoming tasks, so as I near the end of each scheduled task I’ll get a notification to wrap up what I’m doing, take a little break, and then dive into the next task. As I start each new task, I know that since I only have a set amount of time in which to complete it I have to stay focused and get the task done in the allotted time, so that I can get through all of what I want to get done for the day.

For ongoing tasks, where I’m just trying to allocate time to work on them rather than complete them, I fight the urge to work “just a little longer” when the reminder pops up, again so that I can keep knocking out those tasks that really do have to get done today. This is another reason I like to schedule ongoing tasks for the end of the day.

I have found that, generally, how productive I am in a given week is dependent on how closely I stick to this method of planning and recording my day. Planning, because it gives me a clear image of what I want to get done and how much time I have to work with. Recording, because I make sure that as I complete tasks I go back and expand or contract the actual time spent so that I can look back through previous days and get an idea of how much time to reserve for new tasks based on how long similar tasks have taken in the past. It’s also great for when I have to submit my time-tracking reports at the end of the week, since everything I’ve done is laid out very clearly, along with who gets the bill for that time.

I’d like to hear how you plan your days, and what little hacks make you more productive.


The Real Reason I Love AdBlock

First, let’s get this out of the way: Yes, there are ads on my web site. I have no problem with anyone blocking them. In fact, I have no problem with anyone doing what I’m going to discuss in the remainder of this article. I’d love to hear from you if you do, so that I can improve the design of my web site.

The ability to block ads is one of the best inventions in browser technology, since so many ads are incredibly obnoxious and intrusive these days. Lately, though, I find that most web sites seem to be designed to be obnoxious and intrusive, even without any ads. Compare the two screen shots below, for example. The first shows an article on Business Insider in Google Chrome.

Without AdBlock

As far as actual content goes, I see a headline… and that’s about it. There’s all this stuff going on everywhere. You’ll notice that there is only one ad visible, and it’s not really that annoying. In fact, I’d say it’s the least irritating intrusion into my reading experience. Go to the site yourself, and you’ll see what I mean. Imagine trying to read a newspaper like that.

Now, here’s the exact same article in the exact same browser window with AdBlock turned on, along with my own special set of tweaks to clean up the page.

With AdBlock

Such bliss! Now I can read the entire article with no annoyances. The text of the article fits into the same space that before, without AdBlock, showed only the headline. There’s also no popup that flies in from the side when I scroll down.

The Magic

If you use AdBlock and you’d like to make your reading experience on Business Insider as clean as this, try the following set of customized filters:

The way to set this up for yourself on other sites is to right-click on an obnoxious bit of the screen, select “AdBlock” from the pop-up menu, and select “Block this ad” from the sub-menu. From there you can tweak the filter until the annoyance is removed, and then reload the page. I’ve done this enough now that I can usually clean up a site in a couple of minutes, and if it’s a site that I read frequently I can make up for that lost time after a few visits.

Maybe this kind of design makes a lot of money for Business Insider and sites like it, but what it says to me is that the articles, and their contents, are the least important features of the site from the publisher’s point of view.

From my point of view, the only reason I’m even on the site is to read the content. If any site makes the content hard to read, and if it’s too difficult for me to clean up the site with AdBlock, then I’m just not going to visit that site anymore.


Master Foo and the Technical Recruiter

I found Eric Raymond’s Unix Koans of Master Foo several years ago and simply loved them. Like the Zen koans they are taken from, they are a succinct way to communicate concepts of software development, specifically as they relate to the Unix development subculture.

In the same spirit as Eric’s koans, I wrote a similar story involving the illustrious Master Foo and his interaction with a technical recruiter:

An ancient painting believed to be a likeness of Master Foo.

A technical recruiter, considering that the ways of software developers were strange and unusual, sought an audience with Master Foo to learn more about the Way of software. Master Foo met the recruiter in the HR offices of a large firm.

The recruiter said, “Many software craftsmen scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”

Master Foo stood, and began to pace across the recruiter’s office floor. The recruiter was puzzled. “What are you doing?”

“I am learning to walk,” replied Master Foo.

“But you’ve been walking most of your life!” the recruiter exclaimed.

“Yes, but this floor is new to me.”

Upon hearing this, the recruiter was enlightened.


Becoming a Developer Overnight, In Only Five Years

“Do you think hard work can make you talented?”

“Yes. I do.”

This post was inspired by an article on Cal Newport’s site entitled, “The Pre-Med and Ira Glass: Complicated Career Advice from Compelling People”. That article caused me to reflect on my path to my current career. By most people’s standards, I accidentally backed into my career as something of a prodigy, since by age 19 I was working as a full-time software developer in the Florida Governor’s office, but it took years of hard work to get there.

The Early Years

Through age 14 I had no idea what I wanted to be when I grew up (which was perfectly normal, of course). However, the Christmas after I turned 14 I got a TI-99/4A computer, and right away I dove into learning how to program it. I spent the next few years sitting in front of a computer with a guitar in my lap, programming for a while and playing guitar for a while, pausing only for annoying intrusions such as schoolwork or meals.

Back then there was no Internet, and BBSes hadn’t gotten very popular yet, so if you had a computer and wanted it to do anything interesting you usually had to program it yourself. I bought whatever books I could find and soaked up everything I could learn from them and from magazines such as COMPUTE!.

I guess I did have a little bit of natural talent with the computer. I could imagine what I wanted the computer to do and then turn that vision into a working program within weeks of getting my first computer. My first simple programs drew pictures of spaceships on the TV screen, and within a year or so I had written a text editor that could encrypt messages to my friends, a simple database application, and a typing game to improve my keyboarding skills.

The summer after I graduated from high school, at age 17, I was given an opportunity to work as an administrative assistant in a programming shop in the Florida Governor’s Office. Even though the job entailed answering phones, taking messages, and delivering memos, I got to be around real programmers writing real code and listen to them talk about their jobs. Even better, there was an entire room at the office full of binders containing all of the printed source code for the entire budgeting system (this was way before Subversion or git). I would spend my breaks thumbing through reams of COBOL and Natural 2 code trying to sort out how it worked. I felt like Mickey Mouse in “The Sorcerer’s Apprentice,” reading the wizard’s secret books of spells.

When I started as an admin, the office’s word processing system was still in transition from a mainframe text editor to WordPerfect, and I used this transition as an opportunity to help automate the office. I wrote a WordPerfect macro that could download an existing document from the mainframe system, translate the mainframe formatting codes to WordPerfect formatting codes, and save the file locally so that the document could be edited in WordPerfect from then on. It was a very simple macro, but it was a huge time-saver and it got a little bit of attention. Next, I wrote a program that would let me edit and print the address labels for a memorandum distribution list. That caught the eye of a programming manager at the office and eventually led to my first real programming job, at age 19, in the office where I had started as a lowly admin.

When I got my first computer and decided that programming was what I wanted to do for the rest of my life, I didn’t really have any idea how to translate that desire into reality. The officially sanctioned method of entering the profession was getting a bachelor’s degree in computer science and then applying for jobs afterward, but I ended up short-circuiting that process by soaking up all the knowledge I could find, creating programs for any and all ideas that I had, and by taking the first opportunity to just be near computers and software developers. Even though I wasn’t initially hired as a developer, the admin position still allowed me to polish my programming skills by writing applications that contributed to the efficient operation of the office. That eventually led to an entry-level development position where I continued to learn my craft and refine my skills.

The article I referenced earlier made me think of this path to my current profession, because the first thing I started doing was developing my skills. At first I didn’t have much guidance or direction, but it turned out that the most important skills for a software developer are visualizing the end result and then creating a plan to bring that vision to reality, and that’s what I worked on in the five years between getting my first computer and finally becoming a professional software developer.

If you have an idea what you want to be when you “grow up,” but you don’t know how to get started, my advice is to worry about building skills and gaining experience first. Once that’s underway, try to put yourself as close as possible to the people who are doing what you want to do and learn all you can from them. Eventually you’ll build your skills to the point where you can make a meaningful contribution to an organization by doing not just what you love, but what you’re demonstrably good at.


Fix it. Bolt it down. Forget it.

Setting up your environment to be the same all the time, everywhere, can make it easier to focus on the task at hand.

From the age of about 14 I’ve been sitting in front of a computer with a guitar in my lap. It’s been a cheap steel-string guitar, a cheap classical guitar, a cheap electric guitar, an expensive electric guitar, an expensive classical guitar, and several other variations in between, but it’s always there. My home office is full of guitars and amps and wires and microphones, but I keep my classical guitar right by my computer table where I can pick it up and noodle on it while I think.

The tag line of this site is “Pedagogy for the autodidactic programmer.” A goofy play on words, yes, but I firmly believe that if you’re self-taught you must be a much more demanding teacher and a much more dedicated student if you’re to be successful. I’m constantly looking for lessons to apply to the craft of software development, and I find many of them in the field of music, where I am also self-taught.

Continue reading ‘Fix it. Bolt it down. Forget it.’ »