[Pruitt-Igoe’s] 33 buildings were torn down in the mid-1970s, and the project has become an icon of urban renewal and public-policy planning failure.

After listening to the podcast, you come away with the impression that this isn’t a fair assessment. It was built at the beginning of the White Flight, in a part of the city that saw a decrease in population, not the projected 100,000 every decade increase that was forecasted. These and other issues contributed to it turning into the very thing it was trying to prevent: a slum.

The building is considered the example of the failure of Modernist architecture as it applied public house, but if you view it in the context above you can see that there are many external factors that contributed. It’s easy to pick one particular piece of the puzzle and lay the blame on that for the failure. It’s much harder to try and understand the complex relationship around what caused the issue.

Applied to Programming

This type of logical error is present in many (not all, but many) of the conversations about what framework or language to use, what methodology should be adopted, or even where to found your startup. It’s easy to point to one success or failure and declare “X is why Z happened, so if I want to duplicate Z, then I must/must not do X.” This type of cargo-cult behavior is dangerous and should be guarded against.

Yesterday I tweeted this:

Whoa! JustinTV is moving from #rails to #django. I’m telling ya, Python & the web with a little Django mixed in is about to blow up.

It gives the impression of just that type of “Y leads to X” kind of thought process that I’m against. To clarify, I whole-hearted expected what kvogt wrote when explaining why they’re moving to Django. To paraphrase: “it just makes sense right now to be on one platform.” Justin.tv isn’t going to suddenly take the world by storm after moving to Django any quicker than they would have if they had moved their Python backend to Ruby.

That said, I stand behind the final point of that tweet. There are tons of shops using Python and Django that aren’t vocal about their use. Python is powering business logic that runs on servers sending me music, tracking my location, displaying my news, and a whole host of other things. Python can do everything low-level system tasks to scientific and financial analytical calculations to high-level business logic for websites and everything in between.

I can’t help but thing there’s going to be more Justin.tv-style announcements this year: shops standardizing on one language and that one language being Python.

From local testing, it appeared that there was some sort of selective filtering happening at the server level on PyPI that was causing our tests to fail. All of our tests in the CI environment follow these tests:

• Install all of the development requirements with pip install -r requirements/dev.txt
• Install the local package
• Execute the tests using fab test

I could follow these steps to the letter locally in a fresh virtualenv, but the second they hit the Travis-CI server they would time out while trying to install everything. We’ve seen similar behavior at the Tribune when we roll out new servers. PyPI appears to be up, but installs fail due to timeouts.

Once I confirmed this, I started looking at alternatives to pypi.python.org as our main index for testing. My initial thought was to have a dynamic server that would act as a proxy to PyPI and cache everything locally. This requires the least amount of work long-term—assuming the server stays up. The problem was that nothing worked quite the way I wanted. The closest I found was collective.eggproxy. It felt a little odd and wasn’t very configurable without going the Paster route, so I decided to fall back on basketweaver.

Basketweaver builds a static index suitable for using with pip via the --index-url option. It takes a directory of files, then generates the HTML that pip can scrape to determine if the package exists. This HTML can be hosted anywhere that can serve a static HTML page, such as GitHub Pages.

Working with GitHub

There’s a few hoops to jump through when deploying to GitHub Pages. First, make sure you include an empty .nojekyll file. GitHub assumes everything you want to publish is in Jekyll, but this file tells GitHub to not parse your files.

Next, and I can’t count the number of times I’ve done this, GitHub Pages doesn’t give you directory indexes. Basketweaver generates its index in the /index/ directory so you can’t hit the plain GitHub Pages URL and expect to see anything more than an error message. Make sure to add the /index/ after your GitHub Pages URL to view the it once you’ve published your changes.

The next thing I do is rework where basketweaver looks for files to build the indexes. I really don’t want to look at a full directory of files at my root directory, instead I want all of the files stored in the creatively named ./files/ directory. Basketweaver installs a file called makeindex which I can never remember, so I created a run.py file that remembers it for me.

The last thing to do is to use the newly created index when installing packages. For Armstrong, we do this with:

pip install -i http://armstrong.github.com/pypi.armstrongcms.org/index/ \
    -r requirements.txt

