Self-discipline is a muscle. Exercise it.

Today I was at one of my favorite coffee shops when I ran into a friend I hadn’t seen in a long time. Rob and I got to talking about self-discipline. I shared a couple of observations that I’ve made over the past month now that I’ve quit Microsoft and restructured my life as a startup entrepreneur:

1. The kind of self-discipline I need as a founder is pretty different from the kind of self-discipline I needed as an employee.

The work week and 9-5 are now for me meaningless concepts.

Certainly, I had a great deal of latitude when I worked at MS, as do most employees at excellent places to work. But there’s a world of difference between the unstructured life/work I now lead compared to my previous employed life. For example, I can work where ever I want, whether that’s at home, at coffee shops or even in entirely different cities or countries. I can focus on startup stuff 0 hours one day and 24 the next, depending on how I feel.

I think that this was the hardest adjustment for me and many other tech folks I know. Much of programming is done alone, optimally with no interruptions. Many tech people are night owls as well. Combined with the new lack of required structure, I think it’s incredibly common for founders to spend the first month or two after quitting just working out how to work again.

In many ways, this kind of work/life blending is very similar to the college experience. College students accept that life and (home)work are intertwined. In contrast, most folks working for companies try very hard to separate “my time” from “work time”.

In other words, the self discipline most employees focus on is divisive whereas the kind of self-discipline startup founders need is integrative, like the kind successful college students have. The two are quite different, and many folks don’t realize this until they become frustrated and fail to be productive.

2. Self-discipline is like a muscle: use it or lose it.

So what happened to that college-era ability? Like a muscle, self-discipline (of any kind) atrophies if it is not actively used. For example, when I worked at Microsoft, it was easy to decide when to start working: 10 to 11am or the earliest meeting in the day. It was also easy to decide when to leave work: when enough stuff got done and 520* wasn’t gridlocked. The part of my self-discipline that handled when? and how long? atrophied away, and I had to rebuild it before I could become productive again.

Now, I’ve focused so far on the differences in time management, but founders must juggle far more tasks, in greater breadth, then they likely ever did before. They must balance and make progress on tasks relating to business, finanicals, life, idea generation, networking, people, hiring, and more. Most first time founders were not previously VPs or C-suite executives, so they have no experience dealing with such a wide breadth of projects every day. This is certainly true for myself.

Needless to say, I didn’t have any self-discipline at all when it comes to dealing with business errands like filing paperwork and handling banking bureaucracy. So what is the easiest way to grow or regrow self-discipline?

3. Just like a muscle, asking too much of your self-discipline without gradual training leads to immediate failure.

Where many people go wrong, I think, is forgetting that like muscles, self-discipline needs time and training to grow. You wouldn’t expect to be able to suddenly bench press 200 pounds if you haven’t worked out in years. Yet many people expect their self-discipline to start handling the vastly increased load overnight.

A common refrain I have heard is: “Well, look how much I got done while I was working a full-time job at the same time! Now I’ll have an extra 10 hours a day, so I’ll zoom along! I’ll be more productive, happier, and the app/prototype will be done in 1/3rd the time!”

Instead, I have seen months of low output and frustration before people stumble onto the correct training path.

So here are some suggestions or tips that have worked for me to grow or regrow my self-discipline:

  1. Unless you are or were a VP or C-level exec, accept that you will need to spend time to grow your self-discipline in new areas, and you won’t be as productive and effective as you hope at first.
  2. Start at 0. In other words, take a vacation. Vegetate on the couch, focus on a hobby, or go on that trip you always wanted to.
  3. Next, pick the set of highest priority things that absolutely have to be done. Make sure they are clearly date driven. These will certainly be incredibly necessary things like paying your credit cards on time, paying rent, filing tax paperwork or other legal documents, and so on. Now, of course you’ve been able to handle these kind of things in the past. The idea is to reinforce and retest your self-discipline level in the new, unstructured environment you find yourself in.
  4. Finally, pick different goals in different areas. If you were a professional programmer previously, it’s likely you have strong self-discipline muscles in that arena. Go ahead and set aggressive goals there. In other areas, set very low, very easily attainable goals, and make yourself accountable by engaging peers or mentors to apply social pressure. Set arbitrary dates to deliver arbitrary goals. In other words, be your own professor or sports trainer. As time passes, and that self-discipline muscle grows stronger in that field, you can start upping the weight you can lift.

