Hardware

13″ 4GB Macbook Pro, circa Oct 2009 – running Snow Leopard and Windows 7, this aluminum savior is the anointed godhead of my development world.

17″ SAGER NP9262 (Clevo D901C) – the Apollo to the Macbook’s Adonis, this serves as my “power incarnate” machine. It wears Windows 7 handsomely, and will happily execute any resource intensive tasks I send to its gallows.

Dell 24″ Widescreen Monitor – Has saved more alt/tab keys than I care to calculate.

Mobile Edge Alienware Deluxe Backpack – it took a lot of restraint to put down my loathing for the garish-boutique-markup-vendor of a company and pick up their product, but Alienware carries one of the nicest laptop bags for bending spacetime to accommodate my 17″ Sager, complete with a bivouac’s worth of pouches and harnesses.

Dell XPS M170 – a venerable hero of bygone days, XPS remains in active service running Windows XP SP3 to surprisingly good effect. Trustworthy and redoubtable, measured as the balance of power and portability, and bearing a warranty that allows me to summon field medics!

24″ iMac – Media and not much else. Media and testing.

Backups

External 1TB Seagate drives – Handles everything from automated backups to disc images to source control. Almost as reassuring as RAID, with a bit more administrative overhead.

Various cloud-hosted SVN/Git repositories – Source control repositories are in my opinion the most natural location to “backup” and “restore” from, be it locally or in magical clouds dappled with unicorn glitter.

Synch between machines – An informal but nonetheless practical backup that comes as a consequence of frequently switching computers.

Software

Firefox – I don’t think I use as many FF plugins as most developers, but those I do I find to be indispensible.

• FireBug – Especially with all the Javascript development I’ve been doing in the last year, FireBug continues to reaffirm itself as one of the most important tools at a web developer’s disposal, and has attained a damn-near-ubiquitous presence in our community.
• Adblock Plus –It turns out that nobody wants to look at ads, no matter how important they are to a stranger’s business model.
• ColorZilla – Pure convenience plugin for ganking color schemes from attractive pages.
• CSSValidator – First step in CSS bug hunting, conveniently in plugin form.
• PageValidator – Another convenience plugin, helps with developing on FF and testing outwards.
• JSONView – Beautifully formatted JSON output a la the colored, indented XML we’re accustomed to.
• FireFTP – Integrated FTP for convenience, though I usually run FileZilla.
• YSlow – I can guess a site’s YSlow score in my head with reliable accuracy now, but it’s still an effective sanity check.
• Greasemonkey – Testing in the browser is *painful* and Greasemonkey eases this pain.

XCode – Getting better with every release, and the 10.6 build made some huge improvements.

Visual Studio 2008 – I don’t do enough .NET work these days to upgrade to 2010 yet, but VS remains my favorite IDE on account of its richness and excellent debugger. I still open it on a weekly basis for the Javascript debugger alone.

NetBeans – Probably the most used and abused software on my system after the browsers, NetBeans is a like a whole pantheon of gods for platforms I’m working with and has rightfully become my daily place of worship.

TextMate – A solid “DE”, it’s proven itself quite serviceable for Rails development with a earnest, supportive community striving to ensure, say, that we never run out of attractive color coded themes.

Mac Terminal– CLI power is liberating and arcane and productive like six days of God!

Photoshop CS4 – as only an amateur digital artist, I gravitate to Photoshop not for its power but because of the wealth of instructional information available. I started using Photoshop 4 in high school and the mostly awful Adobe has kept me as an impressionable customer since then.

Paint.NET/GIMP – Perfectly serviceable alternatives to Photoshop that I’m starting to come around to more and more. My GFX program of choice now depends on whatever computer I happen to be using.

MS Excel – The best software ever published by Microsoft and consummate spreadsheet tool. I use it daily in one sundry capacity or another.

Cygwin – For terminal goodness on Windows.

HeidiSQL – Stable, quick, lightweight database interface that just works and never hangs.

FileZilla – I’ve been using this for longer than I can remember for all my FTP transferring needs. If it’s not the best of breed, I wouldn’t know because I’ve never had a complaint that pushed me toward its rivals.

Git/msysGit – The DVCS of the gods; and mortals too, since this is probably one of the biggest software influences on how I work that I’ve adopted in the last few years.