I haven’t gone to the trouble of setting up a CNAME for pypi.armstrongcms.org yet, so we’re using the main github.com-based address.

There’s one final gotcha: PyPI uses routing that treats http://pypi.python.org/pypi/South/ and http://pypi.python.org/pypi/south/ as the same URL. That’s why pip install Django and pip install django both work even though the former is the correct package name. The URL spec is ambigous as to whether this is correct, but most web servers are case sensitive, including GitHub Pages.

This will get you if you have dependencies on packages that don’t use all lowercase names, such as South, Fabric, or Django. All three of these are dependencies of Armstrong. The fix is to make sure that your install_requires and requirements files have the correct case. The easiest way to determine this is to look at the output of pip freeze and make sure you’re using the same package name as it generates.

Conclusion

At the end of the day, this keeps our tests from being held hostage whenever PyPI goes on the fritz or starts randomly filtering requests as it seemed to do this past week. All that said, we’re still borrowing other people’s infrastructure. GitHub had a little blip while I was writing this post, underlining that you get what you pay for.

While you can use Basketweaver and GitHub to create a mirror of sorts for your packages, make sure you control the infrastructure if its mission critial that everything always stay up. That, or pay for it so there’s someone to call when it goes down.

One such tool I’ve started using extensively while writing my latest book is Notability. It’s a note taking application that let’s you import PDFs that you can write directly on top of. This is important because I can’t see the typos from within my text editor.

Switching environments when switching tasks is an important concept I picked a while back. For me, that switching comes when I build the book and switch over to a PDF version on my iPad to read it. With Notability, I can take the PDF version of my book and change rooms or sometimes just turn the chair around away from the desk, and switch into “editing” mode.

I’m not alone in using an iPad for editing. I hadn’t found an app that worked well for note taking though, so I often switched back to my text editor to write notes. Having to mentally switch context back and forth and back and forth as I physically switched devices hurt my productivity. Being able to do it all in one app has made iPad editing much more feasible.

Once I’ve finished an edit pass and have a whole slew of changes to make, I switch back to my computer with my iPad close by. Notability lets you change the color of the pen you use, so I swap it out for green, and slightly larger for impact, then start slashing through all of the red as I mark edits off. The satisfaction from marking something off with a physical slash can’t be overstated.

I’ve been using Notability for about a month now and don’t know how I managed to edit without it. I highly recommend it if you have an iPad and are doing any type of writing/drafting work.

Question for the Reader

I’ve been considering a series of short posts like this about tools that I use and how they fit into my work flow. I love to watch people work and see how they interact with their systems, though. Is this something that interests you?

You’re probably wondering what Armstrong is doing there with all of this talk of Ruby. No, I didn’t rewrite Armstrong in Rails last night. No, I didn’t convert all of our fabfiles over to Rakefiles either. Instead, I subverted it from within.

Travis CI uses a .travis.yml file for all of its configuration. There are two key fields that it gives you that let you do fun things with it: before_scripts and scripts.

before_scripts runs before anything starts. It’s like setup in the xUnit world, but for your whole environment. Each of the Armstrong components ships a requirements/dev.txt file, so I tell Travis to do a pip install -r of that during setup. That’s right, Travis CI has pip installed!

Next, I’ve set the script to use our test runner, fab test and we’re set. I had to add a few environment variables to turn off our coverage reports—they don’t provide much value when there’s no one there to view them—and we don’t need to do a re-install like we do on a local environment.

You can see this in action by checking out the current build status for the armstrong.core.arm_wells component here. Here’s the .travis.yml file’s contents:

rvm:
   - 1.9.3
before_script:
  - sudo pip install -r requirements/dev.txt
  - sudo pip install .
env:
  - SKIP_COVERAGE=1 SKIP_INSTALL=1
script:
  - fab test
notifications:
  email: false
  irc:
    - "irc.freenode.net#armstrongcms"

There’s work happening to bring native Python support. Native support means being able to test against multiple versions and such. Be sure to check out the #travis channel on Freenode if you’re interested in helping out.

It generates this output when run with --spec:

I’m using test cases like this throughout my upcoming Programming Node.js book to test output of some of the simple scripts.

Yes, I know you can get some amazingly expressive test cases in other languages, but I dare people who say that JavaScript is any ugly language to find fault with this bit of code.