Now, the idea of “self-discipline as a muscle” is pretty common. Another interesting article on this topic from study hacks can be found here. It talks about self-control and self-discipline as a muscle as well, and takes a different tack on how to improve or trick yourself into working more productively. While I talked about growing the capacity of your self-discipline muscle, Cal talks about how to use that capacity as effectively and efficiently as possible.

* 520 is a floating bridge (in fact, it’s the longest floating bridge in the world). Most days, it gets incredibly backed up, and from the rush hours of 4-7pm, it takes 1-2 hours to travel 7 miles or so.

Ruby Love #1

In my post about Elegant code and craftsmanship, I talked about how DRY – or Don’t Repeat Yourself – is one of the prime directives I try to follow as I develop.

In this series of posts, I’m going to post small tidbits of cool language constructs in various languages that help keep things DRY. They’ll all be tagged under language love, so you’ll be able to search and keep track of them in an easy way.

Today’s tidbit: generating methods in Ruby.

Sometimes you write a lot of code that looks like this:

    def commit_all
      @productions.each do |k,v|

    def dump_all(d)
      @productions.each do |k,v|

    def	reset_all
      @productions.each do |k,v|

Doesn’t feel very DRY, does it? In fact, if you end up changing how you store your productions, you’ll have to change the code at least three times. Urgh.

Ruby allows you to define methods dynamically, on the fly. So you can instead write something like this:

   [:reset, :commit, :dump].each do |m|
      define_method(m.to_s+"_all") do |*args|
        @productions.each do |k,v|
          v.send m, *args

Note how the _all* methods also correctly forward the arguments, if any, to each production’s method.

Cool, no? Of course, this is really just classic metaprogramming much like Lisp. I just love how Ruby expresses it! The syntactic sugar is a nice mix between too verbose and too sparse, while still being flexible enough to allow lots of metaprogramming magic. (I will admit the way Ruby expresses variable arguments is a little confusing, though…)

Elegant code and craftsmanship, or, how lagrangian mechanics is the same as Ruby on Rails

Recently, I’ve been working on a project that customizes my task management software. I’ve been writing it in Ruby, which is a pretty interesting language.

At this point, I’ve probably rewritten the code 3 times.


Because it’s more elegant the second (third!) time around. Because it’s more beautiful, easier to maintain and understand, and easier to extend and grow. But, most importantly, because it feels good.

In fact, every time that feeling hits: “Wait, I could do this better!“, I think of college and my time as a physics major. We all used to work on our problem sets in this one room in Leconte Hall:

Leconte Hall

Leconte Hall

I was never that good at physics. My solutions were always ugly, three or four pages long, full of copied terms that never went away, even though everything started beautifully elegant and short, like this lagrangian: 1

Lagrangian in spherical coordinate system

When I compared with my classmates, I knew they were out of my league. Not only did they get the right answers, but their answers were beautiful. Short. Concise. Elegant. The answers, in other words, at the back of the book.¬†Invariably, my classmates would say: “Well, you see, if you just chose this” or “Well, if you just rearrange this…”

I never really “grokked” physics deeply enough to feel my way to those insights without help.

But I think I can articulate what, fundamentally, is the most important feeling that guides me to great, elegant code:

Don’t Repeat Yourself, ever.

There’s a whole bunch of reasons why you should write elegant, concise code. I think a lot of people have made convincing arguments, showing that it increases maintainability, flexibility, and so on. I’m going to take a step further. I claim those things are simply gravy.

In the long run, if you want to keep on solving hard problems, or hacking together great prototypes in 8 hours in an all night hackaton, or growing your product, you need to love what you are doing.

The first step towards loving your work is respecting the work you create and honoring the feelings you have while creating it. Don’t stuff those “I can do this better” feelings away because it means you have to rewrite something or take 2 more hours to do it right.

It’s worth it to do it right.

EDIT: I’ve kicked off my language love series, which will be short posts about fun things that I find really elegant in different languages: the first is about dynamically adding methods in ruby.

1. This is a pretty elegant lagrangian for the total energy of a particle in spherical coordinate system. And yes, I got it from wikipedia; I haven’t installed LaTeX in years.