lifehacks « blog.elevenseconds

Archive for the ‘lifehacks’ Category

Think of your Plan B

Thursday, May 27th, 2010

When planning things such as a trip, there are two kinds of people: those who only think in terms of happy paths, and those that take into account the chance of things going wrong. I am learning to be in the latter group.

Now, of the latter group, there are two kinds of people: those who simply add buffer time, and those who have contingencies in case their Plan A doesn’t work out. While having some buffer is often a fine way to plan for things going wrong (for example, traffic on the way to the airport), it’s often ineffective. Be creative and think of your Plan B instead of defaulting to just adding more time to your plan.

Posted in for reflection, lifehacks, principles, things everyone should do | No Comments »

How to take off that Self-destructing Wristband

Tuesday, May 25th, 2010

A small hack I figured out at a concert where I got one such wristband. Of course, as with any hack, you should not use this technique to lie or enable others to lie.

The wristband is actually a pretty clever thing. It’s adhesive, but once you wrap it around your wrist, taking it off without pretty much destroying it is very difficult, mostly because of a pattern cut out at one end that prevents you from separating the adhesive:

The 'V'-shaped cut out pattern that makes it very difficult to take the wristband off

The cut out pattern that makes it very difficult to take the wristband off

Suppose you have the wristband on your right wrist. The cut out pattern (seen magnified above) should be visible on top. This is the end that has the glue so the other end should have a few inches that are not glued to anything and kind of tucked in between your wrist and the band.

Trying to pull the wristband by pulling on the end of the band with the cut out patter separates the cut out pieces of paper which only bonds the ends together stronger. You end up maiming the poor piece of paper; there’s no way you can preserve the wristband.

Instead, press the part of the wristband just where the pattern ends (where the “V” is wide and not pointed) hard to the skin with your left thumb while at the same time slowly pulling on the free end with your teeth (or get your friend to help you), pressing it hard to the rest of the wristband (not your skin). Slowly unroll the end, moving your thumb down so it’s always where the adhesive is beginning to be released. As you do this, the pattern will stay intact but it will start sticking to your skin. It’s important to do this slowly and to apply a lot of pressure, especially with your thumb.

Once you separate the wrist band, pull it slowly away from your skin, starting with the same end of the pattern (the wide end of the “V”). Apply pressure so as not to separate the cut out pieces.

The diagram below should clarify the above.

How to take off the wristband

Posted in clever, discovery, lifehacks | No Comments »

My own alarm

Thursday, January 7th, 2010

I wanted to wake up to NPR. There’s a good alarm application for the Mac called Alarm Clock which allowed me to play an arbitrary iTunes playlist on schedule (with bells and whistles such as gradually increasing the volume), but the free version couldn’t deal with playing audio streams (such as, in my case, wnyc.org).

No problem — I used cron as well as OS X’s built-in wake-on-schedule functionality.

First, in System Preferences > Energy Saver, I set a schedule to wake up the computer on weekdays at 6am. Then I edited the crontab: in Terminal I typed crontab -e and typed in the editor

1 6 * * 1-5 osascript /Users/strozek/wnyc.applescript

The above tells OS X to run the command osascript at 6:01am Monday through Friday. The script I pass to osascript is the following script:

set volume 2
tell application “Safari”
activate
open location “http://www.wnyc.org/flashplayer/player.html#/playStream/fm939″
end tell
delay 20
set volume 2
delay 20
set volume 2.75
delay 20
set volume 3.25
delay 20
set volume 3.75
delay 20
set volume 4.25
delay 20
set volume 5

And voilà! I just need to remember to keep the computer plugged in at night and not close the lid.

Posted in code, lifehacks, technology | No Comments »

The evolution of the todo list

Monday, December 7th, 2009

Being somewhat OCD, I keep the concept of a todo list close to my heart. I’ve gone through several dozen iterations of an excellent todo list and what I have arrived at works very well for me; I want to share some of the design decisions I’ve made in the past, since I’m sure that if you’re just as passionate about keeping track of things to do, you probably came across the same problems as I did.

I wrote my first todo list when I was in fourth grade (I was about 10 years old). I found the concept really useful in staying organized and keeping on top of tasks. I think the perfectionist in me hated forgetting things (most of us have a dislike of forgetting things–this is related to our irrational preference for the preservation of options) so I added a safety net for my memory early on in my life (also, as a youngster, I would tend to forget things really easily).