Today marks the 50th straight day of pushing code to GitHub. My work on Armstrong has made a lot of this possible—it’s easy to push code when you’re getting paid to write open source software—but not every day has been Armstrong related code.

During the course of the last 50 days, I’ve rediscovered a few things that I want to share, in case anyone else thinks that they can’t possibly do this without changing jobs.

Keep it small

I’ve written about manageable chunks in writing, but not in contribution. It’s easy to make excuses about why you aren’t pushing code on a daily basis. You need to clean the code up; its not good enough, yet; or it’s not really significant enough to make a difference.

Excuses. All of them.

Every single piece of code you write has importance. Otherwise you wouldn’t write it. There are exceptions to this rule, but those are outliers. Most of the stuff you and I would write and go to the trouble of committing is going to be useful to someone.

Case in point, earlier this week I helped add some interactivity to a timeline on the Texas Tribune. My contribution was trivial, but it might be useful to someone trying to do something similar, so it’s up on GitHub.

There’s always something

There is always something you can do with 5 minutes. I’ve made a lot of contributions to bash-it. Think of it as your terminal on steriods, with pretty colors. I started out with some minor tweaks, then found some places where code could be better handled, then other devs built on that, and I’ve started refactoring some other parts.

I spend the vast majority of my time looking at a terminal, so it needs to fit like a glove. Working on bash-it means I’m getting more and more familiar with my environment and making some pretty cool enhancements.

Find something that you use, something that would make your life a little bit better if it just had X, then go to town and try to figure out how to do X in it. My bash programming sucks. Seriously, I wouldn’t know where to start to write a real bash program, but I can muck around in the internals and figure it out. Just because you don’t know how to program in a language doesn’t mean you: 1) can’t, 2) shouldn’t, 3) aren’t fully capable of figuring it out as a smart human being which I know at least some of you are.

Just start

It’s really easy to get part of the way through a month and say “oh, I’ll start the first of next month.” No. No you won’t. Well, if you’re me you won’t. I have a horrible tendency to want to go big or go home. Not necessarily a bad thing in and of itself, but not good for just getting shit done.™

It’s especially bad when “going big” is “I’m going to commit code every day in a month” and you’re already into an existing month. Then ya wait and you lose that initial momentum.

So the answer for me is to just start. The raw #s are what matters. Get out there, do something, start tallying it up.

Vagrant + Puppet + pip

I initially wanted to create a full build-script inside Vagrant that could be used to setup the entire environment. I used puppet to start the process and found the puppet-pip provider so I was even going to be able to install Armstrong easily. Or so I thought.

There’s something that is happening when puppet runs pip that causes the installation to fail. I’m a big subscriber to select not being broken, but in this case I think there’s some odd in the combination of pip and puppet. The reason is that pip install armstrong via an ssh connection to the same virtual machine works. After briefly discussing it on #pip on Freenode, I opened ticket #298 which outlines the issues we ran into.

I finally decided to go the pragmatic route. For the time being I have a box that’s installed the way you would if you had a raw box yourself. It’s not ideal, but our new armstrong box (warning, that’s a 500mb download) boots up with everything you need to start playing with Armstrong.

Eventually, either I’ll figure out what the issue with pip+puppet is or I’ll switch to some other method that will work. My reason for picking puppet was pretty simple. The provisioning section of the getting started guide for Vagrant shows you puppet code and says essentially “Chef it too complex to simply show you how, so just use this prepared stuff.” I like simple. Right or wrong decision, I’m not 100% sure yet.

Django Server on Bootup

The server runs on startup thanks to upstart in Ubuntu. As far as Ubuntu is concerned, Armstrong is now a service that can be started and stopped with start armstrong, stop armstrong, and so on.

Upstart works on the concept of events. Different tasks emit different events that other tasks can be configured to react to. There’s a startup event and a net-device-up event and so on. I tried all manner of combinations before it dawned on me, the VM is booting, then Vagrant is mounting the NFS with the project.

Once I figured that part out, this recipe helped get things started. A quick task that starts monitoring for the config/development.py file that is mounted after booting was all I need to get runserver_plus going on “bootup”. You can check out the upstart scripts being used in the repository.

