Shady Acres

Effective Engagement

For my son’s tenth birthday, I took him to a major league baseball game. I haven’t sat through a complete baseball game in decades, so this was almost a first-time experience for me.

First off, lets get one thing out of the way: raw baseball is boring. Scientific studies have shown¹ that over 90% of baseball is comprised of something other than baseball; watching the scoreboard, doing the wave, watching the drunk guy yell at the players and passing helicopters, etc. Mostly, though, you’re waiting for things. Lots of waiting. If going to a baseball game involved nothing more than watching baseball, I can’t imagine anyone would actually watch it.

The thing is, the Major League Baseball people realize this. A good game will last three hours, with maybe five minutes of actual action over the entire game. What kind of fan wants to sit through that?

The answer, as it turns out, is an entertained fan. While watching the game, I noticed that every 30 seconds—sometimes even less than that—something happened. Maybe they played some chant (“bum bum bum, let’s go Bucs!”), or maybe they had some dude throw tee-shirts, or maybe they played some snippet of a song over the sound system, or maybe they had men dressed up as Pierogies run around the stadium in the most ludicrous race in the history of mankind. Strikingly, the vast majority of these involved the audience in some way. They put pictures of random fans up on the display, causing other fans to think, “hey, I’m a fan… if I do something now, maybe I can get up there!” They run raffles involving ticket stubs, or seating sections, or outrageous clothing. Whenever a ball is hit near the fans, the ball girl will toss it into the crowd. They show trivia questions on the display board. They have fan interviews, lots of fan interviews. All this stuff is meant to not only keep you entertained, but keep you wanting to stay in case the next “thing” may involve you. It’s subtle but very effective.

I went from the game to a committee meeting for a non-profit at which I’m a volunteer, and I brought this idea up there. We are trying to maintain the enthusiasm of our volunteers, and this experience drove home the point that maintaining engagement requires lots of planning, work, and effort. Running an activity every 30 seconds over a three-hour period takes some serious advance planning. Keeping volunteers involved in a project, or keeping customers interested in your product, or even keeping yourself motivated about your latest personal growth project, requires a lot of advance planning. When that initial effort is put in correctly, the result can really shine.

Interview Tip #1: Be Enthusiastic

For the vast majority of jobs, the skill itself is almost a fungible commodity. There are thousands of “Java developers” or “Quantitative Analysts” on the job market. Just because you took some classes or one worked in the field for a few years doesn’t make you special; I’ve seen fifteen other resumes in the past two weeks alone that were almost identical to yours.

In other words, I’m not hiring a skill; I’m hiring a person.

To that extent: always be enthusiastic during the job interview.

Whether you think you’re the best person for the job, or whether you think you have no chance whatsoever, enthusiasm is crucial. In my role on an interviewing team, we have turned down numerous people who possessed the requisite skills for the position but had a bad attitude, and more than once have passed over a higher-skilled candidate in favor of a candidate who showed excitement about what we do. Apathy is contagious; I don’t need that in my group.

If you’re an enthused candidate, you may have a chance. If you don’t seem to care, you can be certain you have no chance at all.

Listening as a skill

One of the best pieces of advice I have ever received came from a friend of mine, who makes his living as a clinical psychologist. We were talking about his practice, and he told me that his mentor had taught him to never take notes while meeting with a client. Rather, during his training, he perfected a method of listening to what the client was saying, remembering both what was said and what it implied, and then afterwards committing the important parts to paper. I told him I was very impressed that he was able to remember the entire discussion, from beginning to end, without writing anything down, as I can barely remember my own name without periodically checking my drivers license. His response was simple:

“During my training, I learned a new way to listen.”

It can be hard to consider listening to be a skill. It’s something that everybody does, all the time. You probably know some people you consider to be better “listeners” than others, and likely just attribute that to being “part of their personality”. However, everyone starts out with different degrees of artistic ability as well, and it’s well-recognized that, with training, almost anyone can become a fairly proficient artist. Listening is no different, save for the fact that there while there are many books on “learn to draw”, there are few books titled “learn to listen”.

