Op-Ed on Bridge

Different Pairing Styles

Sat, 16 Nov 2013 00:00:00 +0000

Pairing is hard, but to me, the hardest part about remote pairing is not technology or even logistics, it’s collaboration and problem solving together. To that end, there are multiple pairing styles that are worth looking at when you’re trying to pair with someone knew. Each style facilitates collaboration differently and knowing how they work helps.

Driver / Navigator

Fundamental Idea One partner “drives” at the keyboard, focusing on implementing. The other partner “navigates” verbally, focusing on big ideas, questions, typos, and conventions.

Firming Up before Moving On

Tue, 12 Nov 2013 00:00:00 +0000

As developers, we have a tension that we almost always deal with, the tension between writing the best possible solution and the fastest possible solution. Usually we end up somewhere between them, sacrificing a bit of quality for speed. I’ve yet to hear of a developer that would say they sacrificed a bit of speed for quality–but isn’t that what we want to do?

For myself, I’ve always struggled with this balance. What we want is to continually improve quality and deliver features quickly and readily. Can we do both?

How to Interview Well

Thu, 17 Oct 2013 00:00:00 +0000

There are lots of skills a developer has to have, but one of the ones you really need to have if you ever want to make a living is being able to interview well. There are lots of things that make interviewing a challenge, but if you interview well you’ll learn something at the least and get a job offer at the most.

Let’s talk about how to interview well.

Exercism.io - Refactoring and Reading FTW

Thu, 15 Aug 2013 00:00:00 +0000

A New Way to Level Up?

A few weeks ago at LSRC, Katrina Owen mentioned exercism.io as a site she set up for people to go learn new things, get feedback and head toward better code.

I was intrigued. I have always loved small, easily finishable exercises that allowed me to think about things OTHER than the exercise itself. I tried a few and quickly became hooked.

But the thing that really surprised me was not just how hooked I was on leveling up on the exercises, but how hooked I was on reading other people’s code and providing feedback on it. It was fascinating to see how many different ways someone else solved the same little problem. Little differences like naming to big differences like Functional vs. OO approaches to problems become easy to evaluate. It also becomes clear where certain solutions shine and where they don’t.

A Commitment to Being Positive

Thu, 23 May 2013 00:00:00 +0000

It’s really easy to be bogged down with all the crap in life. There is a good amount of it and I don’t know anyone that doesn’t struggle with keeping a good attitude at some time or another. I’ve struggled at various points to stay positive both in my personal life and publicly. I don’t think it’s wrong to have negative thoughts or to even voice struggles or frustrations, but there is a danger in openly venting. It creates a culture that is great at complaining and bad at doing anything about it. It creates an entire set of people bogged down in the crap of their lives, and because of the loud voices they hear all around them, it seems like there is no escape from it. There is so little good that comes from complaining publicly.

Pushing Past Programmer's Block

Mon, 06 May 2013 00:00:00 +0000

As coders, we’re often given tasks to do. These tasks can sometimes overwhelm even the best of us. How many times have you stared at a problem and when you finally sat down to attack it, you spent a quarter of the time you expected to on it. If only you hadn’t spent 3 hours playing Angry Birds.

There are lots of things you can do to “hack” your productivity, but most of them are focused on helping you keep track of tasks instead of motivating you to get going.

ToDo Lists and Bug Trackers

Wed, 01 May 2013 00:00:00 +0000

I love GTD. I love making lists and having things to do. I love having a system. That also makes me love bug trackers when I’m on a team. I love having everything listed in one place. I love letting it be the communication point for a team to get things done. Bug Trackers and To Do lists are great.

They just don’t seem to work very well together most of the time.

Mouseless

Mon, 29 Apr 2013 00:00:00 +0000

I always find it interesting to place artificial constraints on myself. I don’t think it’s the constraint itself that is good as much as what it shows me about myself or what I do. I read an article on Rands in Repose a few years ago that talked about giving up your mouse for Photoshop. The idea isn’t to rid yourself of the mouse entirely. The idea is to make you aware of when you depend on the mouse.