I chose runserver_plus from django-extensions rather than the built-in runserver because of issue 15880. Since I’m starting the script on start up, there’s no interactive interface and the watcher gets a little wonky. It works out though, because you get the awesome werkzeug debugger for development.

Closing

Minus a few oddities in the process, I’m really pleased with the end result. It should be noted that this is meant for development only. As we near our first stable release later this year I hope to be able to create another box that’s more deployment ready, but hopefully this will get you started down the right path.

I gave two talks this year, both on Git. Both talks went well, but my advanced Git talk needs some tweaking so I can get it in at an hour. I always plan too much material when I first give it, so it needs a little more taken out.

As promised, I am going to get both talks online over the next week. Each of the repositories we walked through in the advanced talk are going to be posted to GitHub in their “before” state that you can play with them. They also include README files that explain what you’re doing and how to do it.

I’ve already posted my amending and rebasing repositories. You can search my github for pres. to see all of the repositories. I’ll post again once I have them all up.

One of the more interesting evenings this year was a late-night hackathon that involved two 5 gallon kegs from Jason Sweat’s personal stash. I went to bed early’ish, but got this image emailed to me around 1:30. I’m told whiskey fueled its creation. :-)

Or if you’re geeky, you might want to subscribe to my armstrong feed but don’t like the automagical discovery. In that case, just add /atom/ to the end of the URL and you’ve got your RSS feed.

Ok, time to fess up. Nobody’s actually asked for it, but since moving over to the new site last year I’ve only had one feed. It’s been a sore spot and I’ve censored myself on my blog feeling I need to keep it cohesive. Screw that now.

There’s all manner of bugs that have been reported, but no amount of tweaking my environment variables worked. Some time during the process, Xcode 3 finished installing and all of the sudden things started working.

My guess is that Xcode ships with X11 which is needed for xterm-256color to work, although I’m not planning on uninstalling just to see if it works. At any rate, if you’re having issues with 256-color mode in iTerm2, check to make sure you have Xcode installed.

As I write this post, Twitter’s ever-unreliable updates counter is showing that I have 9,999 tweets. It’s time for a Twitter Timeout.

Why? I’ve found myself thinking too quickly, without depth, mostly in the form of 140 characters. I want to get back to my place, my blog.

I’m tired of playing in other people’s backyards, as it were. A large part of my interactions with the world are through Twitter and Facebook, two things I don’t own. My blog, my email. Those are mine. Until the Internet gives way to some bastardization of itself in the name of safety, security, or the God-forsaken “user experience,” it will always be mine to give and not at the control of some private entity.

So, I’m shuttering my Twitter account for a little while. I’m not sure how long, but I won’t be responding to any tweets or reading Twitter for a little while.

My contact information is amazingly public (it’s in the sidebar), so there’s no shortage of ways to get in touch with me. Feel free to.

I had been kicking around the idea of writing a book on Node.js and decided to use this as an opportunity to see what I had to say on the topic. Turns out that I had about a hundred and fifty pages worth of material.

I’m lucky enough that Pragmatic has agreed to pick up the book, so I’ve got a solid base to build out the tentatively titled Programming Node.js. This post isn’t a book announcement though, it’s about the process.

Why I did it

This past month was mostly for my own benefit. I was certain I could get into a rhythm and turn out a lot of material. My last book took a lot longer than I originally planned and came really close to not happening.

I’m not the first author to find himself behind schedule and feeling like there’s no way out, but it was the first time it happened to me. PragProWriMo was my chance to prove to myself that I could get some serious writing in.

Lessons learned

I’ve got three big take aways from this experience. First, the power of doing first, then talking about it. Second, the power of periodization in sports applies to mental tasks. Third, streaks are powerful incentives.

Actions build more than words

Earlier this fall I watched this talk at Ted from Derek Sivers about goals. The gist is that you shouldn’t talk up you idea, you should just do it.

Studies seems to show that you get the same mental reward from talking about your goals as you do for actually achieving it. I’ve had plenty of ideas fall flat after really talking them up, so I decided to try this tactic and see how it panned out.

That’s not to say I didn’t talk about it at all. I participated daily on the forums posting updates at where I was in the process. I did make sure to not talk about what I was doing though, it was just the end result.

