Last week I read Accelerando, a set of short stories by British science fiction author Charlie Stross. The stories start from the near future (almost the present) and extend to a distant post-Singularity future where humanity lives among the stars, but in the shadows of godlike intellects. Though the entire collection is worth reading (and available for free), the first few stories about a world not too different from our own were particularly interesting. At one point one of the main characters, a very intelligent serial entrepreneur (and “venture altruist”) name Manfred Macx claims to consume a megabyte of text and several gigabytes of multimedia a day just to keep current.

That’s a lot of information for any person to consume in a day – a megabyte is roughly half a million English words. Though this is science fiction, I think we’re quickly getting to the point where people who want to stay current with the pace of science and technology will be required to consume enormous amounts of information regularly. Half a million words a day may be too much for an unaugmented human (Macx has an array of cybernetic implants and software agents forming a “exocortex” for information processing) but I think tens of thousands of words a day will soon become par for the course. And that’s just text. I’m not including understanding diagrams, source code, operations manuals or even video or audio. If we’re supposed to be assimilating such huge quantities of information on a regular basis how are we supposed to make sense of it all?

That brings me to a piece on The Atlantic website dramatically titled “Is Google Making Us Stupid?“. It’s about how the use of search engines and similar fast information retrieval systems is supposedly rewiring our brains. While some parts of the piece are overly sentimental and melodramatic, the core point is sound: the tools we have access to and the way we use them plays a role in shaping the functionality of our brains. I also sympathize that a habit of continually sampling little bites of information can be deeply unsatisfying. It’s easy to get hooked on to a Facebook or Twitter stream but as you stay hooked you can feel your brainpower wither as you lose the ability to concentrate longer than 140 characters. When I get stuck on Hacker News or Reddit for hours I feel terrible by the end of the day. Though I love good stories and movies it’s easy to get hooked on Netflix, passively consuming information but not really doing anything. But I’d like to believe that we can train our brains to be not quite so helpless in the face of endless streams of juicy tidbits.

A growing body of research is showing that the human brain is an incredibly flexible organ. Neuroplasticity is the norm, not the exception. As the amount of information we need to process increases (and our tools to do so get better) our brains change to accomodate it all. That of course begs the question: how far can we push ourselves? Can we train our brains to not just flit from hyperlink to hyperlink but actually digest and understand large amounts of interconnected material with greater efficiency and accuracy? Can we ensure that Google makes us smarter and wiser, not stupider?

Though our reading habits (and by extension our general thought patterns) might be changing, the change is not accidental nor is it inevitable. Instead of bemoaning the loss of the slow reading habits of yesteryear I think we should be trying to embrace the information-dense world around us. In particular, we need to stop thinking of deep reading and skimming as antagonistic to each other. Perhaps what we need to do is not to read slower, but rather separate the physical act of reading from the mental act of comprehending what we have read. I would love to be able to read text fast, look up links and references and then let the mass of information “ferment” in my brain. I’d like to be able to train my brain to think of what I’ve read after I’m done looking at the text forming connection betweens concepts and ideas while I’m walking down the street or taking a shower.

Perhaps this is an exceedingly computer-science centric way of thinking about the brain and thought processes. To be honest, I’ve been writing code and processing data algorithmically far longer than I’ve been learning about how the brain works. I do tend to think of the brain primarily as an information processor. Unlike the author of The Atlantic article I’m not nearly as attached to the so-called “human” aspect of my intelligence (but that’s a matter for another blog post). I like settling down with a cup of coffee and a good book in a nice armchair as much as the next guy, but only on the weekends. During the week I’d like to come up with six impossible things before breakfast and figure out how to make them possible through the course of the day. To do that I need to keep the information machine fed, creativity doesn’t happen in a vacuum. I’d love to know how to do that better.

When I’m working I spend most of my time in three applications: a text editor (generally Emacs), a terminal (either iTerm2 or Gnome Terminal) and a browser (Firefox or Safari). When in Emacs I use the excellent Magit mode to keep track of the status of my current project repository. However my interaction with git is generally split between Emacs and the terminal. There’s no real pattern, just what’s easiest and open at the moment. Unfortunately when I’m in the terminal there’s no visible cue as to what the status of the repo is. I have to be careful to run git status regularly to see what’s going. I need to manually make sure that I’ve committed everything and pushed to the remote server. Though this isn’t usually a problem, every now and then I’ll forget to commit and push something on one of my machines, go to another and then realized I’ve left behind all my work. It’s annoying and kills productivity.

Over the last few days I decided to sit down and give my terminal a regular indicator of the state of the current repository. So without further ado, here’s how I altered my Bash prompt to show relevant Git information.

Extracting Git information

