• My experience with minimalism

    Minimalism was always appealing to me. The philosophy of not having more than one would need is close to my heart. Over the past few years, I’ve been “trimming the fat” off various parts of my life.

    I can’t recall when I started being drawn to a minimalistic lifestyle. I think my passion for minimalism originates in my desire for organization and order. It’s comforting to know that a world around me has a certain structure.

    I remember the time when I started living on my own. I just moved to United States, away from my family. All my life fit in a half-empty suitcase at that time. Few sets of clothes, a blanket, a pillow, some hygiene products, a small laptop. Moving to a new place was as easy as throwing few things in that suitcase.

    After some time, I started accumulating more things. A guitar. More variations of clothing. Cheap coffee table and a shoe rack from a dollar store. At that time I rented a room in one of the shady areas of the city. Adding a few pieces of furniture made a place feel like home.

    Time has passed, and I moved again. Left the furniture behind, took the rest. Still light, but I did have to make a few trips to move everything I needed. I got even more comfortable. A gaming PC. Significantly more junk here and there.

    That’s when I did my first big cleanup. I went through every item I owned, and tossed it a trash bag if I didn’t use it in the past 6 month. Old clothes, some action figures, other useless junk I accumulated. As a result, I tossed two big bags of stuff I didn’t need. I still remember the liberating feeling. Knowing that everything I own serves a purpose.

    It felt like I could breathe again.

    Years pass. I don’t rent rooms anymore, but apartments, houses. This comes with having to own more things. Real furniture. A TV. More musical instruments. Having to accommodate guests. Cooking supplies. A bike. Outdoor furniture.

    But I’ve kept the minimalistic mindset, and I still do periodical clean outs. Tossing almost everything I haven’t used in a past six months. Reducing what I own only to things that I need to have comfortable and enjoyable living.

    Today, I don’t think I can fit everything I own in that single suitcase. Hell, I most certainly will need to hire a truck for my next move. But that’s not important. Minimalism isn’t about the absence of things. If you feel like you don’t have enough - you’re probably doing something wrong. Minimalism is about not being excessive.

    For me, knowing that my belongings serve a purpose makes me feel content, clear-headed. It’s comforting. It feels right.

    Sometimes, I forget and start accumulating stuff. And that’s when I go back to reducing again. It’s not an obsession, but a healthy periodical maintenance. Often it takes months, or even years to get rid of certain things.

    Replace a queen sized bed with a Japanese futon mat. Digitalize the growing paper trail I keep. Travel the world for with a single suitcase.

  • Profiling slow bashrc

    I’ve recently noticed that it takes a long time for my bash to load. I’ve found following StackOverflow answer to be useful, and I based my solution to find a startup time hog in my ~/.bashrc upon it.

    First off, add following few lines to your /etc/bash.bashrc, ~/.bash_profile, or wherever you’d like to begin tracing the script:

    PS4='+ $(date "+%s.%N")\011 '
    exec 3>&2 2>/tmp/bashstart.$$.log
    set -x
    

    And add following few lines where you want to stop the trace:

    set +x
    exec 2>&3 3>&-
    

    Now start your bash session (you can simply open a new terminal Window for that). The above will create /tmp/bashstart.<PID>.log. To analyze it, I wrote a little Python script:

    import argparse
    import heapq
    
    parser = argparse.ArgumentParser(description='Analyze bashstart log for speed.')
    parser.add_argument('filename', help='often /tmp/bashstart.<PID>.log')
    parser.add_argument('-n', default=20, help='number of results to show')
    args = parser.parse_args()
    filename, n = args.filename, int(args.n)
    
    with open(filename, 'r') as f:
        q = []
        prev_time = None
        for line in f.readlines():
            line = line.split()
            if '+' not in line[0] or len(line) < 3:
                continue
            text = ' '.join(line[2:])
            seconds, nanoseconds = line[1].split('.')
            time = int(nanoseconds)
            diff = time - prev_time if prev_time is not None else 0
            prev_time = time
            heapq.heappush(q, (diff, text))
    
    for diff, text in heapq.nlargest(n, q):
        print float(diff) / 1000000000, 's:', text
    

    Save it as bashprofile.py, and run it as follows (replace file name with an appropriate):

    python bashprofile.py /tmp/bashstart.2831.log -n 20
    0.050056909 s: _powerline_init_tmux_support
    0.045323022 s: _powerline_setup_prompt
    0.044722024 s: _powerline_setup_prompt
    0.044423727 s: '[' -f /usr/local/google/home/ruslano/.local/lib/python2.7/site-packages/powerline/bindings/bash/powerline.sh ']'
    0.044364097 s: '[' -f /usr/local/google/home/ruslano/.local/lib/python2.7/site-packages/powerline/bindings/bash/powerline.sh ']'
    0.044137159 s: _powerline_init_tmux_support
    0.015839574 s: __shell_name=bash
    0.010850276 s: command which which
    0.010105462 s: PS2='\[\]  \[\] \[\]'
    0.010000598 s: PS3=' Select variant  '
    0.009837956 s: complete -F _svn -o default -X '@(*/.svn|*/.svn/|.svn|.svn/)' svn
    0.009767517 s: PS2='\[\]  \[\] \[\]'
    0.0095753 s: PS3=' Select variant  '
    0.007915565 s: other_utils=(ant automake autoreconf libtoolize make mount patch readlink)
    0.00771205 s: for script in version functions/selector cd functions/cli cli override_gem
    0.007008299 s: for gnu_util in '"${gnu_utils[@]}"'
    0.00693653 s: complete -F _crow crow
    0.006803049 s: complete -F _svn -o default -X '@(*/.svn|*/.svn/|.svn|.svn/)' svn
    0.006672906 s: for script in version functions/selector cd functions/cli cli override_gem
    0.005912399 s: for entry in '${scripts[@]}'
    

    In my example, Powerline turned out to be a massive hog. Looks like I’ll have to troubleshoot the speed or plain disable it.

    Don’t forget to remove the lines you added to your bash configuration files after you’re done profiling.

  • DidYouMean plugin for Vim

    DidYouMean Vim plugin is very simple: it asks you if the file you are trying to open is indeed the right file. How is this useful? Here’s how:

    DidYouMean plugin in action.

    Say you have two files with a similarly starting names: model.py and model_test.py. You type vim mo, you hit tab to autocomplete the name, you hit enter. In vanilla Vim, you’d be opening a new file: model, since that’s where shell’s tab-completion stopped. DidYouMean detects such a nuance and asks you if you wanted to open model, model.py, or model_test.py.

    Simple idea, and instantly after trying this out, I would really expect this feature to be included in vanilla Vim.

  • Lessons learned: engineering productivity

    I enjoy optimizing the way I work: the less time I can spend on something without sacrificing quality - the better. Below are few ideas on the subject of engineering productivity I’ve successfully applied in my career.

    Don’t work long hours

    A fascinating paper was released in 2011 by a group of Israeli researchers, who studied the factors which affect if prisoners were given a parole or not (source: Extraneous factors in judicial decisions.

    First prisoner in a morning has approximately 65% chance of being released. With every next case, the chance dropped significantly, reaching nearly 0% starting with the third case. After returning from a lunch break, odds of a prisoner being released went back up to 65%. And once again, with each new prisoner the odds decline rapidly.

    A graph of favorable parole decisions given by the judges.

    Authors of the paper suggest that making decisions depletes a limited mental facility. People start looking for shortcuts and making mistakes.

    Working long hours is something we’ve all done more than once. Be it an upcoming deadline, fascinating problem, or a personal project. The problem with working too long is that you’re doing a poor job without realizing it.

    I try to avoid working more than 7 hours a day, and there are people who get an incredible amount of work done under an even shorter amount of time.

    This is probably explained by a phenomenon called “ego depletion”: the idea that self-control or willpower draw upon a pool of limited mental resources that can be used up. When the energy for mental activity is low, self-control is typically impaired, which is what is considered to be a state of ego depletion.

    Dangers of burning out

    Another problem with working too long - is a possibility of a burnout.

    A while back I worked as a freelancer for a client of mine. I worked long hours from home office. This was my first time working from home for such a long period of time, and I made a number of mistakes in the beginning. One of which was working too much.

    I’ve put in a number of 12-hour marathons in order to get more work done. I was on call most of the time. I became overwhelmed with all the work I had to get done. I started losing interest in work and feeling like things are getting out of my control. Every day felt like a bad day.

    Those are the symptoms of a burnout. Feeling of life spinning out of control and feeling like nothing you do makes any impact.

    I broke out of a mental prison of a burnout by getting a better work-life balance, enforcing exercise routine, and never working more than 8 hours a day. 7 in most cases.

    Work-life balance

    Another thing I learned from working from home is how to keep a work-life balance. Not having a separate office and living in a 1-bedroom apartment with my wife, I had to barricade myself in a far corner of a bedroom and turn it into a physically separated office space. That was the space I worked in, and it remained empty after I was done and until I started the next work day.

    Work-life balance deserves a special say: it’s the difference between doing an amazing job and going insane. Set aside time and place for work, and never allow a bleed-through. Don’t be on call if you can avoid it. Don’t open or reply to work-related emails at your spare time. Office is for work and home is for family.

    Distraction-free environment

    Everybody is aware that interruptions hamper productivity, but not everyone actively avoids interruptions during work. Replying to a text message, quickly checking your social network notifications, or looking up that one thing you’ve been forgetting to look up for days - all of this impairs your mental ability to complete the task within a desired time frame and, more importantly, with high quality.

    According to various studies it takes from 20 to 30 minutes to get regain the same level of concentration and productivity after a single act of disruption. A 2014 study from George Mason University found that students composed lower quality essays when interrupted only a few times throughout both planning and writing phases. Distracted students performed considerably worse, even though they were given additional time to complete an assignment in order to make up for the interruptions.

    Know your tools

    Use a single editor well

    This is lower level tip than the rest, but something I find utterly important in my daily work. We, the software engineers, spend at least half the time editing some sort of text - code, email, documentation. Taking time to improve the knowledge of the software you use every day pays off.

    • Using Gmail? Learn the keyboard shortcuts.
    • Use Eclispe? Do the same. Search for plugins which can make your everyday work faster and easier.
    • Use command shell for daily work? Practice your shell scripting skills, find the tools that let you do more work with lesser amount of typing.
    • Pick up touch typing. It’s also a part of your toolbox. Why think about keying words in? Lower error rate while typing - you need to go back less.

    For instance, I do all my work in shell. I use Tmux for creating and navigating multiple sessions. I use Vim for all my editing needs - code, documentation, blogging, composing long emails (via Mutt). I touch type, so working in a text mode is easy.

    Over the years I accumulated aliases for all the frequently used shell commands. All the Vim and Tmux shortcuts are a part of a muscle memory. Jumping from file to file or from one place to another within a file doesn’t take any mental effort and is accomplished with only a couple of keystrokes.

    By eliminating the need to think about or spend too much time working with low level concepts - you free up the mental bandwidth for higher level reasoning and problem solving.

    Read, don’t stop learning

    As per DeMarco and Lister, authors of “Peopleware: Productive Projects and Teams” - one book is more than most programmers read each year. This is the same point Steve McConnell’s “Code Complete” emphasizes.

    A lot of programmers don’t read books. A few even don’t follow relevant blogs or websites. Don’t do what software engineers had to do in the olden days: coding by error in isolation from the rest of the industry. Read a book, learn something you don’t know about. A single book read from beginning to end contains wider array of information compared to disjointed articles some programmers limit themselves to.

    As Jeff Atwood suggests in his article “Programmers Don’t Read Books - But You Should”, pick up one of the timeless books - not affected by changing technologies and processes.

  • Gundo tree for Vim

    One of the obscure, but tremendously useful features of Vim is an undo tree. You would expect Vim to have a simple stack for undo and redo actions, but it’s much more complex than that: Vim keeps track of every change you made in the current session, making it possible to access change history beyond basic u and C-r commands.

    Default interface for accessing far out branches of the undo tree leaves to be desired, but that’s where Gundo comes in.

    Gundo tree in Vim.

    Gundo provides an easy to use interface for navigating history branches. In the screenshot above, I am previewing a diff in one of the undo tree branches inaccessible via u command.

    As per author’s recommendation, I mapped the plugin to F5, which seems quite convenient to me:

    nnoremap <F5> :GundoToggle<CR>
    

    Usage is quite easy. F5 opens or closes the undo tree, j and k are used to travel through changes. Enter key applies the changes.