Remote Teams and Travel

In my current position the rest of my team is located in a different office. I’ve been the only remote member on the team for about a year now and I just got the opportunity to travel to the main office where the rest of my team is. The office with the rest of my team is our headquarters and is much much bigger than the office I work out of; where I work it’s almost exclusively people working on a different but related product. So while I was at HQ,I also got to meet a bunch of people outside my team I had interacted with remotely for years, but had never met and knew only as a voice on the phone and a tiny profile picture.

My team has done some video conferencing before, but we didn’t use it for the ad hoc communication that goes on through the day, just the larger scheduled meetings. But then there was very little of the camaraderie that builds a strong team. Part of it was that there was a lack of meeting space in their office, so when you’d get to your meeting the last meeting would still be going on, and you couldn’t get the room for 5 minutes then another 5 for them to get out and you to get set up the videoconference. Which then meant your meeting would be running long, and causing trouble for the next group, and you’d have no opportunity for lingering teambuilding conversation.

While I was at HQ, we did a bunch of live whiteboarding sessions to plan out the next steps on various problems we’ve been working on. This worked great and we accomplished a ton on those problems. This was something I felt that we had been missing while I was remote. We had tried a couple of virtual white board tools but they all had various problems ( was the nicest of those we tried but it lacked pointing, which became a problem). Figuring out an effective solution to the design aspect was the largest technical hurdle we faced from me being remote.

The biggest overall hurdle we have faced was the social aspect of team building. Being the only remote person on the team, I became a bottleneck since the rest of the team was colocated. This was magnified since most of the other teams in our department were colocated with my colleagues at HQ, as well as most of the other departments we worked with. Having so few remote team members meant that we didn’t have tools and processes to really deal with working with remote teams and people. I know I had never worked with a remote team like this before, and it has been a challenging experience.

The overall travel experience to HQ was a positive one, both on the social and technical aspects of the trip. Although it makes me miss more the social aspects going on day to day, maybe we’ll do better to maintain the social aspect now that we had the opportunity for face time than we did trying to create them remotely.

2015 Year in Review

I started this blog this year to give back to the community. On a personal note, I’m pleased with having succeeded at writing a post every week. I had been aiming for posts a little bit longer than most of what I wrote (I was aiming for 500-750 words a piece but seemed to hit 300-500 more consistently).  I had hoped to post more technical content like the F# posts but I ended up having less opportunity for personal projects than anticipated, and nothing from work would have provided  enough to post about without a 3000 word introduction to provide context.

I wanted to show some insight into what the reception has been since I started back in September. WordPress collects some basic stats on the blog.


The weird thing that jumped out to me immediately is that I’m getting much more traffic from Bing than Google. The bulk of the traffic being for the article I wrote on F# Koans, but that seems reasonable since people looking for information about F# would be using Bing. Also when searching for “F# koans” on Bing I’m the second result, whereas on Google I gave up looking for it after page 15. The “Michael O Church” referrals were all from a WordPress linkback, where his articles that I linked to got footers that linked back to me. The twitter traffic was all for the Checklist Manifesto post.

Overall, traffic was pretty low with 41 people looking at 62 pages. I didn’t do anything to promote traffic, which seems like a good reason for traffic to be so low. I don’t know how this compares to other new blogs. I’m not sure what things I could or should be doing to promote traffic. I think that I should link the blog in profiles I have in various places, which could drive more traffic.

I’ve enjoyed the writing all of these posts. Writing out my thoughts on various topics have helped organize them, especially with the Javascript ecosystem post. I’ve only had one post I tried to write where I couldn’t articulate my thinking clearly and gave up on it (and I’m planning on going back to it eventually.) I wish that I had started doing this years ago.

I’d like to share some of my blogging goals for 2016. I want to keep up the weekly pace – the list of ideas for posts I keep has been holding steady in length although it seems to be accumulating some more complex topics. I want to try and do some more technical posts, but those require more inspiration/preparation. I want to find a way to describe some of what I’m doing at work since it is interesting, but without too much context. Thanks to everyone who has supported me so far, I hope those who have read it have enjoyed it, and here’s to a great 2016!


My first car was decent car when I got it. I had it for years, and I didn’t take real good care of it. Part of it was because I didn’t have a ton of money and wasn’t inclined to spend it on the car, but a lot of it was because I didn’t know much about taking care of it. I changed the oil, but I neglected a bunch of other work on the car. This all came to a head when the air conditioner broke.

I could put a bunch of money into the car and fix the air conditioner, or I could live without. It was early fall, I figured I could wait until next year to deal with it. The next year rolled around and as spring started warming up I started to figure out ways to deal with the lack of AC. I’d park the car where it would be shady when I was leaving work. I’d crack the window when I parked it. I’d cruise around with the windows down. Summer came and it wasn’t great but I adapted to it. There were some unpleasant days on the highway stuck in traffic but most of the time it was livable.