There are generally three things I’m concerned about when it comes the Git repo I’m currently working on:

1. What is the current branch I’m on?
2. Are there any changes that haven’t been committed?
3. Are there local commits that haven’t been pushed upstream?

Git provides a number of tools that gives you a lot of very detailed information about the state of the repo. Those tools are just a few commands away and I don’t want to be seeing everything there is to be seen at every step. I just want the minimum information to answer the above question.

Since the bash prompt is always visible (and updated after each command) I can put a small amount of text in the prompt to give me the information I want. In particular my prompt should show:

1. The name of the current branch
2. A “dirty” indicator if there are files that have been changed but not committed
3. The number of local commits that haven’t been pushed

What is the current branch?

The symbolic-ref command shows the branch that the given reference points to. Since HEAD is the symbolic reference for the current state of the working tree, we can use git symbolic-ref HEAD to get the full branch. If we were on the master branch we would get back something like refs/heads/master. We use a little Awk magic to get rid of everything but the part after the last /. Wrapping this into a litte function we get:

function git-branch-name
{
    echo $(git symbolic-ref HEAD 2>/dev/null | awk -F/ {'print $NF'})
}

Has everything been committed?

Next we want to know if the branch is dirty, i.e. if there are uncommitted changes. The git status command gives us a detailed listing of the state of the repo. For our purposes is the very last line of the output. If there are no outstanding changes it says “nothing to commit (working directory clean)”. We can isolate the last line using the Unix tail utility and if it doesn’t match the above message we print a small asterisk (*). This is just enough to tell us that there is something we need to know about the repo and should run the full git status command.

Again, wrapping this all up into a little function we have:

function git-dirty {
    st=$(git status 2>/dev/null | tail -n 1)
    if [[ $st != "nothing to commit (working directory clean)" ]]
    then
        echo "*"
    fi
}

Have all commits been pushed?

Finally we want to know if all commits to the respective remote branch. We can use the git branch -v command to get a verbose listing of all the local branches. Since we already know the name of the branch we’re on, we use grep to isolate the line that tells us about our branch of interest. If we have local commits that haven’t been pushed the status line will say something like “[ahead X]“, where X is the number of commits not pushed. We want to get that number.

Since what we’re looking for is a very well-defined pattern I decided to use BASH’s built-in regular expressions. I provide a pattern that matches =”[ahead X]” where X is a number. The matching number is stored in the BASH_REMATCH array. I can then print the number or nothing if no such match is present in the status line. The function we get is this:

function git-unpushed {
    brinfo=$(git branch -v | grep git-branch-name)
    if [[ $brinfo =~ ("[ahead "([[:digit:]]*)]) ]]
    then
        echo "(${BASH_REMATCH[2]})"
    fi
}

The =~ is the BASH regex match operator and the pattern used follows it.

Assembling the prompt

All that’s left is to tie together the functions and have them show up in the BASH prompt. I used a little function to check if the current directory is actually part of a repo. If the =git status= command only returns an error and nothing else then I’m not in a git repo and the functions I made would only give nonsense results. This functions checks the =git status= and then calls the other functions or does nothing.

function gitify {
    status=$(git status 2>/dev/null | tail -n 1)
    if [[ $status == "" ]]
    then
        echo ""
    else
        echo $(git-branch-name)$(git-dirty)$(git-unpushed)
    fi
}

Finally we could put together prompt. BASH allows for some common system information to be displayed in the prompt. I like to see the current hostname (to know which machine I’m on if I’m working over SSH) and the path to the directory I’m in. That’s what the \h and the \w are for. The Git information comes after that (if there is any) followed by a >. I also like to make use of BASH’s color support.

function make-prompt
{
    local RED="\[033[0;31m\]"
    local GREEN="\[033[0;32m\]"
    local LIGHT_GRAY="\[033[0;37m\]"
    local CYAN="\[033[0;36m\]"

    PS1="${CYAN}\h\
${GREEN} \w\
${RED} \$(gitify)\
${GREEN} >\
${LIGHT_GRAY} "

}

Conclusion

I like this prompt because it gives me just enough information at a glance. I know where I am, if any changes have been made and how much I’ve diverged from the remote copy of my work. When I’m not in a Git repo the git information is gone. It’s clean simple and informative.

I’ve borrowed heavily from both Jon Maddox and Zach Holman for some of the functionality. I didn’t come across anyone showing the commit count, but I wouldn’t be surprised if lots of other people have it too. There are probably other ways to get the same effect, this is just what I’ve found and settled on. The whole setup is available as a gist so feel free to use or fork it.

While the devices in our pockets might be increasingly powerful general purpose computers I feel like we use them more for communication than for computation. That’s not to say that communication does not require computation (it does, lots of it), but we’re not using our devices with the goal of solving problems via computation.