Pairing as a Life Habit

Wed, 24 Apr 2013 00:00:00 +0000

I’m interested in creating a culture of pairing… not just in my workplace, but in my life. I want to be able to pair with people in order to improve on the skills I alread have. This is seen clearly in the relatively new #pairwithme ‘micro-movement’ that is happening on twitter. It shows that people want to learn from each other and improve their craft.

But it doesn’t have to apply solely to programming. Last weekend I “paired” with a neighbor to fix my lawnmower. He is a bit more mechanically inclined than I was, but it took both of our efforts and problem solving to diagnose and fix the problem. All in all, a worthwhile time where I improved both my relationship with Ben and my ability to cut my grass. He got something out of it too, he felt great and is excited to tackle more mechanical projects. This is exactly the same reasons we talk about the benefits pairing in the first place.

Electronic Music Is Good for Coding

Wed, 16 May 2012 00:00:00 +0000

I’ve recently been curating a playlist on spotify for High Energy Electronic Music so that I could have something high energy with no lyrics, or at the very least very simple ones that were easy to ignore. The big point was to have something high energy that got me into the coding groove.

I have to say that it’s worked. Having a driving beat and some hard hits has made it really easy to get motivated to code on. Suggestions for similar artists/songs welcome.

Distributed Teams in the Same Room

Tue, 24 Apr 2012 00:00:00 +0000

When you’re in the same room, often your communication is done via waving at each other, overhearing a conversation, happening by a desk, etc. It’s accidental communication in many cases, and it’s good.

But it can have detrimental side effects to productivity when interruptions can happen at any time. That was the main impetus behind deploying HipChat to our organization–having a way to allow people to communicate without directly interrupting. Let people come to the communication, rather than taking the communication to them

Pull Requests on Private Teams

Tue, 24 Apr 2012 00:00:00 +0000

Pull Requests are used often in the open source world, but less so on private teams. They are a great way to provide an automatic, team-wide code review mechanism. If your private team doesn’t use pull requests, I’d encourage you to investiage it.

Why would you move your team over to pull requests?

it provides a mechanism for code and source control review
it gives more visibility and accountability to the whole team
you can (optionally) restrict access so only trusted members bless the merge

What is the Pull Request process like?

There are lots of resources about how to submit pull requests out there, but the basics go like this.

Always Fight for Simpler

Thu, 08 Mar 2012 00:00:00 +0000

If there is one thing I have said over and over again in one form or another, but never seem to learn completely, it’s “Always Fight for Simpler.”

Everything could be simpler. Sure, we think it can’t, but it can. Don’t assume you need a feature in an app, a gadget in your life, or a certain amount of money… fight first for simpler.

Ask yourself, for any given situation, what the simplest possible solution to the problem is. Maybe it’s not good enough… but maybe it is. Fight for the simplest solution and go from there.

Complexity and Elusive Perfection

Wed, 29 Feb 2012 00:00:00 +0000

About three or four times a year, I find myself wishing my application wasn’t so complicated. I wish I was some stud developer who always made the right architectural decisions and didn’t back myself into a corner. I read about OO ideas regarding change management and coding for change even when you don’t know what that change is and mostly, I find myself baffled.

Hindsight is 20/20. I can see easily how the decision that seemed good at the time to make a Model.seed! method that allowed you to specify all the department data in the database AND change it in the app was a bad idea. I can see that allowing users to change values of reports from within the reports, like a spreadsheet without using the adjustment-as-a-line-item pattern is now a bad idea… but we’re 3 years on and it’s just not something we’re going to be able to convince the users to change or the management to invest the money in fixing.

Scary Complicated or Richly Awesome?

Tue, 27 Sep 2011 00:00:00 +0000

When you look at a new piece of data, most of our initial reaction is in relation to the complexity of that data. Usually this scares me, but after you get to know the data, the more the merrier! What was scary becomes rich and awesome.