The todo list started as a collection of subjects for which the teach assigned homework. I would write three-letter abbreviations out on a small 2.5″ by 2.5″ of paper, squeezing Monday through Wednesday on one page and the rest of the week on another. The first lesson I learned was to write in a small, regular type so that things could fit on a small piece of paper that I could take with me anywhere.

Soon I realized that it’s better to attach the tasks to the day they are due (or the day before, to be precise) rather than the day they were assigned. This pushed Monday through Thursday on one page and the weekend on another (since I ended up doing most of the task on weekends).

At some point the list was enhanced to include items not related to homework: for example, I wanted to find a new wallpaper for my computer’s desktop, or finish a particular computer program or a game I was working on. Most of the things I had listed at this point were tasks–they were specific and achievable in the frame of one week. When I added longer-term items (for example, books that

I was supposed to read over a semester), I’d separate them visually from all other items with a different color. Finally, I started using icons to represent frequently-listed tasks, partly for increased efficiency, partly because I liked having a system that only I understood.

When I was 16, I went to high school in London. My tasks slowly amalgamated into goals, small and big; particularly as I started listing things I wanted to achieve for self-improvement. This was also the first time that I separated short-term things from long-term things: the latter was one large sheet of paper that I kept in my drawer; the former became post-it notes (yes! I discovered post-it notes!). This was mostly also due to efficiency — I didn’t want to keep copying the same items over and over again from one week’s post-it note to the other.

The move to post-it notes also forced me to keep everything on one page. This ended up being a good thing: I was realizing that I’m a hypervisual person–being able to grasp the entire week at once allowed me to get things done more efficiently (this is also why I prefer restaurants that display all the entrees on one page).

At some point in my senior year in college I finally moved to have an electronic form of my todo list. I held out for quite a long time, because the act of writing out my tasks seemed to make a longer lasting impression on me than typing them out. But through behavioral change I slowly got used to referring to my todo list on a computer. I worked out a few rules that made such a system possible: having the list open at all times (so that I would never lose sight of what I was doing–this also forced me to keep the list small), using simple formatting (I stuck with plain text notes formatted with tabs; simple formatting allowed me not to lose sight of the tasks, allowed me to edit the list very quickly, and made the list very compact). I worked out very efficient (“cryptic” to some) terms to denote tasks.

It was then that I started to think about the effectiveness of my strategy to get things done (mind you, that was back in the day, before someone decided to write a book about these commonsensical things and made a lot of money) as opposed to just the efficiency of the representation. It became more important to have a system that helped me achieve the things rather than a system that allowed me to write them down quickly. This is where a lot of the experimentation happened. I thought a lot about what makes me motivated and while most of the motivation is independent of the protocol for keeping track of goals and tasks, I found a fairly significant variability between which system I used and how effective I was at getting things done.

I toyed with an idea of a kind of game I’d play with myself, a kind of system where I’d reward myself for getting stuff done. I didn’t really need any exogenous incentive–earning virtual “points” was all that I needed (perhaps it’s because I’m a conceptual thinker, or perhaps because I’m a nerd). I’d assign myself points for every task, and the number of points was proportional to how “important” the task was. I would set goals for, say, a month. I went even more crazy than that, coming up with a number of point thresholds, exceeding each of which would give me a different “rank” (it’s incredible how much fun a kid can have with nothing but pen and paper). Recently I dropped any kind of scoring system because I noticed that I by and large knew how well I was doing and keeping track of my score became less of a factor in motivating me — in other words I realized that the desire to get things done had to come from something else than how many points I got for the day.

I also experimented with the timeframe for my short-term todo list. At that point I still had two lists: a short-term one and a long-term one, and every time I came up with a new instance of the former one I’d consult the latter. For about a year I changed the frequency of the short-term list to be biweekly but I found that a frequency of one week is optimal — the list needed to include at least one weekend (otherwise it wouldn’t be all that useful since I do get a lot of the stuff done over the weekend–the weekend is also a “buffer” for overflow work); but if it included more than one I would end up feel too complacent on the first weekend and postpone everything to the second one.

About three years ago I came up with a framework for a high-level structure of the todo lists that I had by and large accepted and tried to follow: I listed things which I wanted to do every day (for example, get up to speed on the blogs that I was following; or go jogging) in a kind of “checklist”. Generic todo items would follow, at first scattered arbitrarily throughout the week. Specific events had dates attached to them. I had a separate file that listed events happening on a particular date if they were more than a week away, to not litter my todo list too much.