This is perhaps a very programmer-centric viewpoint of mobile technology, but one that is important to consider. Even someone like me, who writes code on a regular basis to solve a variety of both personal and research problems, does very little computation on mobile devices. In fact, the most I’ve been using my Nexus for is email, RSS reading, Twitter, Facebook and Foursquare. While all those services definitely have good uses, they are all cases where most of the computation happens far away on massive third-party datacenters. The devices themselves act as terminals (or portals if you prefer a more modern-sounding term) onto the worlds these services offer.

Just to be clear, I’m not saying that I want to write programs on these devices. Though that would certainly be neat, I can’t see myself giving up a more traditional computing environment for the purposes of programming anytime soon. However, I do want my device to do more than help me keep in touch with my friends (again, that’s a worthy goal but just the beginning). So the question is, what kind of computation do we want our mobile devices to do?

Truth be told, I’m not entirely sure. One way to go is to have our phones become capable personal assistants. For example, I would like to be able to launch an app when I walk into a meeting (or better yet, have it launch itself based on my calendar and geolocation). The app would listen in on the conversation, apply natural language processing and generate a list of todos, reminders and calendar items automatically based on what was said in the meeting. Of course there are various issues (privacy, technology, politics, corporations playing nicely with each other) but I think it’s a logical step forward.

As payment systems in phones become more popular, I’d like my phone to become my banker too (and I’m not just talking about budgeting and paying bills on time). For example if I walk into a coffee shop my phone should check if I’m on budget as far as coffee shops go and check coffee shops around the area to suggest a cheaper (or better, for some definition of better) alternative. And it doesn’t just have to be limited to coffee shops.

Mobile technology is sufficiently new that most of us don’t have a very clear idea of what to do with it (or a vision of what it should do). Most so-called “future vision” videos focus more on interfaces than actual capabilities. However this technology is evolving fast enough that I think we’re going to see the situation improving quickly. With geolocation-based services, NFC and voice commands becoming more ubiquitous and useful the stage is becoming set for us to make more impactful uses of the processors in our pockets. As a programmer I would love to be able to hook up my phone to any cloud services or private servers I’m using and be able to interact with them. The mobile future promises to be interesting and I’m definitely looking forward to it.

Now that strikes me as strange because it’s not like procrastination is some deep mystery of the universe. There are people who actually study procrastination and why humans do it (and by extension, how to fight it). They’re called scientists, more accurately, neuroscientists and psychologists. What’s even better is that someone else has gone and done the work of curating much of the available research in the area and tried to offer a coherent, scientific strategy for beating procrastination. That article (and the references) are a veritable treasure trove of information, but here’s the quick start version to get you up and fighting procrastination right now.

Essentially beating procrastination comes down to three steps:

Around the Internet

Around the Internet

Programming

All I Need to Be a Better Programmer I Learned in Kindergarten Sometimes the basics can be boiled down to just a few sentences. Sometimes I think I knew more when I was five than I do now. Of course, that’s a lie, but it’s worth thinking about.

Code Fearlessly I think version control is amazing. I’ve been using Git for a few years now (Subversion before then) and I keep all my writing as well as my code in repositories, backed up to Amazon and a VPS. The great thing about version control is how it lets you make mistakes and try out wild ideas without worrying about how you’ll get back to a working state if you break something.

Health and Fitness

The Creative Brain on Exercise I know, I know. Exercise doesn’t come naturally to most of us spending our days in front of our screens. But given how much of our work is creative in nature, it makes sense to take care of our engines of creation. I think the time spent in exercise will more than pay itself back over the years (in saved medical bills and lost work time if nothing else).

How Getting Buff Can Make You a Better Rubyist. In case you’re wondering about whether any of this exercise and diet stuff actually works or not, here’s some evidence straight from the source. This is worth watching even if you’re not a programmer, but just someone who has a normally sedentary work life.

Tim Ferriss on the 4-Hour Body at the NEXT conference I know that so-called “extreme” advice such as provided by Tim in his book always earns a skeptical look, but I find his idea of minimum effective dose quite interesting. If you’re looking for the most efficient ways to change your body for the better, this is a must-watch.

Eat to Live If you’d rather have advice from a medical doctor who’s also changed the lives of dozens (if not hundreds) of people, this book is your best bet. I tend to think of it as more of a primer on nutrition and health in general rather than just a diet or fitness book. It might take you some time to get through it (though it’s a small book) but again, the investment is definitely worth it.