SVN/Tortoise – And yet I also maintain a lot of older and perfectly operable Subversion repos, for which Tortoise is winning interface, though I find myself using SVN more for document management these days than code versioning.

TiddlyWiki – A potent cocktail of brain map, getting things done, project management, scratch paper, and other assorted miscellany that I’ve tried everything from MS Notes to .txt files to manage. TiddlyWiki is my ideal implementation of this bizarre, nebulous workspace.

KeePass – Everyone has a password manager, and KeePass is ever-sagacious gatekeeper to whom I entrust the keys to my world.

Truecrypt – Excellent security, and comforting fixture of my life the more and more I find myself traveling abroad.

PuTTY – For when I must adventure into the frightful lands of Telnet.

Growl – Eternally straddling that line between informative and intrusive.

Jing/Camtasia – For recording demos, screencasts, tutorials, whatever.

Adium/Digsby – Covers 99% of my communication needs.

Skype – And of course, Skype is the other 1%.

Hosting

Dreamhost – A compelling balance between affordability and “unterrible” support, even if the servers are habitually slow. Serves this blog and some other middle-ground needs of mine.

1and1 – Still hosting here due the uncompromising mediocrity of a company whose servers have never been worse or better than “okay”.

Pair.com – Most responsive technical support I’ve ever received from a hosting company.

Heroku – I’ve taken to pushing all new Rails applications I’m building over to heroku, both professional and personal. So far I’ve been very, very, very happy with everything from one-click deployments to their knowledgeable staff.

It’s that speed which can be worth a million dollars, or at least perhaps, seek and destroy eleventh hour bugs, ship a feature that’s been dropped for time, or make weekend projects feasible. High level productivity gains come from engineering and design decisions and are sustained through appropriate project management. The subject has earned the thoughtful analysis of countless technologists and programmers, but it usually stops short of the visceral fact that the sheer intensity of relentless programming can – in brute, anarchic glory – make more of an impact at the end of the day than any defensive design and planning. Code must be written, and no architectural optimizations can abstract that away.

I don’t want to dovetail into a blissfully approving flight path of crunch times or task-mandates that doing it right now is more important than doing it right. But that’s no reason not to celebrate a corner skill in our profession which everyone seems to possess at a demonstrably different level. And that’s certainly no reason to avoid overexerting ourselves in exercise, given that once we’ve grown accustomed to a hurried pace it becomes easier to apply in everyday affairs, to enter rush mode at will, to let the mind drift to planning while the fingers type the work.

So what are some ways to become a faster programmer?

Programming Competitions

More of a strategy than a tactic, willfully committing yourself to short, intense programming sessions over the weekend where you’re galvanized by the thrill of competition and the taste of an immediate product has got to be one of the best (albeit unscientific) ways to improve your programming speed. It’s not so much about learning tricks or practice, but personally acquainting yourself with a philosophy of frantic, obsessive concentration on publishing a small deliverable.

The scope is about right for these competitions to allow for focused programming with little worry of feature creep, reevaluations of design as complexities are uncovered, or the many other thoughtful distractions which constitute the larger role of development.

Words per Minute

The core virtue of fast programmers is lightning typing speed. You can’t peck aloofly at the keyboard, but must violently hammer away as if zombies were attacking your office and your life depended on completing a block of code before the barricades break. Youthful vigor counts for a lot, but so does unrelenting discipline.

Snippets and Generators

Most IDEs now have tools for managing code snippets and/or powerful template generators. Identify the handful of code you’re repeating most often – say, accessor methods – and write a snippet for it. I’ve only found myself writing perhaps 2-5 snippets at most, almost always to make up for shortcomings in the syntax and idioms of the platform I’m working on.

Hotkeys and Text Expansion

Similarly, dedicate yourself to learning the hotkeys of the environments you’re working with; print up cheat sheets and forbid yourself from using the mouse to perform actions with a known hotkey. Embrace mouseless computing.

Text expansion/intellisense/code completion is a special subset of productivity located in the mouseless computing paradigm, and the quicker you can type through heavily parameterized function calls the further you’ve risen above the limitations of verbose languages, libraries, APIs.

Head Programming

