Reflecting on Being Employed as a Remote Pair Programmer

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected.

The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technical problems, and building solutions.

It is not the "remote developer concept" that many have in mind. I worked from my home, but did not make my own hours. I did not go to an office by day, but also did not work for myself. I could not take arbitrary days off as self-employed or many work-from-home people often do. It worked well for me and for my employer.

We found a pretty sweet combination by using Skype for voice and video, git for version control, and Webex to do screen sharing. The latency for webex is surprisingly low, and suited our needs very nicely. I set up a netbook with a built-in camera for skype so the company laptop's CPUs could be fully devoted to programing and screen-sharing (so necessary when using cpu-hungry development tools). An Asus EEEPC netbook is under US$300 most places, and mine really does a great job. I have had a few headsets. They're inexpensive, but they also tend to get uncomfortable after a few hours, so I would definitely try several. I used a few logitech models and was more-or-less satisfied.

The other useful tools for a remote pair partner? I second monitor (a large one) and synergy. Synergy allows one keyboard and mouse to be used by multiple computers. It is easy to setup and use, and allowed me to switch between netbook and work notebook very easily. I found myself mousing among three screens attached to two computers, and never thinking twice about it. It all just became transparent.

If your organization is interested in using remote teammates, I cannot over-recommend the combination of WebEx, Skype, Netbook, Work Computer, Synergy. For very little cost, you have a powerful pairing system.

There are shortcomings to being a remote pair-programmer, though. You are not visible to your bosses, and can be forgotten sometimes. You do not participate in the conversations at the next cubicle, in the hallway, or at lunch. You don't see the same visual cues as to the team's progress. You can't feel the emotional charge in the room to know when people are afraid, tired, angry, or excited.

A remote does not have the physical presence necessary to be an agile coach or effective scrum master. Email and text will not truly fill the gap of rich, human communication. Your view of the team is the webcam. That leaves you out of mentoring opportunities, so you learn and teach less than you could have on-site.

Remote meeting participation is awful. The room is full of people, and there are one (or a few) mics. Inevitably the people doing the most speaking will be furthest from the microphones, and the most fidgety people will be close to them. There will be long stretches when you can't make out what is being said behind the rustling papers, pen clicks, rhythmic tapping, layers of whispering, etc. The worst interruptions in sound are caused by the the other remote who is on speaker phone but didn't mute their mic. Every time a sound activates their mic, all other sound on the line is cut off. It is almost as if someone were toggling the mic in the meeting room. One can lose interest in trying to keep up and return to coding, missing the reason they were invited to the meeting in the first place.

Finally, a remote is harder to promote and easier to release than a body you see every day in the office. That might be seen as an advantage to an employer, but will probably seem a little off-putting to the remote employee. My intention was to try remote development for a quarter or two, yet we stuck it out together for over two years. That's a pretty nice experiment, and I thank GeoLearning for the great and mutually-beneficial opportunity.

Would I be remote again? I think I would. I would remote with the same team in a heartbeat, because they're good people and we learned how to do this together. I still learned, connected, and enjoyed software development with good people. But I think I would like to go onsite again for a while. However convenient it is to be distant, programming is still a social act and still best done shoulder-to-shoulder.

Observation on Growing Disconnected

People, software, and organizations often grow in this way: they accumulate without assimilating, and aggregate without integrating. As a result, they tend to be disconnected and fragmented and without a real focus or direction. In all three cases, it's amazing how functional they can be considering the shape they are in.

Perhaps this is the different between innovative young companies and the well-worn thinking paths of large ones, between young turks and hold functionaries, between greenfield software and legacy.

If so, then can we renew our creativity, youth, vigor, and clarity by ordering and integrating ourselves?

I would like to believe it is so. The idea, alas, is too grand for me. It's out here now, and maybe it will spark something more easily grasped and leveraged.

Software Talent Agency?

I had some thoughts cross my mind today, and wanted to write them down before they fade.

I'm of some reputation in the agile community, a sometimes-recognized author, a consultant (ex-of Object Mentor, ex-of CSC Consulting) and an agile coach. I've taught thousands of developers to program in C or C++ or Python, how to do TDD in many more languages, and the intricacies of object-oriented design. I've refactored horrible code and tested and built tools and transformed teams.

I am also a 48-year-old man who needs to establish his personal brand. Many of us are introverts by nature, and those of us with rural, midwestern upbringing tend to self-deprecation. I've always found self-promotion abhorrent. Writing a promotional bio actually makes me a little sick at my stomach. The shame of it is that I could have learned to be comfortable with it a long time ago.

If I had begun the push earlier and had some coaching I would have made some different technology and career choices, but who knew? I jumped the track a few times, missed a few predictions, and didn't do some things that might have made me wealthier and more secure in my life and community.