While I want to improve as a computer science researcher I also want to improve as a developer. For me, the fact that we must take our beautiful algorithms, logics and abstractions and express them in terms understandable to a dumb machine is not something to be despised. In fact, I consider it a pleasant challenge and a source of infinite creative joy. I would like my job a lot less if it didn’t involve a significant amount of programming. That being said, how exactly do we level up as a developer? In fact, what does leveling up even mean for a developer?

For the last few months (years?) I’ve been a growing fan of the idea of deliberate practice – the idea that the best way to improve is to take well-defined measurable steps towards getting better where at each step you get feedback as to what you did wrong and how you can do it better the next time. Deliberate practice has been applied by athletes and writers, can we apply it to programmers? In particular, can we come up with something more detailed than “Read code. Write code. Repeat”? Luckily for all of us, Jason Rudolph took some steps on that path a few months ago.

Remember that deliberate practice requires that we have a list of well-defined, actionable goals on our path to excellence. We must know clearly what the goals are and also be able to unambiguously tell if we’ve achieved them or not. Jason came up with a list of simple yes/no goals that will exercise your programming muscles. What I love about Jason’s list is that it combines a lot of what it means to be a good developer. There are goals for learning tools of the trade (different languages, environments and frameworks), goals for learning core concepts (different paradigms and parts of the software stack) and social goals (open source and community involvement). There are a lot of things on the list, but then again, computer technology is a vast field.

Jason’s list is also necessarily incomplete. I’d argue that it’s practically impossible for one man to know all about the computer technology field today. But the good thing is that we have the technology and the community to take one man’s starting point and extend it for our own purposes. Jason’s list is available as a gist on Github and has already been forked many times by people who are using it as their own deliberate practice guidelines. I have my own fork where I’ve fleshed out sections on uncommon programming languages and more theoretical learning goals.

It might be a bit naive to think that just going through a list of programming challenges will make you level up. However, I think the list is a good head fake. The point isn’t really to go and do everything on the list. The point is everything that comes as a side-effect of completing the list. You’ll definitely put in a few thousand hours and churn out thousands of lines of code in a variety of different languages and environments. You’ll expand your mind by learning about programming styles and tools that you would have missed out on otherwise. As you encounter problems you’ll have to ask around on forums, mailing lists and IRC for help. This is important because deliberate practice is useless if you’re practicing the wrong things. In the absence of programming coaches, the global communities of programmers are your best bet to find mentors and guides. If you release your code to the world you’ll gain some street cred, get valuable feedback and maybe even provide something of lasting value to fellow developers. If you follow through on the social and community goals you’ll gain non-programming, but useful skills and meet a lot more people who can point in new and interesting directions. You’ll discover interesting new problems and come up with applications and solutions you might never have thought about otherwise. Maybe, just maybe, you’ll learn enough to level up as a programmer.

As a parting note, let’s all keep in mind that this will not be easy. It will take time and effort. I’m in graduate school so I might be able to make it part of my day job to do some of these things. But a lot of it will have to happen on my own time and energy, when I could be exploring Ithaca’s gorges or watching infinite Star Trek episodes on Netflix. This is even more true for people who have legitimate day jobs and families. We all need to come up with our own reasons for why we want to invest all this time and effort in deliberate practice. But one thing I keep telling myself is that the time will pass anyway and my energy will be spent somehow. I would rather spend it on writing my own operating system than on Star Trek reruns (no matter how much I love Star Trek).

How an MIT postdoc writes 3 books, a PhD defense and 6+ peer-review papers and finishes by 5:30. One of the best and worst things about being in a PhD program is that it is opened: it can take as long as you want it. Though being at a world class research university like MIT or Cornell is certainly a wonderful experience, I’m not at the point in the life where I want to spend more than a few years in one place. I want to do good work, do it in a focused manner without killing myself and hopefully have a life and get done in a reasonable amount of time.

Thrust, Drag and the 10x Effect Managing your time goes hand in hand with managing your energy and your activities. In the software world there’s a claim that the best engineers are often ten times as productive as mediocre ones. This article aims to give you some tools to help you on your way toward being ten times as productive.

Why Emacs? I make no secret of the fact that I think Emacs is the best text-editing environment on the planet. This post gives a very straightforward but informative introduction to the question of “Why Emacs?”

Video

Derek Sivers’ Speech to Berklee College of Music I have a tremendous amount of admiration for Derek Sivers. While this speech is geared towards music majors, most of his lessons and advice can be generalized to your profession and life in general. There’s a lot of wisdom packed into a few minutes.

Software

Readability is an awesome tool in the fight for a reading-focused, cleanly designed web experience. They started as a browser plugin that strips a page of unnecessary clutter and presents just the text in a clean, visually pleasing format. They’ve released upped their game with a payment model for publishers, a rich web application and a review-pending iOS app. If you read a lot on the web you probably want Readability in your toolbar.