Well, actually, there are, but they’re disguised under other titles such as “Be a Better Boss”, “Improve Your Marriage”, and “Learn to Debate”. In fact, there are countless books on a huge range of subjects that could generally classified as “improve your interactions with other people”, and almost all of these will dedicate some space to teaching how to listen. The problem is, like with so many other skills, people read the book and then forget to practice. This is a skill like any other, and it will only improve with practice.

Well, lets make it simple. Good things come in threes, but that’s one more than we need here.

Rule #1 of listening: Pay attention to what the other person is saying. This seems so obvious, and yet so many of us never do this in conversation. When we’re listening to someone else talking, once we begin to get an idea of what’s being said, our first instinct is to begin to formulate our reply. Don’t do this! If you’re doing that, you’re not listening to the rest of what’s being said. This is particularly relevant during a discussion or debate, when you’re just itching to demonstrate why your opinion is correct and their isn’t. Give them your full attention, and try to understand the nuances of what’s being put forth, and then try…

Rule #2 of listening: Don’t be afraid to take some time to think about what was just said. Silence during a conversation evokes the most interesting emotions. Many people find more than three seconds of silence very uncomfortable, and try to break the silence with empty talk. It’s a rare person who can completely comprehend a complex concept or subtle argument within that short timespan. Take your time; think about what was just said, ask for clarification, repeat the idea back to ensure you really got it. The speaker will likely be flattered that you’re taking time to actually think about what was said, and you’ll have a better understanding of whatever you’re discussing.

Personally, I’ve also been trying the “don’t take notes until after” technique as well, and after doing it for a few months I’m finding that I can typically remember most of what was discussed. Most, not all, but hey, it’s a start, and these skills take time to improve.

Keep the Good Ones

An interesting and insightful post made the front page of Hacker News recently, titled “Employees leave managers, not companies”. The post posits that commonly, employees leave a company not because they’re displeased with their workload, or with the company ethos, but because of a conflict with his or her manager. Anecdotally, I’ve seen this happen many times; people leave positions simply because their manager is unbearable to work with. In every case, even if the person simply transferred internally, these transfers pose significant setbacks. Occasionally, entire projects are scrapped because a few key people left, all due to a single bad manager.

However, the opposite is also true. Knowing that it’s so difficult to find good managers, people who are able to find—or are lucky enough to have been assigned to—truly outstanding managers tend to develop very strong working relationships. There are more than a few stories of people who have followed their bosses to new jobs, simply because they found it to be such a pleasure working for that person.

These types of managers are gold to companies.

It’s well known that employees whose personalities jive with the “corporate culture”—even if the “corporation” is just four or five other people—produce far more benefit to the company in both the short and the long term than those who don’t. Harvard Business Review recommends businesses “hire for attitude, train for skill”. Gallup’s Q¹² survey, which they market as “the 12 key dimensions that describe great workgroups”, includes an explicit item “I have a best friend at work” as a key factor in the effectiveness of a team. Blog posts innumerable describe the perils of hiring strictly for skills and not paying enough attention to personality matches.

Given that all of that holds true when dealing with co-workers and employees, it’s oh-so-much-more true for managers. Coworkers who don’t get along can simply ignore each other as much as possible and business will still go on as usual; each has their separate tasks, and while minimal communication isn’t great, they can each still work independently and Get Stuff Done. Managers, though, are completely dependent on open communication to do their job. If you dislike your manager, you’ll minimize communication, which makes the managers job nigh impossible. The converse is also true; a rapport between a manager and his “managees” fosters open communication, a pleasant working environment, and much more effective management.

Bottom line: if you’re a CEO, or even just a higher-level manager, you should go out of your way to ensure that managers like these stay around. It’s these people that make your employees want to come to work every day. Do your best to make these managers happy to be working with you.

