WordPress database error: [Got error 28 from storage engine]

WordPress database error: [Got error 28 from storage engine]
SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('category', 'post_tag', 'post_format') AND tr.object_id IN (572) ORDER BY t.name ASC

Nine months of pair programming - Yan Pritzker – Yan Pritzker

Yan Pritzker software entrepreneur, photographer, musician

Blog :: Git Workflows Book :: Dotfiles :: Photography :: About Me

Get the news feed
Get updates by email
Follow me on twitter

hello, i'm yan

I am a photographer, entrepreneur, technologist, guitarist, climber, and telemark skier

This blog is about startups, blogging, Ruby On Rails, virtualization and cloud computing, photography, customer service, marketing, ux and design, git, and lots more.

I am the CTO at Reverb.com - The Marketplace for Musicians. We're hiring web Ruby and iOS developers!

Selected Reading



Reach me at yan at pritzker.ws

Nine months of pair programming

Posted 22 August 2012 @ 5pm in Uncategorized

I’ve paired off and on throughout my programming career, but for the last nine months, I’ve had a chance to pair nearly full time. I’m not much of a drink-the-koolaid dogmatist, so I’ll try to give my honest opinion about what’s wonderful and not so wonderful about pair programming.

The Good:

Zero time for knowledge transfer – when my pair partner decided to leave the company, we didn’t have weeks of knowledge transfer sessions. Because we had been pairing about 90% of the time, there was actually no knowledge transfer required. Contrast to previous companies, where a core engineer with siloed knowledge leaving the company would wreak havoc.

I felt more productive. A pair keeps you honest and prevents you from facebooking and checking email compulsively. This meant that we would get a very strong groove going and be very productive. Conversely, by the time 4:30 or 5pm rolled around, we were pretty destroyed. While we tried to take sporadic breaks, I found that when I worked by myself, I would work longer but with more breaks. With a pair, we would work shorter hours but start to feel quite inefficient by the afternoon.

Higher quality code. I did feel that after discussing things with a pair, the overall code quality improved. For this to work, your pair doesn’t always have to be an all-knowledgeable rockstar. Even bouncing ideas off someone who doesn’t understand them fully can often lead to a better design. But it’s even better if your pair nicely complements your knowledge in areas you’re not strong in. I was lucky to work with some pretty bright people. In past companies, I had been paired with B-level guys, and that was not only a drag on productivity but also morale, leading me to dismiss pairing. But that’s more of a hiring issue, and not a pairing problem.

Not So Good

My voice got tired. I also find that when coding, something happens to my linguistic center for English and I just start speaking very strangely. Switching constantly between English and code is hard and reduces overall productivity. On the other hand, discussing things usually leads to better code.

Research and learning is awkward. It’s definitely counter productive to read over someone’s shoulder while they’re doing research, as people read and absorb information on different schedules and in different ways. For example, I google and skim pages at lightning speed, causing my partners to probably think I have ADD, but that’s what works for me. I found it extremely helpful if one person was coding, the other could use a second computer to look things up and pass things back and forth as chat links.

Creative tasks are harder. While our combined creativity in refactoring code was high, non-coding tasks such as visual/ux design became a chore with someone over your shoulder. I found it easier to break apart for such things and have one person work on the connecting code while I mocked up the design.

Simple tasks take longer. While the overhead of pairing is well justified when you’re debugging complex issues, designing new areas of the system, and so on, for quick one liner tasks the overhead of having to explain to your partner what you’re doing slowed the overall process down.

During times when I worked remotely, I was able to knock lots of little tasks in a day, whereas with a partner it felt like we achieved half as much. During remoting sessions, we would not simultaneously pair, but we would discuss things in chatrooms, and do code review via github pull requests. I believe if you are not lazy in code review, and really question every line of code, it can be just as good as pairing in terms of code quality.

The desire for environment uniformity can be difficult to handle. One partner I worked with had an idea that everyone should have exactly the same environment, editor, etc. I believe this idea comes from Pivotal Labs. Having a uniform environment lets you seamlessly switch from one workstation to another and not have to adjust. This seems like a good idea on the surface, so that developers can be equally productive. However, I believe that lowering everyone to the lowest common denominator actually decreases productivity.

For example, my vim setup lets me type probably an order of magnitude less keystrokes per day than most people and achieve incredible speed and efficiency. I personally don’t feel comfortable having to type more, which is horrible for your hand health, and forced into an editor I don’t like just to achieve team uniformity. Instead, I find having two machines side by side, with one person reviewing code and doing research much more productive. With my other partner, we were able to achieve a nice harmony with him driving for half the day, and I for the other half. This allowed each of us to be ultra productive on home turf, while still getting all the benefits of pairing in terms of knowledge transfer and code review.


I think pairing coupled with an extremely pragmatic approach to knowing when not to pair is the key to success. For me, the benefits of pairing are very high. Instant knowledge transfer and high quality code are very important. But, I believe it must come with a healthy dose of scheduled breaks, time for doing solo tasks such as design, and occasional remote code review sessions to give pairs a psychological break and mental refresh.