I went back and forth on whether I should explicitly include the daily tasks on my list or not. At first I thought that by including them I would be more incentivized to do them every day. At the end updating them ended up just wasting my time so instead, my short-term list now has a list of these things to remind me what I have to do every day, but I don’t keep track of whether I actually do.

Finally came the iPhone and for the first time since I switched to a computer-based todo list I could carry the lists with me at all times. It was great as I no longer had to email myself notes (or keep them in some separate
container and then get them out of my iPhone). I’m still pretty adamant on keeping the notes as simple and unformatted as possible and accessible from anywhere so I wanted to stick to text files. Fortunately I found an app called SyncBook which did exactly what I wanted it to do — it allowed me to sync a folder of text files between my computer and the iPhone and–most importantly–it allowed me to edit the text files on the iPhone (there are several good apps that work in a similar fashion — take a look at Evernote if you don’t need the notes to be text files and don’t mind slightly bigger overhead, or just sync native Notes if you don’t mind Marker Felt. There are also apps that allow you to edit richer documents if you do care about the formatting).

About three months ago I settled on a final design for my todo lists. I like it because

It’s simple–there is minimal overhead; I only need to update pretty much one word when I complete a task (or want to add a new one)
The important information, and only the important information is with me at all times–I have the todo list open on my computer, and when I’m away from my computer I have it on my iPhone. Syncing is as easy as pressing one button in SyncBook, and I can sync over the local network, which is great (I can do it anywhere around the house)
My todo list is organized in a three-tier structure: day, week, month, which is a natural structure to think about tasks
- week (a short term list) enumerates all days of the week with things which I have to do that day. It also has a general “grab bag” of items which I simply have to do at some point in the week. Finally it has a list of items which are my daily tasks (I don’t repeat them for every day) and a list of items which are my weekly tasks. All the daily and weekly tasks derive from my goals. Finally, it contains a list of problems in my life that I want to solve in order of how anxious they make me.
- thisMonth enumerates all items which I’m supposed to do at some point in the month. I also include longer term periodic things such as what books to read and what miniprojects to do. Every week I take some items from this list and put them in the week list.
- nextMonth enumerates all items which I’m supposed to do next month. Every month I move them to the thisMonth list.
- calendar which contains all events with dates attached to them. I tried to use something like iCal but I like the flexibility of specifying indeterminate times (e.g. some time in the latter half of January) and I found the existing interfaces of iCal insufficient
All the items are available offline — I hate not being to access something because it’s online, or having to deal with slow web-based interfaces. Changing a status of an item takes me a couple of seconds at most
It’s short–the short term list consists is a text file measuring 20 rows and at most 50 characters in a row (so it can fit on one page on my iPhone). All thanks to efficient representation of todo items — there’s no need to be verbose since I remember most things that I’m supposed to do given a short prompt. For example, I know that “nprAlarm” is a task to set my computer up so that it wakes me up every morning by playing the live podcast of WNYC.
It’s fast–syncing is fast, editing is fast, viewing is fast. Moving items from one list to another is fast.
All my goals are represented in one form or another on the short term list. That way I’m constantly reminded of what I’m supposed to be doing and how it connects to my goals.

Of course, this framework is just one of many and which framework works for you depends very much on your personality and what makes you tick. I do, however, encourage you to follow a few principles:

Have a list. Some people say that having a list is bad because you stop relying on your memory. I solve this problem by training my memory in other ways (e.g. with Brain Challenge). Don’t conflate training with work
Experiment. Switch things around. A kind of “evolutionary” process–an informed random walk–allows you to find the most effective system
Keep it simple. Complicated lists end up wasting time and detract from actually getting stuff done
Keep it available. You never know when you have some time to knock something off the list, and you never know when you want to add something to the list
Keep it flexible. After all, we think in free-form way, not in a highly structured way, especially when we go about our daily activities and let our mind wander

Posted in lifehacks, lists, principles, things everyone should do | 4 Comments »

Life Hack #26: How to prioritize things

Thursday, November 19th, 2009

(This might be one of the most useful discoveries I’ve made about myself so far. This may not apply to everyone but I’ve found it very valuable.)

Prioritization is a difficult problem because it involves more than one factor. If only one dimension is important, prioritization is easy: since prioritization is an ordering of things, all we need to do is come up with a consistent (transitive, i.e. if A is “more” than B and B is “more” than C then A will always be “more” than C) ordering of items based on that one factor. For example, if we want to prioritize solely based on how much we want to do something, we’ll do a good job coming up with the order (do it the way we sort a hand of cards — for each item, figure out which of the items already prioritized it’s “more” than and which one it’s “less” than).