Why LinkedIn’s “recommend” system is broken, and how to fix it

LinkedIn recently added a new feature, skill recommendations. The feature is a one-trick pony; it allows any (registered) user to vouch for the skills of their friends. Once they’ve done so, their picture will appear next to that skill on their friend’s LinkedIn page, allowing others to see that they have confirmed that their friend is, indeed, an expert in that skill.

Unfortunately, their implementation has a glaring problem. Fortunately, it’s not that difficult to fix.

To understand the problem and it’s solution, we need to appreciate what LinkedIn was trying to accomplish with this feature. As anyone who has tried to hire an employee knows, the problem is actually quite simple; resumes are untrustworthy. In an attempt to secure an interview, job seekers regularly “embellish” their experience and expertise, oftentimes well beyond the point of absurdity, and there’s no easy way to verify that anything on a resume is true. Sure, you can interview the person, but interviews are time-consuming and difficult to do right (by “right” I mean “in a way that actually reveals how much the candidate knows within a very short time period”). Besides, the whole point of the resume is to try to determine whether you want to interview the person. Within that framework, LinkedIn’s new feature is huge boon to employers and recruiters; it’s an attempt to fact-check the resume for you, saving you the worry that it’s all a huge pack of lies.

Against this backdrop, we can understand the problem with the current implementation of skill recommendations. Right now, when any user logs in, they are likely to be presented with a dialog box containing a random “friend”—let’s call him Bob—and a list of skills. Their task is to answer the question, “Does Bob know this stuff?” The rationale, I would guess, is that if the user doesn’t know the answer, they’d select “I don’t know”.

In practice, it seems that the average user doesn’t really know (or care) whether Bob is an expert in whatever skill. Their first thought seems to be much closer to, “hey, if I recommend Bob, maybe he’ll recommend me as a gesture of thanks.” Since this feature has been implemented, not only have I received recommendations from people who clearly don’t know whether I actually have the skill in question, I’ve also been recommended as an expert in a whole bunch of things I know nothing about.

The effect of these bogus recommendations is to remove all potential value from the recommendations. If I can’t trust that they’re correct, I’m back to where I started.

There are a few ways to solve this issue. The first solution is very simple; only show the “does this guy know these skills?” box when our skills are similar. Given that LinkedIn has access to each user’s information, including their work history, other people they worked with, their self-identified skills, and their education background, this shouldn’t be a terribly difficult problem. Yes, this will decrease the number of recommendations each person will receive, as it decreases the pot of available people to recommend any given user. However, by allowing bogus recommendations, LinkedIn decreases the value of skill recommendations in assessing a skill set, as we mentioned above.

A second solution would utilize the same skill-similarity index as above, but instead uses it to weight the recommendations received. If a user has similar skills, then their recommendation could be given high weight, and if their skills are highly dissimilar, then their skills would be given a lower weighting. The sum (or whatever operator is deemed most appropriate) of all recommendations could then be used to determine how much weight this recommendation carries. Currently, LinkedIn simply sums the number of recommendations and displays it as a number next to a given skill. By applying this suggestion, LinkedIn could make this metric more sophisticated, and therefore more useful.

On the Breadth of the Human Psyche

Recently, Starbucks ran a campaign. For a mere $450, you could buy a $400 “limited edition” metal gift card. Now, obviously, Everyone heard about the campaign, and then Everyone immediately said, “wow, that’s stupid. Who the heck would pay Starbucks extra money just to get a gift card that says ‘limited edition’ on it?”, because Everyone is smart. Everybody smartly kept their money in their wallets, the campaign ended in failure, and the ad advertising manager was subjected to public ridicule for even suggesting such a stupid idea.

Ha! Just kidding. The campaign quickly sold out, of course. However, the fun didn’t end there. These cards soon showed up on ebay (eBay?) and garnered bids upwards of $1,000. More on this later.

