One of the most enjoyable parts of my last job was that we hired a lot of junior developers and interns. I really enjoy working with younger people than me, because they’re as eager to learn new things as I am. I also really enjoy discussing technical things with them, largely for selfish reasons: explaining something to someone else makes me understand that thing much better.

One particular intern on my old team was a lot of fun for me. The company was the first place he worked since graduating with his B.S. in Computer Science. The things he said were so similar to things I said when I first graduated, and his approaches to problems reminded me so much of my own approaches to problems eight years earlier that it bordered on creepy.

One particular exchange between him and I stood out in my mind. It was exactly the conversation that 28-year-old me would have had with 20-year-old me.

Him:

Arggh, the other team changed the interface of something my code is using, and now it’s broken.

Me:

So? Just fix it.

Him:

I will, but it’s annoying. I mean, if they had just started the application they would have seen it’s broken. They’re so stupid.

Me:

Wait, it breaks right away?

Him:

Yeah, you get an error when you hit the front page. The front page!

Me:

Then they aren’t the ones who are stupid. We are.

Continue reading ‘I Broke Your Code, And It’s Your Fault’ »

I used to have a huge collection of DVDs. For a few years, any time I saw a DVD of a movie I liked priced at under $10.00, I bought it. My DVD collection spanned 4 shelves, easily 300 movies. When it became clear to me that Blu-ray was going to win the HD format war a few years ago, I sold nearly all of my DVDs on eBay, one by one. I did this before Blu-ray was declared the official winner because I knew it would be hard to get decent prices for my DVD collection once DVDs were outdated, and I think it was the right move.

I’m slowly rebuilding my movie collection in Blu-ray, but the main difference between my Blu-ray collection and my DVD collection is that I intend for my Blu-ray collection to be limited. Rather than buying the Blu-ray of every movie I like, I’m only buying the Blu-rays of the films I absolutely love. Many of my DVDs were never watched after purchasing, a few of them were even sold on eBay without the cellophane removed. New purchases are just my favorite films of all time (or at least related, which is why I own Terminator Salvation).

Continue reading ‘First World Problems: Blu-ray Woes’ »

Software development is a strange beast sometimes. Despite the fact that it is not predictable enough or constant enough to qualify as true engineering, it’s often referred to as Software Engineering anyway.

There are no rules in software development. Some suggest the existence of best practices, but really there are only guidelines and recommendations.

Despite these truths, there are a number of alleged “rules” in software development, often suffixed with “considered harmful” as a reference to Edsger Dijkstra’s famous “Go To Statement Considered Harmful” essay. I want to look at one of these rules a bit more closely.
Continue reading ‘Magic Variables Aren’t Always Magic’ »

I recently had to merge a number of independent projects into a larger project to enable a long-term project reorganization effort. Since we’re using Git for both projects, this was quite easy, but it required some investigating to figure out how to do it.

So you have two projects, old-project and new-project. You want to end up with a subdirectory inside of new-project called old-project with all of the code from old-project, and you want to preserve that project’s history.

For the purposes of this demonstration, old-project is cloned at /home/machete/old-project and new-project is cloned at /home/machete/new-project.

At the end of this, we want there to be a /home/machete/new-project/stuff/old-project with all of the commits from old-project intact.

Continue reading ‘Moving One Git Repository Into Another As A Subdirectory’ »

I’ve made no secret about the fact that I Love Pair-Programming. I’ve tried pair programming with a number of different setups, each one better than the last.

I’ve had a lot of people ask me about how best to set up pair-programming environments at work, so I’m going to take you through a number of different ways to pair-program and discuss the advantages of each.

Level -1: Not Pairing

The first level of pairing is something I see surprisingly often. An inside-corner desk, typically an individual’s workstation. Another person scoots their chair over and leans in, looking at the same monitor.

It seems like no coincidence that virtually everyone I’ve seen “pair program” this way dislikes pairing. That’s because this setup is not actually pairing. It’s just coding with someone watching over your shoulder.

Nobody likes having someone read over their shoulder, let alone read code they are writing. This set-up basically ensures that the person writing the code (the driver) and person thinking about the next steps (the navigator) never trade places. Trading places involves not merely sliding a keyboard over, but actually scooting rolling chairs out of the way, so it never happens.

Just as importantly, the two programmers are not the same distance from the monitor. The monitor “belongs” to the person sitting closest to it, so the other person is really just watching. The navigator will probably just zone out and think about something else while the driver codes away, confident that their pairing partner is helping ensure they don’t make mistakes.

This kind of pairing is a waste of time. Corner desks are the office furniture from hell. Put it in a cubicle so that it’s basically impossible for two people to fit and you’ve essentially ensured that nobody on your team will ever pair program.
Continue reading ‘Mechanics of Good Pairing’ »