The reality is that prioritization involves multiple dimensions: how much we want to do something (both in the short term–instant gratification–and the long term), how long it’s going to take, how hard it’s going to be, how tedious it is to do (which is different from the other three!), etc. We can no longer come up with orderings because we don’t really understand how the different dimensions relate to one another. Which do I want to do first: something that takes a long time but is enjoyable, or something that’s hard but gives me something in the long term (and, of course, the degree to which these factors are at play is also important).

I’ve witnessed many people try to come up with frameworks to handle this problem. We’ve all done it: one-to-ten grades, complex formulae that look like weighed averages (although nobody wants to admit that that’s what they are), forced rankings, baffling heuristics… I’ve tried and failed many times. At the end of the day I feel like something is not quite right.

And this led me to a solution which I’ve been trying out for the past two weeks, with great success. I started prioritizing things based solely on one factor (which is easy), namely based on how anxious not doing them makes me. I think I’m “spawning” a new principle that seems a good one to follow in my life: leading an anxiety-free life (perhaps that’s what happiness is, after all).

I have a short list of problems that I want to tackle in my life. I reorganize this list based on how anxious I feel about each of these problems. All tasks that I have to do that derive from these problems are therefore much easier to prioritize. While this model is much more simplified (it ignores a lot of the factors I mention above), I’ve found it to be (a) very satisfying, and (b) fairly robust (i.e. I can still shuffle some of the tasks around and by and large I feel good about the results). Perhaps this capacity of something to reduce one’s anxiety is a good natural heuristic that combines these factors. Perhaps it works because it addresses a deep feeling, a kind of fundamental utility. Either way, it works like a charm.

Posted in discovery, lifehacks, principles, things everyone should do | 6 Comments »

On diagnosing problems

Thursday, October 22nd, 2009

The ability to diagnose problems is one of those incredibly useful skills to have in life. From experience and observation, I can say that very few people possess it. While it’s a bit of an art, there are some simple principles that people just don’t seem to apply.

You may think that diagnosing problems is an ability that’s really only useful in a narrow domain, such as programming or fixing cars. But we come across problems all the time, even when we don’t realize it (A clogged drain in the bathroom. Tivo doesn’t want to record your favorite show. You don’t seem to be losing any weight despite being on a diet). So here are the basic principles. Nothing in here will be a surprise to anyone; the bulk of the work is in internalizing those principles–and being able to apply them when solving problems.

Define the problem.
What is the problem exactly? Can you concisely yet precisely formulate what the problem is? If you have to use words such as “broken”, this is usually an indication that you haven’t really defined the problem well. How does the problem manifest itself? It’s very useful not to mix diagnosis with the formulation of the problem; at this point your diagnosis may not be correct and you may be incorrectly leading yourself down a wrong path from the very beginning. A useful trick is to try to simply phrase the problem as something that constrains you, i.e. something that prevents you from doing something.

Replicate the problem.
Can you show me the problem manifesting itself? Most problems in the world are easily replicable; for example, if the TV doesn’t turn on, it doesn’t turn on. But some problems are more tricky than that–maybe your brakes make a noise only when the engine has warmed up enough; if you just turn the car on, you won’t hear the noise. Being able to show the problem occurring is very useful as it allows you to test your theories easily. Note that at this stage you don’t need to figure out all circumstances under which the problem occurs: you just need one.

Contain the problem.
Try to replicate the problem with as simple a setup as possible. This will eliminate a lot of the factors that would otherwise have to be included in the diagnosis. A lot of people either assume that most of the steps they did are necessary for the problem to occur (very rarely is a problem a coincidence of a large number of factors), or assume that most of the steps they did are irrelevant (surprisingly frequently is a problem due to something that one implicitly rules out early in the diagnosis stage).