This fascinates me, for the single reason that—to me—the success of this campaign is absolutely mind-boggling. Yes, people collect things all the time; cabbage patch kids, beanie babies, whatever the latest craze is. However, this is pure, unadulterated, “please give me your money” Capitalism. I would have thought that people wouldn’t be interested in being part of an exclusive club just because that club exists. (Thinking about it some more, I realize that this is the fundamental business model of the entire fashion industry, and that American Express is built on a very similar concept. Ah well, everything’s obvious once you’ve seen it.)

However, what hit me most wasn’t the fact that I clearly have no future in advertising. What struck me was that my point of view—that such an advertising campaign is a completely idiotic idea—is clearly, completely, and incontrovertibly wrong. Not only does Everyone not think it’s stupid, a not-insignificant part of Everyone think it’s an excellent idea, to the extent that they went out and bought one. (Some enterprising folks were so forward-looking that they realized that others would appreciate this idea, and they bought some simply to resell them.) At this point, I wouldn’t be surprised if it turns out that some of my friends, who I would have sworn up and down would think this idea was ridiculous, were among those who bought one of these cards. When I first heard of the idea, I was dumbfounded with the combined audacity and cluelessness of Starbucks. While I’m still kind of disturbed by the audacity of Starbucks, now I’m mainly dumbfounded at the cluelessness of… me.

I’ve been thinking about entrepreneurship a lot lately, and this really drove home the point that I have no clue what people want. This really drives home the concept of “start a business by solving a problem you face yourself”. It’s hard to know what other people want, and it’s really hard to not only solve the need but to solve it well. Lesson learned: don’t laugh at anything, there are business opportunities in places you’ve never even knew existed.

Doctrine: the unwritten “Data-first” tutorial

The following are my notes to myself on how to take a “database first” approach to creating a php Doctrine application. There are two parts: first, a simple outline describing what you’ll be doing and why, and then a step-by-step of how to do it along with explanations.

What problem is Doctrine solving for me?

Doctrine is an ORM (object-relational mapper) tool for PHP. What this means in practice is that, after you set up Doctrine, your PHP application will be able to interact with the database as it would any other set of PHP objects. There is much discussion on whether this is good or bad, or even necessary at all; read and consider for yourself. Taking the view for the nonce that an ORM is worth implementing, the instructions below will help walk you through setting up Doctrine, following these general steps:

1. Install necessary software
2. Set up your environment. Doctrine uses a command line tool (Doctrine), which requires a little bit of legwork to get working.
3. Set up & populate your database (outside of doctrine; i.e., open a MySQL shell or phpMyAdmin or whatever and create something).
4. Inform Doctrine of your schema using (mostly auto-generated) xml files.
5. Create Entities and an Entity Manger. Broadly speaking, an “Entity” is a representation of a database table as a php object, and the Entity Manager is your interface to these objects.
6. Verify that everything works.
7. Have a beer.

Warning: I found the Doctrine tutorial to be pretty horrible for beginners. In fact, I found the majority of the documentation to be pretty horrible for beginners. You’ll likely get frustrated at some point. Stick with it, read questions & answers on StackOverflow, talk to the (very helpful) people on the IRC channel; it’s not nearly as complex as the docs would have it seem, and the result is pretty nifty.

Database-first Doctrine setup, step-by-step

1. Install Doctrine via Composer. This will save you a ton of time in the long run in numerous ways. It’s almost stupidly simple: install Composer, create a file entitled composer.json containing the following single line:

   {"require": {"doctrine/orm": "2.3.0" }}
   

   (This instructs Composer to install the 2.3.0 version of the Doctrine-ORM package. If you’re using a different version, change it, and here’s hoping that everything else below still applies to that version.) Now type the following into your terminal:

   $ composer install
   

   Note that once installed, the Doctrine command line tool is located at vendor/bin/doctrine.