I never made any grand announcement though. There was no blog post claiming I was going to write every day of the month or that I’d finish the month well over half way through a shitty first draft. I just did it.

Periodization: it’s for more than sports

The second lesson was more subtle, but obvious to me in retrospect. I could have written more on any given day than I did. I ended just about every day midstream, but that was fine. I left those ideas sitting there waiting to be explained.

Picking up where I left off was easy. There was no need to figure out what was next. I didn’t have to ramp up and there was no fighting that feeling of being spent. Like I said, this is obvious with the benefit of hindsight. It’s one of the core principles of training.

For those of you who don’t know me that well, I used to be a pretty competitive mountain biker. I spent a few years racing and one of those was spent all over the southwest racing at national events. I wasn’t amazing. I was consistent and faster than a lot of people, but I dove into the process of training. I picked it apart, tried to understand everything, and came away with what I believe is a pretty solid understanding of the fundamentals that underly training as an endurance athlete.

One of the main principles is that you never want to leave it all out on the trail unless it’s a race. You want to end each day with something left in the tank. It’s counterintuitive at first, but the reason is simple. You’ve got to ride tomorrow. And the next day. And the next day.

You get faster by slowly ramping up the pace and the miles, and rarely draining yourself down to zero. You can’t recover quickly enough to get the next ride in when you do that.

I made a conscious decision to limit myself to two pomodoros a day, or roughly an hour of time dedicated to nothing but writing. Keeping the commitment small was key to my success. It kept me from getting burned out and ensured that I was still enjoying the process every day without over doing it.

Keep it going

The final piece is the streak. Today marks the 42 straight day that I’ve written or worked on my book. I’ve spent the past few days converting it from ReStructured Text over to Pragmatic’s internal markup, but I count those as days of work.

I probably could have spent a few hours over the weekend and knocked it all out in one sitting, but I wanted to keep a steady pace so I could keep the streak up. Today marks the 42nd straight day I’ve worked on the book and now that I’ve stretched it out this far I don’t want to see it go away.

Nothing here is new, though. These are all things that other people have figured out before me. This November simply put these things into sharp focus for me and the end result is that I’m half way through a book on a tool I thoroughly enjoy using and think more people need to know about.

For the record, I did miss one day in November. I didn’t write the day I gave my Pragmatic Guide to Git talk at Zendcon. I figure giving a talk is a good enough excuse for missing a day.

Then it dawned on me, why don’t I just embed the video on my site? Makes it super easy for people to find (travisswicegood.com/tags/riak) and I don’t have to go searching for it.

So, here’s what I consider one of the best talks to date on NoSQL.

This means some big changes for me and my family. First, I’m moving to Austin. I love Lawrence, the quirky little town that it is, but it’s time for a change. Austin was high on the list of other places to consider (great cycling, big tech community, cool vibe, etc., etc.) so when this opportunity came up I had to take it.

The move is complicated by virtue of owning a house. For the first six months or so we’re going to split the house – me in Austin and Meg in Lawrence. I’ll be spending a week or so a month working from Lawrence so I can help finish up some of the random project on the house that we want to finish before we attempt to sell it. This works perfect with the Lawrence real estate market which peaks in April every year.

What happens to Domain51?

One question I’ve gotten repeatedly is what happens to Domain51? Well, nothing in particular. I’ve spent the last 5 months or so winding it down in preparation for a transition of some sort. Until recently, I didn’t know exactly what that transition was going to be, but I’ve setup all of my former employees on their own adventures and wrapped up the work for existing clients. So it will go back to being my placeholder for any random consulting I do and the legal owner of all of my personal code copyrights.

What about Lawrence?

Lawrence is one of the coolest places I’ve lived. While writing this post I realized that it’s the place I’ve called home more than any other place since I left El Paso years ago.

There are tons of great people here, the culture is great, the weather isn’t half bad (though 2010 hasn’t puts its best foot forward), and it has some of the best food in the world if you’re a vegetarian. I am truly going to miss this town and everyone in it.

Isn’t journalism dead?

Yup, that’s what is so exciting about the Tribune. They’re trying a different model, and helping them make it successful could set the tone for how journalism copes with the seismic forces that are causing it so much change.