Now imagine that you are well-known in your community, and you heard of some upcoming new Corey Haines or Ben Rady or other talented kid. You would have the contacts to introduce them around. You could help them to establish their web presence and write up promos. You could promote them among their peers. You could connect them with editors who could shepherd them into writing gigs with magazines. You could hook them up with local communities, find them speaking opportunities and help them polish their presentations. You could help them to write the kinds of things that get picked up on reddit, hackernews, and the like. You could find them side gigs, maybe help them negotiate rights to quote code and publish details on the work they do. You would have to learn about buzz and how it works, the way a publicist does.

It would be a talent agency for programmers.

With just one or two good success stories, you would raise the value of your organization and all of the people being coached there. Companies would be interested in using your people, and people would find value in joining.

It would be rough at first. You'd collect money much as a headhunter would. You would get a clip from placement, maybe a finders fee or the like. Maybe a clip from writing gigs you developed, deals you sign. There would be much to learn, but relationships would have a long tail. In time you could collect money on both sides.

I know that people already get involved in the community and connect and conferences, but not all people know how to do that or how to build momentum that way. It's a knack that some charismatic people have and others do not. Not all talented people can keep a room spellbound like Bob Martin or connect with people so easily as Corey Haines.

I wonder if the software world is big enough that we could have a talent development agency for software developers. It's a really intriguing thought, since self-promotion is not always what good techies do best.

I'm still the midwestern introvert, but I wonder if some of my extroverted peers see some value in the proposition.

About "Under Test"

I wrote earlier about code being under test, and how advantageous to have a test "under" several layers of testing. As I was looking through my old google docs, I found this drawing I'd made to explain layers of testing in a web app.

Terminology is catered to the audience of the time, and will probably confuse some. For instance "controller" here is really more like the "model" layer with its duty of acting as facade and moderator for underlying objects. Its purpose is primarily ensuring business rules and performing a single broad function that includes potentially many objects at the lower level.

The "API" objects here are the business objects. Again, tailored to the local terminology. Apologies. Maybe the Agile Otter should redraw the whole thing sometime soon. Anyway...

The idea is pretty simple, but sometimes people don't quite understand why the code-behind needs to be thin and why they shouldn't re-implement functionality in the fitnesse tests. If we use good cohesion and manage coupling well, then the unit testing becomes fairly simple, as do the unit tests on the controller.

We can test the code-behind through the web but even automated browser-tests are slow, often running for hours. It is handy to have browser tests, but nobody wants to sit and wait for them to finish. Most shops will push them off to the build farm so they don't suck up developer time. If code it only tested by-hand through the user interface, testing is pushed off to a dedicated testing team who will script and re-run the sames tests month after month for hours. It quickly becomes too expensive to keep scaling that team, and they start selectively running ui tests, in which case errors will slip out to production and customer care will have extra work, and bug fix reports will pull programmers out of new feature engineering. Often a company will have to split off a separate full-time team to do production bug fixes and data repair. It gets expensive quickly. Automating the tests means that we might be able to run all the tests every day, so that fewer defects can get out to the customers. It's cost-effective, but again very slow. The less the code-behind does, the better we can deal with it being potentially untested.

Our integration and acceptance tests (shown here with FitNesse) are going to run many minutes, maybe an hour or more. If the tests take only a few minutes then programmers will run them several times a day, probably before committing or pushing code to the shared repository, almost certainly at the completion of a programming task. Ideally these tests will bypass the code-behind entirely, but not re-implement any of its functionality. In order to make these tests effective, we need to empty the code-behind so that it is little more than plumbing between the controller and the UI. The business function controller is pretty testable, but the tests are like integration tests with many objects involved and possibly significant effects. It can still be tricky to test at this level unless most of the interesting bigs are pushed down into the business objects. The less it does, the easier the testing is.

Finally we're getting into the individual business objects. These tend to be pretty easy to test, as they mostly act only upon themselves. Good news for us. We can write extensive tests to drive behaviors into the objects. They become robust and predictable and understandable to the degree we stick to what we know about coupling and cohesion. Because they are underneath layers of testing (UI, FitNesse, controller, and individual unit tests) we can have more confidence in the changes we make here.

Maybe the picture isn't perfect, and the terminology is a little twisted, but the idea here is very simple. It works out that we can save ourselves time and money and even save face if we learn to keep the upper layers of the application thin, and save the meaty implementation for the areas where it is under layers of testing.

Of course, all blessings are mixed and even dark clouds can have a silver lining, so simple ideas can have costs and side-effects all their own. But this simple idea seems to work and seems to reduce problems for development teams and companies which employ them.

Want Your Own Agile Otter?

This is a limited time offer. If you would like to have The Agile Otter working for you, this might be your chance.

If you are looking to expand your technical team or need an experienced Agile coach, feel free to drop me a line (tottinge@gmail.com) and we can talk through particulars. I can work as a remote pair-programming partner (tech team) or on-site in NW Chicago burbs (coaching).

Explaining What I Do For A Living