2. Set up a bootstrap.php file (mostly) as described in the Doctrine tutorial, as below:

   <?php
   
   // Load files for Doctrine to run... thank you, Composer,
   //  for making things simple
   require_once "vendor/autoload.php";
   
   // Load EntityManager
   use Doctrine\ORM\Tools\Setup;
   use Doctrine\ORM\EntityManager;
   
   // Set Entity Manager parameters
   $paths = array("entities");
   $isDevMode = false;
   $dbParams = array(
     'driver'   => 'pdo_mysql',
     'user'     => 'root',
     'password' => 'pwd',
     'dbname'   => 'dbname',
   );
   
   // Set up an Entity Manager
   // ACHTUNG: The following line is different from the
   //          tutorial!
   $config = Setup::createXMLMetadataConfiguration($paths, $isDevMode);
   $em     = EntityManager::create($dbParams, $config);
   

   Read the comments above to see what’s happening at each stage.¹ You should set the database user, password, and database name as appropriate. Note also that this assumes your entities will be placed in a folder called “entities”; if not, change the $path variable as appropriate. Note that the entity manager is assigned to a variable named $em; you’ll use this variable for practically all database interaction.

   Follow this up by creating a cli-config.php file, which allows you to use the extremely helpful doctrine command line tool:

   < ?php
   
   require_once "bootstrap.php";
   
   $helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
       'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
   ));
   

3. At this step, Doctrine is set up for use. It knows that you have a database server and how to log in, but nothing else. At this point, you should create the actual MySQL database as necessary using whatever tools you like. If you already have a database you want to connect to Doctrine then just move right along and…

4. Execute the following from the command line to create a rough draft of the mapping of the database²:

   $ doctrine orm:convert-mapping xml ./path/to/entities/location \
     --from-database --force
   $ doctrine orm:generate-entities ./path/to/entities/location
   

   The first command will create a set of xml files at ./path/to/entities/location which describe the database schema in a language that Doctrine understands. The second command will create a set of php classes (one class per file) describing the tables. You will need to require_once each of these files in your bootstrap.php file:

   <?php
   
   // Load files for Doctrine to run... thank you, Composer,
   //  for making things simple
   require_once "vendor/autoload.php";
   
   ... (all the stuff from step 2 above)
   
   // Load files for our application
   require_once("path/to/entities/location/Table1.php");
   require_once("path/to/entities/location/Table2.php");
   ... etc.
   

   Most likely, these files are pretty close to the truth, but not entirely accurate, because Doctrine’s built-in tool isn’t smart enough to recognize every type of join and dependency. In the next few steps we’ll see what’s missing and iteratively correct the generated XML to include the missing parts of the schema.

5. Check if the schema is good by running the following:

   $ doctrine orm:validate-schema
   

6. As stated before, it almost certainly won’t be, so iteratively fix the generated xml (or yaml, whatever) schema by running

   $ doctrine orm:schema-tool:update --dump-sql
   

   continually and addressing each of the ALTER statements. Each ALTER statement represents something in the schema that doesn’t match the database. You’ll need to spend a lot of time in the Doctrine XML documentation (or YAML documentation, as the case may be) to get this right. You’ll know when you’re finished because there will be no more output from orm:schema-update and orm:validate-schema will report a passing database.

7. Generate/write getters and setters for each element of each table in the database. The tutorial does a good job explaining this part; see the “A first prototype” section. Briefly,

   • All columns should be represented as protected or private variables.
   • All getters are return $this->(varname); (i.e., for a var named $id you’ll have return $this->id;).
   • Setters are mostly just function getVarname(varname) {$this->(varname) = (varname);}. For more complex functions involving foreign keys, you may have to call functions from the dependent entities.
   • There’s a bunch of stuff about “owning side” and “inverse side”; it’s way the hell complicated in the documentation. Read the tutorial for full effect, but briefly, if there’s a bidirectional relationship between two tables, Doctrine wants you to define the one that will be changed “first”, and the other one will be updated as a function of that change.³

   Supposedly the orm:generate-entities function does this for you. Let me know if you get it to work.