The quickest way to program is to embark with firm goals and implementation plans, programming the project in your head before you ever touch the keyboard. Formal specs take too long and impulsive programming leads to wasteful back-stepping, so the idea is to develop a balanced mental tour that gives you just enough context and boundaries so that, at any given point as you code, you’ll know what precisely what the next step should be.

Sub-Machine Guns

Prolonged white-knuckled programming is an unsustainable weapon in the developer’s arsenal, and must be used properly. By properly I mean “like a sub-machine gun”: sustained fire in short, controlled bursts. With ass on seat and fingers on the keys, dump as much code as possible onto the screen, but stop periodically to cool down and re-aim. The pause is only to gather your resolve for another assault and it mustn’t last long, merely long enough to ensure that you’re hitting your target and to crack your knuckles.

Mock Code

Building and propelling momentum is at the heart of fast programming (and, for that matter, entering the fabled “zone”). Anything that kills this momentum, even as a necessary evil, should be avoided. If an implementation detail is threatening to arrest your speed, abstract the offending code and push if off into some stub to be revisited later, preferably while waiting for a compile or test suite to run.

Working code is paramount when you’re racing the clock, and if you can defer some unexpected analysis until later, so much the better. My assumption is that a mocked feature now with full supporting code is better than uniformly functional but incomplete code. Yes, even magic numbers are better than putting on the brakes.

Code on the Side

Every second is precious, and we regularly endure brief moments of inopportune downtime while we compile the code, deploy it, launch the environment, run tests, transfer files, and so on. Always keep some code on the side to jump to and from during these lags. It must, of course, be the sort of code amenable to quick modifications, and requiring only minimal effort to mentally reorientate to and resume. There are always edges of a project like this, however, and the trick is strategically saving them to fill in otherwise unproductive gaps.

My sense from reading various blog posts and git repos is that most people factor such logic out of the controller, which at least consolidates the complexity further upstream, and then resort to a variety of Ruby syntax and Rails convenience methods as required by the query. This is the approach I’ve always taken, and because I don’t think there is a better way to generalize the solution that isn’t already represented in the framework, I’m posting an example finder method as a sort of syntax reference.

What follows is a pretty typical case. This method is using searchlogic, geokit, and acts-as-taggable-on, as well as named_scope and some basic pagination. Ruby’s Hash is the real hero here and gives us most of the tools needed to keep such methods readable.

class << self
   def find_with_options(opt={})
   opt = opt.slice(:tags, :search, :sw_lat, :sw_lng, :ne_lat, :ne_lng, :limit, :offset)
   conditions = {}

   unless opt[:sw_lat].blank? || opt[:sw_lng].blank? || opt[:ne_lat].blank? || opt[:ne_lng].blank?
            sw_point = GeoKit::LatLng.new(opt[:sw_lat],opt[:sw_lng])
            ne_point = GeoKit::LatLng.new(opt[:ne_lat],opt[:ne_lng])
            conditions[:bounds] = [sw_point,ne_point]
   end

   conditions[:limit] = opt[:limit] ||= 50
   conditions[:offset] = opt[:offset] ||= 0

   scope = MyModel.include_an_associated_model
   scope = scope. associated_model _name_like(opt[:search]) unless opt[:search].blank?
   scope = scope.tagged_with(opt[:tags], :on => : tags) unless opt[:tags].blank?
   scope.all conditions
   end
end

The problem for me, at least, is that I can’t turn the compulsion off. It sits right below my consciousness, urging the brain, when given a system, to seize upon the most elegant paradox it detects for solving the problem at hand. Take, for example, polymorphic belongs_to associations with accepts_nested_attributes_for in Rails. Any two of these keywords in combination will turn up tales in the SERPs of bewilderment and errors, but the effort to solve a data modeling problem brought these three elements together in a perfect storm that would punish me for my inspiration.

So I’ve one model, which then belongs_to another, polymorphic, model. The belongs_to model was the workhorse of the pair, and therefore needed to accepts_nested_attributes_for in order to initialize its counterpart as required.

class BelongsToModel < ActiveRecord::Base
   belongs_to :polymorph_model, :polymorphic =>true
   accepts_nested_attributes_for :polymorph_model
end