How do we move from scary complicated to richly awesome? Comprehension, comprehension, comprehension. And what is the best way to grok something like that? Dive deep into the guts of the code or the task and find out why the data is there and what it does. Why was it modeled that way? In what way could it have been modeled different? Do I have the power to change it? Is it a good thing to change it? Do I understand the system fully enough to see the richness of the data and of the model itself?

Feedback Loops and Estimation -or- What Rubik's Cubes Taught Me About Making Software

Mon, 04 Apr 2011 00:00:00 +0000

Estimation is hard. It may not be listed as one of the top two problems in computer science, but it’s at least a close third. Over the years I’ve gotten to try all sorts of methodologies for estimating. Waterfall, Agile, Points, Stories, Requirements, Features, Epics, Pomodoros, Billable hours… you can go on forever with the Jargon of Management, trying to get information from a developer about how much longer The Client has to wait until The Feature is finished.

How to Stay At Inbox Zero

Tue, 04 Jan 2011 00:00:00 +0000

I saw a link recently on how to get to the ever elusive “Inbox Zero” and it seemed kinda lame–label everything “oldinbox” and archive everything in Gmail. Maybe that’s the only way to do it when you have 10K+ e-mails in your inbox, but it seems like the best way is to never get there to begin with.

Personally, I haven’t had more than 50 e-mail in my inbox at any given time in over 2 years. I ruthlessly archive and delete items and as soon as I’ve processed something into an action for “Things” I get it out of my inbox. For e-mails I just need to look at, reference or respond to, I use the stars feature, but I have only 8 starred items right now. I think at some point I had nearly 20… that’s about the max.

The Importance Of Speed in Automation

Fri, 03 Dec 2010 00:00:00 +0000

We are impatient people. This is something that we must work to fix in order to grow as individuals, but it is something that serves the automator well–or can be our downfall.

Joel Splosky wrote on the “Joel Test” that having anything less than the best tools money can buy is rediculous for a development team. The reasoning is this: If you’re paying developers what they are worth, then they are expensive, and wasting their time while they’re reading the Onion waiting for a build will kill your productivity–and your bottom line.

Simplicity

Tue, 23 Feb 2010 00:00:00 +0000

I’ve read quite a bit lately about simplifying our lives–mostly from a personal perspective, i.e. having less stuff, doing fewer things, focusing on the right things. It made me wonder how that translates to the professional level.

Apple, 37 Signals and many other companies make a living making software simple AND effective to use. That’s one way that it translates–on the macro level, but how about on the micro level? What is your absolute minimum work setup where you are free from distractions and free to do everything you need to do? Are there things that initially seem like “extras” that are actually a big deal? Are there things that you have in your workspace that you could easily do without now?

iPad - The Future of Casual Computing

Tue, 02 Feb 2010 00:00:00 +0000

I read a great article last week about the complexity and power of computers vs. what most non-Gen-X-ers want and it really got me thinking about the iPad.

The audience for the iPad is larger than the audience for the iPhone, even larger than the audience for a Mac. It’s a nearly complete computer replacement for a whole segement of the population. Some college students have the potential to get by without a computer at all. Imagine if everything fit into your $800, top-of-the-line device that you carried around under your arm. You could read your textbook, take notes, listen to music, watch movies, check e-mail… scratch that, check Facebook, browse YouTube, compose your paper, balance your budget and map out where to eat after study hall. It’s a fully functional device that is a tiny dent in their pocketbooks compared to a laptop.

Fixing "Freemium" issues in the App Store

Fri, 11 Dec 2009 00:00:00 +0000

Recently, Apple allowed Apps that are free to add in-app charges in order to allow users to “try before they buy.”

Interestingly, BrainJuice, a developer of the game Arcade Hockey recently decided to move to this freemium model, but made a major mistep in my opinion. The original app was $0.99, but the newly updated version is free, but contains ads. In order to turn off the ads, you must pay $0.99, which will mean that you basically paid twice for the same app. There might be a bug fix or two here and there, but nothing deserving of doubling the price of an app.