I had a friend once tell me that he didn't understand what it meant to program computers. He was not really a computer user, and was just getting ready to try email at the time. He wasn't a gamer, and frankly the whole computer thing seemed too weird to him. After all, it's a machine, right? How do you program a machine? Is it like choosing a darkness setting on the toaster? Typing data into quickbooks? What? That was many years ago, but it still sticks with me. Some people (most in fact) really don't know what I do. If I tell them, they don't know any more than before.

When most people hear "programmer" they think "IT", in which case I must be the guy who fixes network outages, distributes patches, and helps people when their machine crashes (admittedly, a weak view of what IT is about). But no, I'm not that guy. I love those guys, but I'm not one of them.

A cousin of mine took an introductory course on programming, probably in Visual Basic, I don't recall. He told me that what I do for a living is really easy, "just typing." Of course I do some typing, but I'm not employed as a typist. In fact, on my good days, the program I work on is net-negative in terms of lines of code. But then a one-semester course on music appreciation hardly makes one a symphony conductor, or even a musician.

A post on slashdot a while back asked how to disguise "think time" because people mistake it for slacking. Again, we forget that this is not obvious to non-programemrs. One follow-up from Ben Alabaster was useful

During their lunch break get them to do a simple task like as a crossword. Ask them to be conscious of the amount of time they spend reading/writing vs. the amount of time they spend thinking [or looking up the answer]. Tell them that this is exactly the same as the time you spend reading/typing vs. the amount of time you spend thinking and looking up answers.

Better still Sudoku because it can involve hours of trying to figure out where you went wrong and why none of your numbers add up. So while the task itself seems relatively easy, after all, it's just numbers in boxes it can take time. Get them to predict how long it'll take them before they start and see if their prediction is right - guaranteed it won't be. You can hit them with a double whammy for why your time expectations never quite add up either.

This is the only way I can really think of to get them to understand the way engineers work. I see lots of "those types just don't get us types" - people are adaptable, people can understand things if presented in a fashion they can understand, it's just that nobody's ever taken the time to present them with an argument they get.

I think it is a great answer. We don't type for a living, we understand, reason, mentally try different solutions, hypothesize, disprove, reason, and invent. If we already knew the solution, we would simply type it in and be done with it, just as someone who had already solved the sudoko puzzle could copy it onto paper in hardly a minute's effort.

The majority of my work, though, is in diving into a system I don't understand (having read only a small percentage of its total verbiage), learning enough to understand why it is broken, rearranging and rewriting things until they make sense, writing tests to prove that my understanding of the problem is right, making changes that should fix the problem, and testing that my changes don't introduce new problems, all within a system vast enough that no one person understands how it works. I guess that isn't so easy to understand.

I spend more time learning than problem-solving, and more time problem-solving than typing. Basically, programmers learn and think for a living, and type their solutions into computers.

I suppose the right analogy is that you are handed three pages in the middle of chapter 17 of a 40-chapter novel, and you're asked to make some plot changes in the next hour or so. There is no chance you can read the whole book and make the changes in time. You could ignore the book and make your little changes locally and hope it doesn't disrupt the overall plot line, or you can read the chapter you're in and wing it. Eventually you'll have a solution you believe in, and you can type it in... but you shouldn't dive in with a typewriter until you've assessed what's going on, and the first thing you type probably won't be "good enough."

But now imagine that the document isn't a novel, but a multi-million word legal contract. You have to be very, very precise. Any mistake might open the company up to lawsuits and issues and costly contract revisions. Now you have the idea.

A really huge crossword puzzle is still a good approximation of a software system. Any one letter of any word may be a part of several different words, and changing one word may force you to change several others, which might cascade out to several others as well.

Do you understand why solving crossword puzzles isn't "just typing", and why it's faster if you have partners and reference materials? Do you understand why you might spend more time thinking than writing, and why sometimes you need to walk away from it for a few minutes if you're ever going to complete it? Then you probably understand programming well enough.

Where's Tim

I've been quite busy of late, partly with holiday season, partly with medical matters (wife's ankle surgery), partly with church, partly with Agile In A Flash, and partly with the series of articles Jeff and I are writing for PragProg.

Last month's PragProg article brought some good feedback and kind words from some of you and we're thankful. We have two more "big topic" articles to go (abstraction and volatility) and then we're back to the stories behind the AgileInAFlash cards (on pre-order via online outlets and expected in January). Please keep up with us there as well as here and at Agile In A Flash.

I'm looking at some new projects next year, hopefully some that pay and some that allow me to improve my chops on open source development. I don't foresee another book just yet, but some writing is definitely in the works.

The only other news is that I dived into Ruby for a little while, and will be chasing that down via the three books I now own. I'll likely be playing with IronPython and other CLR languages this coming year, and I still have to get some Javascript skills together.

It has been a great year, and I expect next year to be greater yet. Stay tuned.