The second and third years went similarly. I had just gotten used to it. My wife wasn’t enthusiastic about going places in my car without AC in the summer, but we’d take hers and everything was fine. My friends didn’t know about it until the second year and they all thought I was crazy when they found out.

This relates to software development with how we all face a point where we have to choose between continuing to do what you are doing or switching to something new. You may have gotten used to your screwy build process or awkward internal library, but everyone else who sees it thinks you are crazy, just like my friends thought I was with the car. Sometimes leaving your broken AC alone is the right call, but often you need to fix it to truly improve your life.

I never ended up fixing the AC in that car. It did end up having obvious costs sometimes. There was a job interview I ended up at all sweaty and I ruined some groceries, but overall the savings up front may have outweighed the costs for me in this situation.

Assuming you understand all of the costs that you are paying, you can try to make a reasonable decision. That’s easier said than done. Often times these costs manifest as infrastructure failings and are hard to see since they cause minor friction in day-to-day activities and not as more obvious standalone issues. If you are you used to setting up servers by hand, not having something like Chef doesn’t appear to be a problem. To find these types of costs, you need to talk to outsiders sometimes.

This can be interpreted as the blindspot from the Johari window. The thing that is obvious to most people but that you can’t see. This can also be described as boiling a frog. If you put the frog in a pot of boiling water, it will jump out. If the frog is put into cool water and heated the frog will stay in the water and be boiled. You can grow into a situation that you would never have tolerated to start with. Try to take this understanding and reevaluate situations from an outsider’s perspective. This can help you to understand what you have and fix the underlying issues.

Actually About Refacotinrg

I wrote this little library recently to help generate some random dates. I made seven different commits to the project. I want to discuss what I did in each of them and the process to get from concept to completion.

In the first I knocked out a basic concept with a few tests, to show it probably  worked. It had one extension method, one helper class, and two tests. In the second commit I added another extension method with two more tests. In the third commit I added a third extension method and three more tests. This is all normal stuff, the fourth commit is where the interesting stuff starts.

In the fourth commit I refactored the before and after methods to reduce the duplication between them. That’s the obvious part that most people would do. I also refactored the tests that were generating a bunch of random dates to use a common helper method. This is the part that most people miss in Red-Green-Refactor – they refactor the business code but skip the test code.

The fifth commit refactored to allow chaining multiple conditions together. I put in an implicit conversion from the builder to DateTime. I was using the builder pattern, but for whatever reason I didn’t call it a builder at the time. So, I changed it to call it a builder  in the sixth commit along with updating it to allow me to generate multiple dates in the same range with one builder. Previously, the builder would only generate one date so the implicit conversion worked reasonably.

In the seventh commit I added overloads to the various extension methods for DateTime? as opposed to just DateTime. It was a little enhancement but it made it much nicer in some situations by pushing a bunch of null checking into the library itself.

There’s nothing revolutionary in either the software or the process but often times when talking about writing software, we talk in terms of  fully formed libraries springing forth from the mind and not about the arduous process that you go through to get there.

Agile process and local maximums

Changing your process to make it more efficient is a good thing. Changing it to make it less efficient may still be needed. Imagine your process as a function – you make changes along the x-axis and the y-axis is efficiency.


Imagine you are at the point where the arrow is pointing, looking a little to the left or a little to the right and you seem to be in a great place. Since you are at a temporary peak, any change is immediately  a little bit worse, but way over to the right after a more significant change there is a much, much better place to be. You need to see it and make the leap from the current comfortable local maximum to the other slope.

Think of it like a genetic algorithm. In a genetic algorithm you need to avoid the local minimum, to get to the optimum solution. You attempt to keep a broad stock of algorithms to breed with, to try and get past the local minimum. It is also easier to maintain a stock of algorithms rather than a stock of different processes. In the process world it isn’t quite as simple, since there isn’t just one fitness function to maximize and every team is different to a certain degree. But, you can pull different ideas from outside your organization, or from other teams inside your organization.

The other way to consider things is that you are in a good enough position on the x-axis you can  innovate on the z-axis and continue up the manifold. As an example, say you have a great setup for automated testing, so instead of changing that, instead you try and migrate from continuous integration to continuous deployment.

This can still result in interlocking processes that each depend on one another to succeed. If you have a strong manual testing culture, it works well with a slow release cadence and a rigid change control process. Trying to build a continuous delivery pipeline under those conditions is going to end in pain and failure. Trying to automate testing and relaxing change control could be really valuable even though the immediate impact of trying to automate testing is a slow down in feature creation.

Recognizing the prerequisites to an improvement and tackling these things in a reasonable order makes sense. It also lets you focus on making a particular change rather than blowing everything up at the same time. But you still need to look out from your hilltop and find the next mountain to climb.