One of my goals for my time at RC was to increase my fluency with the programmer’s toolkit (particularly the text editor and command line). The volume of blog posts detailing developers’ idiosyncratic configuration files is a good indication of how important these tools are. But every time in the past that I tried to implement someone else’s magical dotfiles, I gave up quickly because I didn’t know enough to tweak unexpected behavior. And every time I thought about writing a script to automate some computer task I had to do regularly for work, I was defeated by an impending deadline, and defaulted to the drag and drop convenience of OSX.

Tool #1: A text editor

After watching several RCers do keyboard magic with vim, I wanted to join the club. So I opened vimtutor and got to work. After about a week of getting used to modal editing (which I love) with basically no configuration files, I decided it was time to dive into the world of text-editing plugins. I managed to find some blogposts that broke down the authors’ .vimrc section by section. I downloaded Vundle and the Solarized color scheme, which really is easier on my eyes than the high-contrast, brightly colored, defaults. Over the course of the next week, I gradually added plugins one-by-one. I got over my fear of overriding system defaults in order to make vim play nicely with autocomplete. When I’m not using vim, I miss the fine-tuned movement that it provides. There are some formatting quirks to figure out still - pasting can be ugly (though :set paste makes it better) and the auto-indent settings aren’t where I want them to be. I have to get around to enabling language-specific defaults, especially as I dive more into Python, where whitespace actually matters.

Tool #2: The command line

I’ve spent 20 years as a computer user beholden to the power of the GUI. I’ve gotten glimpses into the awesome power of command line systems. PINE was my primary email client in college because it was so fast. The Athena cluster terminals were always Linux based, and I used the command line to write and run programs for various CS and Numerical computing courses. But in the hours a day I spent on the computer, I used the mouse for everything. RC has been a great time to gradually shift more and more of my workflow to the command line. First, I’m surrounded by people who can help me tweak UNIX commands without thinking, and who can help me retrace my steps if I follow a command that I found on Stack Overflow and it doesn’t work as expected. Second, the cost-benefit calculation of taking time to write a tool no longer figures, since there is no pressure to ship anything.

Tool #3: Git

It is amazing to me just how quickly so many tools have achieved such huge market share in the programming world. Git was invented while I was in college, and I don’t recall ever hearing about it. Now, programmers can’t function without it. It has made pairing on projects a breeze, and has saved me from directories filled with different versions of the same file. I can so easily access the source code for small tools like co.js, which wraps generators and promises together quite neatly (in <100 lines of code) and huge projects like Sefaria, which I’m hoping to be able to contribute to by the end of the summer.

Looking at both of these projects confirms for me what Joel Spolsky says - “It is easier to write code than read it”. I’ve been thinking about why this is the case. One thought occurred to me after reading a blog post that this week’s RC resident, Nathan Marz, shared with us about Suffering-Driven-Development. He talks about how good abstractions emerge from suffering through all of the nooks and crannies of a problem domain. This got me thinking that when you read code, you’re skipping the suffering phase entirely. This makes it very hard to understand the problems that abstractions are coming to solve in a given codebase. In theory, good documentation is supposed to explain these sorts of things. So far, I have found that code is either so condensed that it more or less hides any trace of the original problem, or so huge and spread out amoung dozens and dozens of files that I can’t draw a mental map of the relationship between the pieces of code. I imagine that this will get easier with experience, though I’d appreciate any pointers to exemplary mid-sized OSS projects with accessible but non-trivial codebases!

I spent a fair amount of time these past two weeks worrying about not having a big project to brag about. But after two weeks in which I wrote one or two little projects every day (gradually overcoming my fear of git committment), worked my way through Project Euler problems in vim, and paired a lot more than in the first two weeks, I’m starting to notice subtle shifts in the way I program. The keystrokes are becoming more fluent, I run tests on my helper functions, which saves me tons ot time debugging down the road, and I can more quickly find what I’m looking for in the sea of information. It feels good.