The Tribune is adopting what I call the NPR approach to journalism. They’re organized as a non-profit. You don’t subscribe to a paper or some such, you become a supporting member of it. Interested in politics and policy in Texas? Then you need to visit this page for more information about how you can support them.

I am really excited about this move. It’s the meshing of the past year’s work in non-profits and politics into one gig in an industry that is in the mist of a massive shift. How could I not want to be in the middle of that?

From today’s announcement:

Last summer, Pragmatic author Travis Swicegood proposed a new kind of book covering the popular version control system, Git. We thought it was a good idea–so much so that we’ve launched a whole new series in this format. Check out the details on the series below, as well as Travis’ new book, Pragmatic Guide to Git, now available in beta.

Having a good idea is cool. Having a good idea that you can get other people excited about too is even better. I thought I was onto something interesting when I pitched the idea to Prag, and so did everyone else there. A year later and here we are with an entire new series lined up.

Here’s the quick description of the new book:

Need to learn how to wrap your head around Git, but don’t need a lot of hand holding? Grab this book if you’re new to Git, not to the world of programming. Git tasks displayed on two-page spreads provide all the context you need, without the extra fluff.

Data is the new soil

I love that line. Data gives rise to new ways of understanding something. Presenting something spatially gives you the ability to put it in context more quickly than trying to explain the context.

Take 20 minutes, this video is well worth the time investment:

The new Pro Glide from Gillette only costs less than $10 to purchase. Good deal, right? Nope. The replacement blades cost $3-$4 each! Assuming you get a few weeks out of each blade, you’re looking at paying between $6 and $10 every month to use this razor blade.

It’s a great deal—for Gillette.

I use Merkur razor. I paid a lot, comparatively speaking, up front but I can buy better quality razors for less than $0.75 each. They last a lot longer and I end up with a much better shave.

I view the trade-off here as the same one you have to look at when deciding what framework you choose to develop your code in. There are a lot of frameworks that provide a lot of help getting off of the ground. It almost seems too easy.

Write your on custom blog in 5 minutes? Sure! Want to have a RESTful API? Add a couple of classes, some new routes, mark as complete.

Look at the framework and read some of the comments from its detractors. Those complaining generally have one of two problems:

1. They’re going to complain about anything, they’re just ranting. Ignore these people.
2. They’ve hit a legitimate pain point in the framework where they deviated too far from the intended use. Pay attention to what these people are talking about.

If you’re application is significantly complex, no off-the-shelf framework is going to do everything you need it to. Some frameworks may even get in the way. Make sure you realize the trade-offs before you commit.

What makes a good framework?

The best ones serve as scaffolding—in the original meaning.

… a temporary structure used to support people and material in the construction or repair of buildings and other large structures.

Put another way for software development:

… helps you ramp up quickly, then gets out of the way.

Historically, frameworks manage the first part of this well. That’s where they shine. It’s the last part that they’ve had a problem with.

Django manages both of these well. My one complaint with it is that it manages the latter part better than the first. There’s a lot of boilerplate needed to get started, but I can live with that. When my applications outgrow Django, removing Django from the equation is easy with one exception.

Models.

Models are like your razor’s blades. Without blades, your razor doesn’t shave; without models your application doesn’t have any data to work with. The fix I’ve found works best for me is to keep my models then and put all of my logic for operating on them in other areas of the code base.

This separation helps me keep my business logic portable. I might be using the cheap route to get started, but the heavy lifting goes with me if I decide something else is a better fit.

Honestly, how different is this than the current frequent shopper cards? Our rewards aren’t points (at least all of the time), it’s lower prices. A lot of our credit cards are already points based. “Get a million points, fly anywhere.”

That particular job posting rubbed me the wrong way, however, because of it’s emphatic no telecommute policy, with them going so far as to call attention to it with a bold font. To automatically shut the door to any potential employee who might be an amazing fit, just not in their particular office seems extremely one-sided.

I woke up ready to write, and did. Before writing my first book, my post would have been rather mellow. I would have presented the case, but not gone quite so far in making my case. This post, I decided to let it rip. Companies that didn’t allow telecommuting don’t get it, end of discussion.