8. At some point, you should see this:

   $ vendor/bin/doctrine orm:validate-schema
   [Mapping]  OK - The mapping files are correct.
   [Database] OK - The database schema is in sync with the mapping files.
   

   Beer time.

I haven’t discussed how to actually interact with the database at all, just how to set it up. The aforementioned tutorial has a discussion on how to actually write queries; check that out for some direction.

“Call put butterfly”: how to handle the on-site interview

The secret sauce of the expert communicator is understanding the intent of the other side. Admittedly, this can be a pretty tough task. Firstly, if you’re participating in a conversation, you probably want to get something out of it for yourself. Understanding the intent of the second person both requires insight into the mindset of the person with whom you’re speaking, as well as requiring you to keep two things in mind throughout the discussion, which can be pretty tough. Additionally, if oftentimes happens that what you intend to get out of the conversation is different from what the second person intends on gaining. The good communicator understands what both sides are hoping to gain, knows how to balance the discussion to ensure both sides benefit, while simultaneously actually carrying on the conversation all the while.

On the other hand, there are some common situations where understanding each other’s goals are simple because the situation is so common. One of these settings is the classic job interview.

We’ve recently had some very… interesting candidates come through (and back out of) our doors, and some of their mistakes are instructive enough to make them worth sharing with others. The following is an overview of the collective discussion of our group after finishing the interviews, and comprises some basic tips that apply to almost all interviews, regardless of setting. No matter what industry you may be in or what position you’re hoping to fill, these should be applicable to you.

1. Be concise. When you’re asked a question, think for a little bit, and then answer the stated question. Don’t answer another question which you think is related; I know what I asked you, and I know if you’re being evasive. Don’t talk on and on and on and on and on and on and on trying to demonstrate your encyclopedic knowledge; instead of being impressed, I’m more likely to wonder if you have difficulties communicating. I have yet to hear an interview question where the answer requires more than three minutes of continuous speaking time. If we end up having a conversation, that’s probably good, but if you’re talking for minutes at a time, something’s probably going wrong. Give an answer and move on. If I think you didn’t talk enough, I’ll tell you.

2. Be thorough. “But wait!” you say, “You just said to be concise! Aren’t brevity and comprehensiveness mutually exclusive?” No, no, NO! If I asked you a question, I want to hear your answer. Sure, you shouldn’t ramble, but you definitely should answer the question fully. Remember that most interviewers are also testing communication skills. “His answer was short, sweet, and too the point.” is a great compliment.

   By way of example, we had an interviewee who, when asked to describe options trading, responded with the following three words: “Call put butterfly.” That was it. She didn’t get hired. As I described earlier, you should focus here on what the other party wants. In an interview setting, the other party wants to see that you have a mastery of the topic being discussed. Demonstrate that mastery!

3. Be honest. If you state something on your resume, you better be capable of carrying on an in-depth discussion of that topic with just a few moments notice. If you state that you’re familiar with a technique, or you’re an expert in a particular field, you should be able to discuss that topic at length in fairly extensive depth. “Expert” is a pretty strong word, and if you claim to be an expert, then you should be able to answer all but the most esoteric and abstruse questions. When in doubt, don’t list it on your resume. No one really cares what your resume says anyway; listing dozens upon dozens of topics you have expert knowledge of is just asking for trouble.

4. Lastly, understand that we’re on your side. We want to hire someone—that’s why we posted the position. You looked interesting enough for us to take time out of doing whatever it is we do to talk to you. The sooner we find someone, the sooner we get back to doing actual work. We’d love for you to be the person we hire. Do your best during the interview—be personable, be genuinely excited, show interest in what the interviewer has to say—and convince us that you’re the best person for the job; we’d be thrilled to have you on board.

The $600 Mac Laptop

