Time Management: Is Your Schedule a Stack or a Queue?

I am always really excited when some abstract data type seems directly applicable to real life. It’s like a little nod from God saying, “yes, computer science and logic and math are real things! Happy learning!” Today we’re going to talk about stacks and queues.

These words both have special meanings in computer programming: A stack and a queue are both ordered collections; that is, they keep track of things, and let you handle these things in a specific order. A stack is “last in first out” or LIFO, and a queue is “first in first out” or FIFO. Think about a stack of plates: The last one you put down is the first one you’ll pick up. Think of a queue (people standing in line) at a store: the person who’s been in line longest gets helped first.

Let’s focus on one thing: the plates on the bottom of the stack. Let’s say you own 10 plates, and, on average, you run the dishwasher with 5 dirty plates in it. If you keep all the plates in one stack, that means the bottom five plates will never be used. 

I think the human attention span is a stack, but to get work done, we need a queue. Last week, I had a really unproductive day. I would start working, then I would get an email, then I would get some notification about a meeting, then I would get some question over Skype, then I would get an email. As each of these things came in, I would work on it immediately. Last in, first out. My attention span was a stack. What was I working on when I got that first email? Who knows! It got pushed to the bottom of the stack, and because I was running a stack, not a queue, it kept getting buried. My important work was like the bottom five plates in the cupboard. What a terrible afternoon!

Another way of thinking of this problem is that is has a lot of work in progress. I would start a task, then interrupt it, start another task, then interrupt it, start another task, and the stack would keep getting deeper! We learned from The Phoenix Project that work in progress kills productivity. All those things on the stack took five, ten, maybe thirty minutes of my time, and none of them were done. It’s like I went bankrupt by making a bunch of $10 loans and then never collecting anything.

In many ways, the queue is the opposite of a stack. In a queue, the oldest thing is the one that gets worked on first. This has a very important property: queues will empty. If you can handle tasks even slightly faster than they arise, you will eventually do all the tasks. And, there will only be one task in progress at a time: the task that has been in the queue the longest.

I really think that the different between stacks and queues is a key to understanding what a to do list or a schedule is really for: Human attention, and the activity you receive, is inherently a stack, with newer things crowding out older things, but productive work is inherently a queue, with older things getting finished before they’re too old. A schedule is a buffer that lets you transform a stack into a queue. 

Let’s go back to my terrible afternoon. What if I had just maintained a list of things to do when I was done coding? I get an email, a question over Skype, a survey about lunches, whatever, it goes on the queue. Then I keep coding. When the code I am working on is done, the queue advances, and I get the oldest email. Then I get the second oldest email, etc. The queue will empty, which means I will get things done. 

So, there are approximately six million apps and websites for tracking to do lists, and it doesn’t matter which you use. (Heck, when I was in college I just carried around a sheet of printer paper with everything I need to do on it. I use Trello now.) But really, the basic function of a to do list is to be a big enough buffer that you can turn the growing stack of input from daily life into a queue that you can empty.

Till next week, happy learning!


Book Review: The Phoenix Project

The Phoenix Project

I read this book very quickly; it’s definitely a fun, easy read, and an interesting novel in its own right. It was breath of fresh air compared to sort of meandering technical prose I’ve found elsewhere. 

A note to the non-technical audience: Almost all the characters in this novel are in IT. There are a lot of acronyms and technical terms. Don’t guess; look it up.

My main criticism is that at times, the book is a little bit “everything’s ok now”-y. In other words, there are a lot of episodes in the book that go approximately, “Everything is terrible!” Then IT people work late nights. Then someone discovers some DevOps magic sauce, and then everything is better. But that’s the worst I could say about it. And maybe, that’s a criticism of me; maybe the episodes where DevOps solves problems seem trite because I haven’t experienced this magic first hand, and I am simply incredulous that it could work so well.

One key benefit of reading the book was that I got to see the difference, close hand, between functional and dysfunctional teams, between good practices and bad practices. Maybe, if we’re critiquing the book as pure literature, the lessons of the book are too obvious, the morals of the stories too overt, but if we’re talking about it as a tool for learning, obvious lessons are good lessons, because you learn and remember them. People often mistake obscurity for brilliance; don’t let that mistake keep you from reading this book.

The biggest single takeaway lesson for me in this book was this: work in progress, that is, tasks that are started but not done, kill productivity. Here’s why: They already took some of your time and money, and they haven’t given you anything back yet. That’s bad. I think perhaps the lesson, from a developer, is to work on one thing at a time. Pick a feature, or a bug fix, or whatever, and knock it out of the park. Then do the next one.

Personally, I have sometimes been guilty of only working on what I felt like, or only working on the thing I most recently got an email about. This is bad, because some things remain work in progress forever. More on this soon, but I can foreshadow a future article: if you work on the newest thing, rather than always clearing out your work in progress, some tasks can stay in progress forever. 

I definitely recommend the book, especially if you’re in charge of other people, or if you (or your employees) resent or lack established procedures, and view keeping paperwork current as wasted time. It was also sort of motivating; after reading the book, I would go to work ready to charge in, and solve all the problems. If you work, or plan to work, in a technical field, or especially if you supervise technical employees, I really recommend The Pheonix Project.