An Aside: on Theories
Note that while you will certainly run across theories about the problem as you try to replicate it and contain it (and sometimes even define it), you should be careful not to jump to conclusions too quickly. I think a lot of smart people are also lazy, and this combination manifests itself as impatience when diagnosing problems. There’s nothing wrong with having theories, and in fact, experienced diagnosers will be able to come up with a theory with very little information. But what I see a lot is people coming up against a problem they can’t solve and struggling to solve it because they are either stuck with theories that don’t work and can’t find better ones, or went down the wrong path early on in the diagnosis (when I was a teaching assistant in a computer science class back in college, I would help students find bugs in their software. They would be taken aback at the simple questions I asked them; “Of course that’s not the problem,” they would say. I’d tell them, “If everything is an ‘of course that’s not the problem’ yet you can’t fix the bug, at least one of the ‘of course that’s not the problem’s is probably the problem”.

So hold off on theories for as long as you can–if you ran across a hard problem (which is really the domain we’re interested in here), you are likely to want to solve it, and only as a second-order thing to solve it quickly.

Locate the problem.
Chances are, by now you probably will have located the problem to a large extent. If you haven’t, it’s the natural next step: determine where the problem lies. There is only a subtle difference between locating a problem and testing theories, so you will invariably be doing the latter as well. Start with your (small) setup needed to replicate the problem. Vary your setup to draw conclusions about where the problem is (or, more likely, where it is not). This will help you narrow down a set of theories that you will have to try out by a substantial amount. It’s a good idea to do easy things first (to gather as much information as possible about the location of the problem), but of course there’s a bit of an art in trading off cost of the experiment against the expected amount of useful information it will give you.

For example, I once had a clogged drain in my sink. Here is what I did–compare this with the steps above:

The problem was this: the sink would accumulate water quickly so I couldn’t have the tap running too long or I’d flood my bathroom.
I could easily replicate the problem by turning on cold water to its maximum and waiting for one minute. The sink would fill up with water.
I noted that I don’t need to use cold water; hot water would do as well. I also didn’t need to turn it up to the max–at some point (maybe half way through) water would start accumulating
Locating the problem is one of my favorite parts of diagnosis. First, I poured water down the “safety” drain located on the upper part of the sink (the one that prevents the water from spilling out of the sink). I could not replicate the problem. This means the problem is somewhere between the hole in the sink and the part where the drain meets the safety drain. This is great because I no longer needed to unscrew the “U”-shaped part in the drain (it was below where the safety drain flows). If I had started with a theory (“there’s probably a bunch of disgusting stuff blocking the ‘U’-shaped part”), I would have wasted some time.

Note that normally we just do this all implicitly, in our heads, but there again, a clogged drain is not a hard problem. It’s a good idea to be a little pedantic once to get a feel for what diagnosing problems well means.

Finally, form theories and test them out
If you’ve gotten to this point, you are likely dealing with a hard problem. Good!–because this is where the most art comes in. The hard part about forming theories is that you have to find theories that help you prune your search tree as much as possible, in as cost effective way as possible.

The “search tree” thing is very important. I cannot stress it enough. Each theory you test eliminates a class of problems. So if you imagine the set of all possible problems, each theory you test in the sequence will eliminate a subset of them. It’s much better to eliminate most of the problems first (this gives you fewer problems left, so fewer theories to test). It’s a little bit like the game of 20 questions–it’s better to ask a generic question that eliminates half the possibilities first, than a specific question that with high probability eliminates a very small set. Of course you don’t know the probabilities or even the eliminatory power of your theories so this is where the art comes in. You have to trade off three things:

How expensive is it to test your theory?
In the best case, how many problems can the test eliminate?
How likely is the best case?

Again, if you’re stuck with a problem, you will likely not care about being the most efficient so really you should strive for your theories to simply eliminate as many potential problems as possible (ideally in a balanced way, just like the questions a good “20 Questions” player would ask).

The nice thing about a problem tree that you thus construct is that if it’s balanced, you will not need to test many theories — just like 20 questions should be enough to find a thing from amongst a million things! However, one thing I see people do over and over again is forget where they were on the tree and either redo many tests, thus getting no useful information, or perform tests that are irrelevant given where in the problem tree they are (for example, if I tried to see if the “U”-shaped part is clogged after I figured out that it’s not the problem).

Posted in lifehacks, principles, things everyone should do | 2 Comments »

Life Hack #25: Music for running

Thursday, October 15th, 2009

I’ve spent some time thinking about how to trick myself into perceiving running (especially running on a treadmill) as not such a boring activity. I used to listen to audiobooks and podcasts, but found listening to music to yield the most success. A few days ago I went through my music and picked out songs for running. What was different this time, though, was that this time I looked at the tempo of each song to match it up to how fast I wanted to run.

Everyone has a different pace (and a different frequency with which they move their feet when they run at different speeds) so there is no good formula, but I recommend playing various songs while running on a treadmill and finding the speed at which the song seems to be in sync with your run. You can use any of the (sub-)harmonics of the frequency (so a very slow song may still be appropriate, if you happen to move your feet twice as fast as the song’s tempo). You can then arrange your playlist according to how fast you want to run at the various stages of your run.

I also had great success picking the songs I really liked, or was motivated by, to appear at the beginning and the end of the playlist, for additional motivation. I also found that around two-thirds into the run, I’d be particularly demotivated (likely to stop), so I put some good songs around there, too.

Posted in lifehacks, paramathematics | No Comments »

Life Hack #24: Train Yourself in Behavioral Change

Monday, October 12th, 2009

As we get older, we tend to trade off flexibility for comfort. We begin settling on the food we like, the music genres that we find pleasing, the technologies we are comfortable with. There is something deeply satisfying, though, about the ability to fundamentally change something about our lives. I suggest you go through an exercise to try to change your behavior in some aspect of your life.

A good example–one that some people attempt–is to lead a more active life. I tried that as part of my goals over the past year. Behavioral change is not easy–we fall back to the old model very easily and quickly, and any deviation from a carefully worked out new routine can ruin the whole plan. This “infant mortality” period is usually pretty long–it lasts somewhere around a year, sometimes more–but once it’s over, the feeling you get is deeply satisfying. Often the change of behavior you want to effect is a very positive thing (leading an active life makes you healthier, for example) that you can only achieve through an investment like this.

How do you know when you’re done? That’s very simple–when the new behavior feels right and effortless. To put it bluntly, at first it will be a pain in the ass to do the new thing; you’re done when it’s a pain in the ass to do the old thing.

Posted in lifehacks, principles, retrospective, things everyone should do | 2 Comments »

Life Hack #23: Write notes to yourself

Wednesday, October 7th, 2009

I often catch myself having microthoughts in the least expected moments- in a restroom, while working out, in a dream, while listening to the radio. I like to write them down because many times a small thought would lead to a really good idea, or even a change in my life philosophy.

There are, of course, many ways to write notes to yourself. I like doing it electronically, because I don’t want to transcribe everything. I also like my notes to ultimately end up either in my inbox (which I treat as a high-priority todo list) or go directly into the todo list). A simple solution of using the Notes app on my iPhone and then emailing the notes to myself once I’m done, or just keeping a “compose email” window open at work and sending the items to myself atthe end of the day does the trick for me.