I’ve recently been attempting to use my iPad as a laptop alternative at work, and I quickly learned that typing on the iPad on-screen keyboard is a very “meh” experience. While the keyboard is appropriately sized for typing using proper form (asdfjkl;), the lack of punctuation is a deal-breaker. Even worse, the substitution of some punctuation keys with other keys (I’m looking at you, Mr. Return-and-not-Quotation key), combined with the missing numbers and symbols, topped off by the lack of a Command key for all my muscle-memory ingrained keyboard shortcuts, made typing on the iPad simply too error-prone and cumbersome for most real-life applications.

Then I found this:

The Logitech Ultrathin Keyboard Cover. It’s an iPad cover which is also a full keyboard, with a couple function keys added for iPad-specific actions (show/hide keyboard, go to home screen, etc.). While that’s how they market it, I believe that focus misses the boat completely. This device transforms the iPad from a nifty device into a full-fledged, $600 ($499 iPad + $99 case) Mac laptop. With this keyboard, I can do everything I want, and I can do it quickly:

• Take notes in meetings
• Quickly type out URLs
• Compose emails containing more than a single line of text
• Write blog posts, such as the one you’re reading right now
• Work comfortably in Terminal emulator/remote login iPad apps (e.g., zaTelnet)
• Code!

Not to mention that, since I’m working with an iPad, I get all the benefits of an iPad as well:

• Immediate wake from sleep
• Significantly longer battery life than a laptop
• Much lighter/more portable
• HUGE app market

One of the benefits of the setup of the device is that the screen is right next to the keyboard, which makes switching between the keyboard and touch-based UI very natural. I’ve become very used to the “type-swipe-type-touch-type” workflow.

I took notes on a laptop as a student, and I can now only dream of now much nicer this would have been relative to carrying around a 15-inch laptop. Obviously, for applications that exist solely on the Mac, this would only be a partial solution. However, anyone whose interaction with a computer is mostly typing and casual gaming—a fairly large audience—this setup makes for a very attractive alternative to buying a traditional laptop computer.

It’s worth noting that these I bought this particular keyboard case because of it’s excellent reviews. I imagine that many of these benefits would hold true for most keyboard case. I strongly recommend the Logitech keyboard shown above, but there may be others that would offer the same benefits; do your homework.

Time Debt

“How can I best manage my time?” Almost everyone asks this question at some point in their life. Most of the time, this comes up when when there are more tasks to do than time to do them.

I recently learned a new time visualization technique intended to help solve this problem, a concept called “time debt”. The concept can be summarized in a single sentence—a Time Debt is the time required to complete something which you began but never completed. Every task requires a certain amount of time to complete, and if all the necessary time was not fully invested in the project, it will either have to be invested at a later date or the project simply won’t be completed.

This conceptualization is a powerful one, because it forces us to consider our time as form of currency. Five dollars can buy some pizza and fries; five minutes can buy a few emails and a half-thought-out tweet. Money can be saved in the bank to be used for a later purchase; time can be banked by planning ahead as to how you plan on spending your next chunk of time. Just as large sums of banked money can often end up being eaten into by smaller purchases, setting aside large swaths of time (e.g., weeks, months) often leads to some of that time being eaten up by unexpected time requirements. Conversely, just as it’s mentally easier to justify spending small amounts of money, it’s easier to mentally justify something that takes “just a few minutes”. We usually try to avoid spending money we don’t have, because it causes us to tap into future income to pay for previous debt; overcommitting your time simply means that future time will be spent on tasks that you had planned on having completed. Most appropriately, it can be fiendishly difficult for some people to control their spending, and (as many can attest) it can be just as difficult to control the usage of your time.

Note that I haven’t discussed how to budget (pun intended) your time. There are a frankly ridiculous number of techniques out there meant to help gain control of your day. I use a modified version of Getting Things Done, as well as the Pomodoro technique for what it’s worth; try a lot of things and see what works for you. However, I hope this concept makes it easier for you to visualize how you spend your time.