Till next week, happy learning.


Old Teacher Trick: Don’t Guess; Look it Up

Before I was a computer programmer, I was a high school Latin teacher. I had a rule in my classroom: “Don’t guess; look it up.”

The rule came out of situations like this: We would be reading some piece of Latin. I’d be calling on students, and they’re answering questions, translating pieces of Latin, asking questions. And then we would get to a work no one knows, like nequiquam. And I would ask, “does anyone know what this means?” And the most amazing thing would happen. People would start to guess. 

Now, occasionally you can cobble together the real meaning of a word. Like “unobtrusive” is probably the opposite of “obtrusive.” But that’s the exception. As a rule, if there’s a fact that’s not in your brain, wishing won’t put it there, and guessing is even worse. When you guess, you take information that might be wrong, put it into your brain, and then instruct your brain to proceed as through it knew the information. Imagine if a database did that: you’re querying for some contact’s email address, and your database doesn’t know, so it picks are random email address? Or worse, it picks an email address that looks right, like stringing together parts of the guy’s name, at gmail dot com? That would be terrible. Your database would be lying to the rest of your app to save face, and you should replace it.

So why do we do this to ourselves? We’re reading, we see a word and we have only a limited idea of what it meas. So what do we do? We make something up and keep going. That’s like the database that makes up email addresses: it’s failing silently when it should complain. 

So, if you’re reading a technical document, or talking to coworkers, or listening to a podcast, and you hear a word you don’t know, look it up. Figure out what it means. Then keep going.

There are two reasons that looking things up, rather than guessing what they mean, is particularly important in computer programming.

First, if you’re talking to another developer, and you misuse a technical term, there is a very high probability that they will assume you are stupid. Think about this: the word “dumb” used to mean, “can’t speak,” and now it means, “not smart.” How do you think it changed meaning? It changed meaning because people are heavily biased against unclear or incorrect language. Maybe that’s not fair, but it is true. So if you come to a word you don’t know, look it up.

The second reason that looking things up is especially important in computer programming is because we have specialized meanings for normal words. What does it mean to say a website is “restful”? Does your code have a lot of classes? How about a lot of arguments? How about a lot of style? Now, there’s usually some connection between the specialized meaning and the normal meaning, but you can’t trust it entirely; make sure you know the difference. Don’t guess; look it up.

Looking things up is also very important when you start a new field, a new job, a new programming language, whatever. You must know what the words mean, or you cannot know what is going on. 

When I was studying to become a Latin teacher, we learned an interesting statistic: 95%. That’s the the absolute minimum percentage of words you must know before you can understand a written document. The minimum. That means, if you hear a 200 word talk, and there are 10 terms you don’t know, you will certainly misunderstand a lot of the meaning. To understand a passage without difficulty, you must know all the words.

So, make a rule for yourself. Whenever you encounter a term that you don’t know, look it up.  This will take 4 seconds at the time (thanks Google) and will save you both from making foolish mistakes and from having to look that word up again. Sounds like a good deal, no?

(By the way, the meanings of words are composed from the meanings of other words, and it makes a directed graph. Every time you find something in real life that can be represented as a directed graph, remind yourself how awesome computer programming is, and smile. And if you don’t know what a direct graph is, look it up.)

Till next week, happy learning!




Mindset Post: No Magic

“It just works, that’s why” should not be in your vocabulary. The phrase is about as useful to a software developer as “it’s magic, that’s why.” This explanation should not even satisfy curious children, let alone grownups.

But this explanation is frequently found in software because, frankly, more people know how to use software than know why it works. Let’s take Facebook, for example. I can post some pictures. Then people in Paris can like these pictures, and I can find out that people like these pictures. Magic!

False. Facebook is very clever, in that its customers can use it without knowing how it works, but it’s not magic. Somewhere, some team of developers wrote some code that serializes your picture, posts it to a server somewhere, which persists it somewhere, and notifies other servers, and … I am not going to speculate any further about Facebook’s architecture. Rather, I use this example to convey a mindset. Picture posting does not work because Facebook employs magical unicorns that teleport your pictures around. It works because real people wrote real code in real programming languages that you can actually learn. They put this code on server that are connected to the Internet and so can you. The difference between the developer at Facebook and you is that the developer at Facebook built a thing you didn’t build, not that he or she is a unicorn and you’re not.

This mindset is surprisingly exhilarating. Every time you see a thing that uses software, you should think, “how does that work?” I like to try to imagine the people that built that. Did they sketch a flowchart on a conference room whiteboard? Probably. Did they wonder about what the public API should look like, or how the thing would perform under load? Almost certainly. They probably have a favorite text editor.

So, now that you don’t believe in unicorns and your childhood is ruined forever, how will this new mindset help you? It will help you by turning real life into giant learning machine. Look at the software you work with. Does anything seem magical? If it does, props to its development team, and now go learn how it works. Is it open source? Go read some code. Does it have an SDK or good documentation? Go look that up. The less magic is hiding in your assumption about how things work, the faster you can learn.

(This post owes a lot to an old post by Eric Lippert about interviewing programmers. You should follow his blog. I have an article coming up on which blogs I found most helpful when teaching myself to program. Eric’s blog is at or near the top of that list.)

Till next week, happy learning!