Unfortunately, what appears to happen when one puts this design into practice is that a NoMethodError is thrown whenever the belongs_to model receives the nested attributes hash, e.g.

params = {
   :name => “blah”,
   :parent_type => “polymorph_obj_class”,
   :polymorph_model_attributes => {
      :info => “blah”,
      :details => “blah”
   }
}

@belongsToModel = BelongsToModel.new(params)

In the example, polymorph_model_attributes is constructed with the attributes “info” and “details” because I personally have the domain knowledge to know that those attributes belong to the polymorph model and should be provided. To process nested attributes, however, Rails needs to know this also so it can use that knowledge to add an appropriate build method (called something like ‘build_polymorph_model ‘) to the belongs_to model, and initialize the nested object whenever the belongs_to model is initialized.

The paradox arises because Rails cannot dynamically create a “build_polymorph_model” method without first knowing the class of the polymorph. Even passing in a parent_type or equivalent attribute will not provide the model with the foreknowledge it needs to build this helper method.

Any alteration to my data model would be enough to escape the conflict, but this uncomfortable relationship with belongs_to and the need to instantiate my objects from the direction of the belongs_to model came about because it really does best represent the schema behind the scenes, and so I was loathe to surrender it to the apparent constraints.

The solution was as simple as possible. I took a literalist approach, and went ahead and defined the build_polymorph_model explicitly myself, adding in the appropriate logic to initialize any one of the several possible polymorphic models that could be associated.

class BelongsToModel < ActiveRecord::Base
   belongs_to :polymorph_model, :polymorphic =>true
   accepts_nested_attributes_for :polymorph_model

   def build_polymorph_model(params)
      # build any supported polymorphic relationships here
   end
end

Adherents debating the styles travel parallel roads in the direction of improving maintainability, but take opposing paths (and tend to toss aspersions across the median). Comments depart from reality over time and are perhaps redundant by nature, while self-documenting code is a frequent vanity and incapable of reflecting the many levels of abstraction that constitute design. I think a good way of realistically traveling these issues is by practice, and naming your branch conditionals (the subject I raise this very moment!) is a modest but noble idiom suitable for any lounge in solitude or with a cordial in hand.

Branch conditionals are important thing to name right because they’re all but the core flow of your code and you’ll be reading them over and over again in the repetitive quest for understanding, and its more senile relative, recollection. Branch conditionals (usually) look like this:

If (x && (y = (d  ? a : b) || y < e.p() ) )
{
blah();
}
else if (t.F() && g == q[0])
{
meh();
}

A far more readable and self-documenting way to formulate the code would simply be:

var isThisThingAndAlsoSomethingElse = (y = (d  ? a : b) || y < e.p() );
var butThatCouldAlsoBe = t.F() && g == q[0];
If (isThisThingAndAlsoSomethingElse )
{
doThis();
}
else if (butThatCouldAlsoBe)
{
doThat();
}

I find the separation of the comparisons from their consequences to save hundreds of milimoments of thought when working with code. Like most advice, it’s quite simple, and nobody follows it. The highest value can come from small optimizations like this, and collectively, when I scroll through source code with a lot of named booleans I read it that much faster than short files with pithy dents of anonymous conditionals.

In fact, I find this simple idiom useful enough that if I were granted one wish about all the code I’m to read before I die, well, named branches would be the second after the simple demand for thoughtful, verbose variable names, of which named branches is a like subset to begin with so it’s reasonable several times over.

A fortunate byproduct this practice is that naming branch conditionals can sometimes be hard, a fact you should use as a chance to articulate your logic. Choosing a name can also be a useful secondary measure of code smell, or suggest method refactoring, or reveal problems with business logic, and what’s more it’s a further refinement in this world of programming where nouns and verbs are given descriptive titles yet filled with murky details.

So what you have is self-documenting code because it reads like a comment, and it must read like a comment in order to express a more or less complex branch conditional. At a higher level, idioms like this are showing up in a lot of other places like Domain-Specific Languages and advice on naming tests, which are arguably just a branch conditional at heart themselves. What that suggests to me is that it’s a useful detail for programmers to orientate to.

Benefits: readability; passive analytical tool; DRY.
Costs: verbose; antagonizes our instinct for quick and clever over clear.