How to Not Suck (at Being a Programmer)

November 4th, 2013 about shells, vim, git, and regex

One of the lamest features of being a programmer is the overabundance of trivial tasks that are just plain boring and time-consuming. Fortunately, our craft lends itself very well to enabling laziness: not in a negative sense, but rather, a productivity-boosting, awesome sense. Traditionally, renaming a set of 5000 files to conform to a new naming convention (eg converting .JPG to .jpg) would take a tremendous amount of effort and an equally tremendous amount of forever. By being lazy, a programmer can expend a miniscule sliver of that effort and time to write a simple script that automates the whole process.

Update: even easier than I thought.

I'm a big fan of being lazy, so here's a bunch of tips to help you become a big fan of being lazy!

Shells

Learn to love terminals / shells and the incredible power and flexibility they offer you. A GUI cannot compete with a shell when it comes to raw power, extensibility, flexbility, or anything else that actually matters. Furthermore, there may be situations where you're confined to only a terminal and can't access a GUI. Knowing how to manipulate a shell is an incredibly understated skill in the programmer's arsenal.

Text editors

Use a real text editor. That means one that works through ssh, without a window manager. That means you need to get used to using a terminal. If you disagree with me on this point, that's fine, and I respect your opnion, but you're wrong and I hate you. GUI text editors get a few pretty features that a terminal editor simply can't support, but in the long run, they pale in comparison when it comes to features, power, and flexibility. Notice a theme here?

Regular Expressions

Regular expressions are like find-and-replace on mega steroids. I can't even count the number of times I've seen another person poking around a file, replacing a dozen function calls with a similar but slightly different function call. Not only is this a totally anti-lazy way of doing things, but it's error prone: one poor function call may go unnoticed and remain unchanged, leading to headaches for future you or future maintainers.

Version Control

This is the most important of all the things in this list. Everything else on this list is possible to argue against, but no one in their right mind would argue against using version control. Not using version control is completely imbecilic and unprofessional. Version control acts as a safety net against accidental hardware failures, file deletions, explosions, etc. Beyond that, it provides a whole host of awesome features that you should want to use anyway: easy collaboration, quick changelog summaries, project histories, systems to test new features or experiments, and more. Use version control or go home.

Hisss

November 1st, 2012 about git, programming, and python

I've always been really interested in learning Python. Its clean syntax and use of whitespace to delimit code blocks has always been very appealing, and the incredible amount of positive feedback I've seen about it is impressive. I've dabbled with it a few times, but never enough dabbling to solidify its semantics in my head. I even tried porting this web site over to Django once, but I ended up losing motivation because of the brand new learning curve (like Vim's, it was intimidatingly steep). Recently, however, I decided to make a terminal-based to do list and plunged right into it with Python. In the very beginning I was having difficulty handling the command line arguments properly, so I was tempted to switch to a more familiar language like PHP. In spite of PHP's calling, I knew I'd never learn Python if I just kept quitting in favor of a more familiar language, so I stuck with it.

Man am I glad with that decision. After getting the arguments sorted out and actually getting into the logic of the system, I was blown away with how simple and expressive Python's syntax is. It's amazing how concise and readable everything is and how easy it is to create beautiful, easy-to-read code. Control structures are concise, formatting is simple, and complicated operations are reduced to simple expressions. Tasks that are cumbersome in other languages are made trivially easy with Python. For example, checking if the string "Whose cookie is that?" (stored in the variable bigstring) contains the substring "cookie" done in multiple languages:

LanguageCode
C strstr(bigstring,"cookie") != NULL
C++ bigstring.find("cookie") != string::npos
PHP strpos($bigstring,"cookie") !== false
JavaScript bigstring.indexOf("cookie") != -1
Java bigstring.contains("cookie")
Python "cookie" in bigstring

It's not even a contest on which language is the most compact and readable. Of course, this form of succinct syntax, along with its whitespace-delimited code blocks, can be a source of confusion for people more familiar with other languages. For me, and I would imagine most people, especially those new to programming, this type of syntax is easy to pick up on and assimilate into. This was also one of my first real experiences with Git, pushing me even further out of my comfort zone. I'd been using Subversion for almost a year and was pretty content with how it had turned out for me, but I couldn't ignore all the Git + GitHub hype going on in the internets. Another satisfying decision, as Git is incredibly powerful. I'm not nearly experienced enough to describe all its advantages, but a quick Google search should explain it fairly well.

My command-line to do list

October 27th, 2012 about git and python

In an effort to improve my personal task management / organization and my Python, I've been writing a command-line based to do list. I based it heavily on todo.txt and Steve Losh's t, but with my own little twists and ideas built into it. It's my first real experiment with both Python and git/github, so I'm learning as I go and hopefully making a usable product for people other than myself. You can check out all of the details over at the github repo and even fork it or something funny like that.

GitHub!

October 20th, 2012 about git

I just made a GitHub. Right now I only have one repo with my .vimrc and .bashrc sitting around in it, but I'm gonna start using it for all of my demos and projects.