For the last several months I’ve been pair programming every day, working with another developer on a Windows application. Both of us usually use Macs, so we’ve adopted a company Windows laptop to do the work, and as we’ve experimented with our pairing tools, we’ve learned a bit about how tools affect getting the job done.
Alternating Mac & Windows, Dvorak & Qwerty
When we started on the project, my pairing partner and I sat with our Macs in front of us and the Windows laptop in between, pushing the PC back and forth depending on who was driving. The keyboard and trackpad were unfamiliar, and despite weeks of using them, we still only tolerated them, frequently sighing at clicks we didn’t mean to make and keys we didn’t mean to hit.
Read more on Adventures in Pair Programming – 2 Devs, 3 Computers…
The ability to know what day of the week a given date falls on is usually associated with savants. But with a little memorization and some arithmetic, anyone can do the same. There are several techniques, some requiring more memorization than others, some requiring more arithmetic. The technique in this post requires memorizing 12 single-digit numbers for the year you’d like to use it on, but it requires less calculation than alternative methods (such as this one).
Read more on Mental Math Tricks — Find the Day of the Week a Given Date Falls On…
One of the most visible parts of Atomic Object is this blog, Atomic Spin. Untold numbers of potential clients and employees contact us because of what they read on Spin and what high regard they have for it.
Spin’s success isn’t an accident; it’s a group effort. Everyone at Atomic is asked to contribute regular posts, and though it may be unusual to ask programmers to write, it’s more unusual to have so many programmers who are so good at writing. One of the things that sold me on working for Atomic Object was how well their programmers expressed themselves on the company blog.
Programmers aren’t natural-born writers. Some love to write, but others are happy to express themselves solely through code.
Spin isn’t a good blog because Atomic is made up of unusually good writers. Spin is so good because Atomic is made up of unusually good programmers. Like good writers, good programmers insist on expressing their ideas as clearly as possible. Programmers use code, and writers use language, but the underlying skill is the same. The medium is the easy part. The hard part is learning to express yourself. Read more on Hackers & Writers – Practicing the Non-Linear Arts…
One of the aspects of Atomic that makes it successful as an innovation services company is that it’s made up of people who enjoy trying new things. In my experience, this is very unusual — most people resist change.
Innovation is a gamble, and everyone isn’t a gambler. Even if the benefits eventually outweigh the costs, the costs still come first. You have to spend time, energy, money, and other resources before you gain. It’s often easier to sidestep innovation and keep doing it the same old way.
The costs of innovation can be seen in big new ideas, practices, and technologies, but also in small innovations.
Moving the Keys Around
A couple months ago, my co-worker Al announced he was planning to learn the Dvorak keyboard layout. Even though learning a new keyboard layout is a big change for a programmer, several of us at Atomic have made the switch and now use Dvorak every day. Read more on Challenges to Innovation: Fear, Friction, & Compatibility…
As developers, we prefer to automate wherever possible. Usually we automate computers, but it’s also possible to automate humans. Humans, after all, come with their own built-in automation system called “habit formation,” and we can cultivate helpful habits if we understand how habits form. Here’s an example from personal experience.
At Atomic Object, we’re very dedicated to test-driven development. The project I’m currently working on has 113 files of tests for a project with 154 files of logical code. Most code files are verified by a corresponding test file, so it’s important to update the appropriate tests before making changes to the code. Coming from a project that put more emphasis on full-stack integration tests rather than file-by-file unit tests, it was easy to forget to update the unit tests before diving into the code. Correcting this tendency required a bit of habit hacking.
Charles Duhigg’s excellent book The Power of Habit lays out a three-step framework for forming a habit. First, you need a trigger, something that cues you to carry out a routine. When you finish the routine, you need to receive a reward. Once you know the trigger, the routine, and the reward, the habit will start to form.
Read more on How to Automate Your Human – Forming Good Development Habits…
Tmux is a powerful terminal multiplexer, and its built-in support for scripting allows you to create new features according to your own workflow.
I spend most of my day in Tmux, at the command line, grepping through codebases and editing files with Vim. I copied and pasted or re-typed file names for a long time before I realized how irritated I was that I couldn’t merely click on a file name and immediately open that file to the given line.
An IDE would have that functionality, and being firmly in the camp of command line as IDE, I set out to right this wrong.
Read more on An Introduction to Scripting Tmux Key Bindings…
When working on multiple web applications, it can be taxing to remember which applications are running on which ports. By default, Ruby on Rails serves on port 3000, MAMP serves on port 8888, many applications start up listening on port 8000, and you might even find yourself using a non-traditional port like 8012. Knowing where to find each application becomes increasingly difficult. It would be much more convenient to call up, say,
http://launch/ in your browser, rather than
Fortunately, it only takes a few simple shell commands to accomplish such a feat.
Read more on Serve Local Web Apps under a Custom Domain…
In the battle of data formats, the two heavyweights are XML and JSON. Of late, JSON seems to be winning, in large part because most languages natively support JSON’s chosen data structures, but there’s one arena where JSON hasn’t made much of a showing: the command line. The command line provides a lot of programs to handle plain text (
sed, to name just a few), and handling XML is even supported through
xpath, but dealing with JSON has been the domain of standalone scripts written in Python, Ruby, or whatever your favorite language happens to be. There’s been few good ways to manage JSON directly from the shell. That’s why Stephen Dolan created Jq.
Read more on Handling JSON from the Command Line with Jq…
Critics of Ruby on Rails often accuse it of being slow. The standard rebuttal is that any web application scales given enough instances, but that rebuttal ignores one important effect of Rails’ slowness: the impact on development. Any time you run a Rails command, Rails loads your entire project, a process that starts out slow and slows down as your project grows.
If you’ve been irritated by these startup delays, you’re not the only one, and there’s finally a way to wait less and do more. Its name is Zeus.
Read more on Using Zeus to Pre-load Ruby on Rails Environments…