Adding lots of git love to your prompt

There are two things that are really useful to see *at a glance* while writing code:

  1. What branch am I on?
  2. Have I modified stuff?

NINJA EDIT: Alan Antonuk has mentioned that there already are such bash prompts in git. Here’s what I’m now using:

#git ps_1
if [ -f ~/ ]; then
    export GIT_PS1_SHOWDIRTYSTATE="true"
    export GIT_PS1_SHOWSTASHSTATE="true"
    . ~/
    export PS1="\$(__git_ps1)$"

You can get the latest from

And here’s what I used to use:
I added some stuff to PS1 so my bash prompt shows both the the branch name and the diff status.

Define two functions in your ~/.bash_profile:

    function parse_git_branch {
        git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ \[\1\]/'
    function check_modified_git {
        if git diff --quiet 2> /dev/null && git diff --cached --quiet 2> /dev/null
            echo "*"
            echo ""

and wrap the change to PS1 with a test for git – just in case your bash_profile is executed on a machine without git installed:

if hash git 2>/dev/null; then
    export PS1="\$(parse_git_branch)\$(check_modified_git)$"

Of course, you can do fancy things with colors. There’s lots of explanations of the bash color codes online; here’s one:

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.

Getting off the intermediate plateau

If you’ve ever learned a skill to a high level (advanced, expert, rockstar, etc. are labels that are often used) and stopped to think about the experience, you might draw a graph that looks like this:

Skill versus Time: the inevitable plateau.

Skill versus Time: the inevitable plateau. (Thanks to Anna Czoski for creating this.)

I think most people have experienced this in some shape or form. I think I’ve experienced this enough times to form some thoughts about what is universal about skill-learning. Today I want to explore those common elements and in a later post I’m going to propose some ways I think learning can be improved based on those commonalities.

If you’re wondering, I’ve struggled through – or am still in – this  ‘intermediate plateau’ in:

  • salsa
  • tango
  • guitar
  • piano
  • most computing languages – my most recent, Ruby

At first, almost all people have an easy time learning a skill; you get better, exponentially, and there’s a tight feedback loop, because the improvements are very visible and very easy to feel – your frustration level drops quickly. With sufficient time, you become intermediate; “good”, but not “great”; an average sized fish in the pond.

This is when things get hard. Does this sound familiar?

  • You’re good enough: You can accomplish enough things to ‘get by’, but you don’t execute as well as advanced peers or experts
  • You don’t know how to improve: the lessons or classes that you found great as a beginner don’t seem to be useful anymore
  • Your peers are other intermediates: whether you’re coding with others, dancing socially, or jamming with friends, you feel comfortable performing with other intermediates. But when you have the rare opportunity to engage with an expert or advanced peer, you feel nervous, out of your depth, uncomfortable; unable to keep up.
All of this should should familiar. But why do people end up in a long, drawn out plateau where their skills don’t grow? Here’s what I think are the key reasons intermediates “get stuck”:
  • Less incentive to improve: Intermediates know how to do enough to be successful; that might be having fun with others, or being able to build the average RoR website, or complete work items assigned at work. Beginners find everything frustrating; so they don’t have an option of doing the ‘fun thing’. But intermediates find some things frustrating and some things fun. They avoid the frustrating things: it’s human nature. For example, intermediate skiiers complain they can’t do black diamond runs well, yet when asked what they ski, they predominantly ski blue runs. The thing, then, is to:
    1. Do what is hard; don’t perfect what is easy.
  • Beginner teachers are unlikely to be good intermediate teachers. There is a lot of material out there for beginners. First, there is a monetary incentive: there’s lots of beginners and high turnover. Second, the level of skill required to teach beginners is low: so instructors are easier to train and teaching material easier to create. But beginners don’t realize they need different teaching once they become intermediates. They gain little value from continued investment (in time and money), and eventually become frustrated and quit lessons or structured learning. So:

    2. Intermediates desperately need high quality teaching methods and materials, and their needs are very different from beginners.

  • No role models or mentors: Beginners spend a lot of time with other beginners but also intermediate peers; in other words, they ‘peer up’. Intermediates more often ‘peer down’: that is, they spend a lot of time with other beginners and intermediates, but not with advanced folks. Without such direct, high bandwidth interaction, intermediates have difficulty understanding where they need to improve. Simple time, however, is rarely enough. Structured feedback is required: oftentimes, advanced practitioners are so good at what they dothey consciously or even subconsciously workaround the problems intermediates exhibit.  So:
    3. Intermediates need advanced role models and mentors to improve.

Now, if all of this seems obvious and trite restatements, apologies. You’ve likely been thinking about this problem just as much as I have. I realized this post is quite long, so I’ve split it into two parts. In the next part, I’ll actually get into the meat of this post-series: how I propose we can improve the educational / learning experience by systematically attacking each of these 3 points I’ve outlined.

Hello, World

Hello, world (BASIC)

The canonical hello world

I’ve long wanted to write about all sorts of things. Sometimes I have long (and I mean long!) discussions about things that later I want to reference, wikipedia-like, while arguing in heated discussions with friends. Other times I just want to record something important, inspiring, or intriguing and let the world know.

I hemmed and hawed about starting a blog. I registered on tumblr and wordpress and thought about using G+. But a couple of things stopped me for years.

First, I found Facebook updates “almost good enough”. Most people would agree Facebook is poor for long-form interaction (and G+ is substantially better in this respect). But I rarely had the patience to write out longer texts anyway, so this didn’t bother me much. I found the pain bearable.

Second, I thought most people (most of my friends, I mean, of course) had the same opinions on most of the topics I felt were important. This, I am discovering again, is really – really! – not true on a wide range of topics. Turns out we all come from different places, and apparently, my viewpoints are pretty strange.

Obviously, though, something kicked me in the pants. And that thing is Quitting My (Cushy) Job and Becoming An Entrepreneur. I certainly want to write about and record my journey as a startup founder. So I have, finally, a Great Reason To Start A Blog.

But what to write about? Focusing on specific parts of your life works: I’ve seen many people separare the “personal” from the “technical”. But it’s hard work. Since I don’t want to make writing any harder then it is, I have instead decided to write about everything that I want to write about: Dancing, Technology, The Future, and Entrepreneurship.

I’ve also set a goal for myself: to write 2 posts a week. Here we go!