Posted in lifehacks | No Comments »

Life Hack #22: Frequent resolutions

Thursday, October 1st, 2009

I love making resolutions. I’ve found them to be a great way to get motivated, especially after I’ve failed to deliver on some other promise I made to myself. For example, I’d promise myself I’d stop eating junk food. I’d do pretty well for a couple of weeks, and then a familiar story happens (I’m sure something similar happened to you if you’ve made some resolutions): I have to stay late at work, or I end up celebrating something with my friends, and I end up eating a bunch of junk food. Worse (because junk food is just so good and because I’ve already failed), I continue eating junk food.

I found the best way to get out of this hole to be saying to myself, “OK, tomorrow, I am restarting my life. I’ll eat healthy food, and also go running every other day.” I stop thinking about what had happened and start looking into the future — hell yeah, I’ll be able to stick to my new resolution! I’ll be strong–it can only get better from now.

It is, at the end of the day, just a game I play with myself–but there again, if I didn’t need to play games with myself, I wouldn’t be failing on my resolutions. There are some caveats that I’ve realized over time.

Don’t wait for an arbitrary time to start a resolution. No point waiting for Monday morning (or, worse, the beginning of a new month!) — tomorrow is as good a day as any. In fact, why not start right now? I like to write the time at which I made the resolution on a white board in my room to remind me of how much time has passed without me breaking a promise.
Be careful not to make the ease with which you make resolutions become an excuse for breaking promises. I’ve noticed that I’ve made my resolutions more frequent through waiting much less, not through breaking my promises faster.
Don’t be too ambitious–small promises work best, especially if you extend them over time. If you promise yourself something unachievable, you’re likely to break it sooner (and, what’s worse, you’re also likely to dip deeper–for example, break all the promises you’ve made so far at once)
What you do between breaking a promise and making a new one matters–I used to stuff myself silly with junk food before making a resolution not to eat it “because it’s the last time in a long time I’ll be having it”. As a result, I ended up eating more junk food over time than before making these resolutions. This is also another reason why you may want to decrease the amount of time between breaking a promise and making another one.

Posted in lifehacks, things everyone should do | 1 Comment »