And boy did it work. Nearly 90 comments—between Hacker News and my blog—later, I’m still amazed at the fervor with which both sides attacked the issue. Almost to a T, no one was in the middle on this. Everyone had an opinion. They loved it, or they hated it. Everything from management types saying how their teams wouldn’t be the same if IRC was their only interaction to people with severe social anxiety talking about how telecommuting affords them the opportunity to deal with that anxiety by focusing on their job, not their proximity to people.

I like to mine the edges of the conversation to get the bigger picture. My post emphasized the importance of taking a stand. Had I not been so opinionated, I doubt much interested would have been given to the post.

Honestly, the post is a little harsher than my personal opinion on the subject. Companies that start the conversation with prospective employees by outlining the things they aren’t going to stand for are starting off on the wrong foot, but beyond that I realize that telecommuting does present challenges in some environments and some companies—at their loss—aren’t willing to try to overcome those challenges.

A few months back a recruiter—the flaky kind it turns out—was talking with me about a gig. I was honest that I wasn’t looking to move, but for the right opportunity every thing was on the table. I told him:

I want to be up front with you. I’m not looking to move, but I’m not ruling it out. All I ask for in return is that you approach this with the same open-mindedness. Let’s continue the process, see if its a good fit, then figure out if we can make the logistics work.

Needless to say, they didn’t. Companies, particularly in the tech space, are asking their potential employees to take a chance on them. Companies are taking a risk too, but when companies expect the employees to be the only ones giving (broadly disregarding monetary compensation from the companies for the moment), they set the wrong tone.

You can almost always discover what technology a company is using if they’re hiring. I found out Plurk uses Python through this method, that Twitter hasn’t given up on Ruby, and even when it doesn’t make sense Washington DC shops still use Drupal.

That last company is what gave rise to this tweet:

They’re pretty blunt about telecommuting, actually. Going so far as to say “[i]t is not ok to telecommute.” The emphasis is theirs (as seen in this Skitch). This gives me a couple of possible explanations:

• They’ve been burned in the past. They hired someone on who misrepresented himself, his abilities, his capacity, or all of the above. They feel that they gave it a try and it isn’t for them, so they’re not going down that road again. This is the most generous possibility.
• They don’t have their heads screwed on right. They live in a “constantly evolving and fast-paced” environment (as seen on other job postings) which translates roughly into we can’t control our product team, our CEO, or worst, what our sales team promises, so you’re going to have to sit by and wait for the hour-by-hour priorities. Communicating them by any other means than directly from our mouth to your ass, sitting at a desk waiting to turn our ideas into money via that magical electronic device in front of you is too inefficient.
• A slight variation of the previous option is that they lack the confidence in their abilities. They have the vision, the product specs are nailed down, but they don’t know if they can convey them without “reading” the other person.
• Finally, the last possible option is that they’re so out of touch with reality that they believe the only way for work to be done is with “asses in seats.”

Of these options, shy away—no, run, very quickly, away from the 2nd and 4th. Those companies don’t get it. The other two provide some hope, it’s up to as to whether to stick around (or start) and find out.

Companies that don’t allow telecommuting, especially companies that are up front about it, don’t get it. Telecommuting is no longer a technical challenge. Reliable high-speed Internet is ubiquitous at this point. I can see adding that as a requirement to a job posting, but not where you’re located.

With the technical out of the way, that leaves only the social aspect of the company and the position they’re hiring for. I get the culture that requires someone on site. I also realize I’m not interested in working for a company with that culture.

It’s the culture that specs and requirements are fluid based on the latest hallway session. It says interruptions are a part of the day that you should be used to—we like to chat a lot. It’s the we don’t have any realistic metrics to use to judge your performance, so we can only know if you’re doing work by whether or not you show up. That last one has worked so well in the past.

The world’s a big place. There’s a lot of developers in it. There’s even a few kick ass ones. Most of those don’t live near you—even if “this position is located at our offices in Palo Alto,” which is another euphemism for no telecommute. By being up front about telecommuting not being and option, you’re telling me that company comes first (we go to the mountain). Hiring someone good is important, but hiring the best you can afford isn’t.

A company that doesn’t go out of its way to build the best team possible, regardless of where they’re located, isn’t a company I want to work for. It’s a matter of priorities. I’ve got mine straight, they don’t have theirs.