Fog Creek Software, Inc.

Well, I'm now at Fog Creek. I love it here. The benefits they mention in their recruiting materials are all real and all great. I love the food, I love the snacks, I love the flexibility, I love the views of New York and the Hudson.
More important than that, I love the work.

Microsoft

Over the last few years, working on Outlook at Microsoft, I became more and more aware of good engineering practices. At Microsoft, so much of product development is handled by others, that initially, it was easy to sequester myself in my office, write lots of code, then fix lots of bugs, and feel a certain sense of accomplishment. I had to learn what it meant to write code that could be localized, code that was considered to have quality, by the standards there. I also saw lots of code, much of it good and much of it bad. I became very familiar with old code and still managed to forget plenty of code that I wrote after only a few months.
But I also started learning about what good code could be. I started to develop a certain feel for good code, and also started to recognize the natural impediments to writing good code, some of which are inherent in shipping a product that people will buy. I learned about TDD and tried to practice it in my work. I shared the ideas and concepts with my team. I started to get impatient with pace of adoption at Microsoft, while at the same time recognizing some of the reasons it was slow as valid.
As I approached my 6 year mark at Microsoft, I really started feeling like it was time for a change, both professionally and personally. Our family was ready to live somewhere that didn't involve 8-9 months of rain each year. So I started feeling around for jobs. The Fog Creek opening landed on my radar at just the right time and, long story short, I started on September 14th.
One part of that long-story-made-short bears mentioning. After making the decision to take the job at Fog Creek, I was once again impressed at what a great place Microsoft is. My coworkers and management were very supportive of both me and the move. I've reflected on my time there and feel very good about what I learned, what I accomplished, and the products and features I was able to work on. I would definitely recommend it as a great place to work.
I've had a few friends and acquaintances ask me how I went about making this decision, and I felt like it would be good to share some of the reasoning that went into it for others. I'm not going to write a "10 reasons to switch jobs now" list or a "7 reasons small companies are better than large ones" list or a "How to land a dream job in New York City" essay. Rather, I'd like to talk about how I see my career and hopefully pull out some universal principles for any career in software development.

Own your career

First of all, you need to own your career. I'm not going to go into a lot of detail on this one, because any good advice on careers in general, or software development careers in particular, will offer plenty of detail on this one. I just want to call it out as a necessary pre-requisite to all the other ideas.

Know what you want

As my wife will tell you, I don’t normally know what I want. I tend to be pretty ambivalent about a lot of things. About 6 months before this career change, however, I started taking about 30 minutes a day just to think about and write about my career. I went back over all the notes I'd ever written down, all the goals I'd ever considered, all the crazy ideas I'd ever had. I organized them all and tried to figure out what made me tick. This was a pretty simple exercise, easy enough to do before breakfast (what can I say, I'm a morning person). But it paid huge dividends almost immediately. I went into work more excited (still at Microsoft). More importantly, I started to really care about where I would end up. I don't know if my 30 minutes a day strategy would work for everyone, but you really need to become passionate about something, or your career won't go anywhere.
For me, that passion boiled down to becoming a software craftsman. Which leads to another important principle in creating your ideal career: strive to be your very best. I connected with the ideal of a being software craftsman, which is admittedly still being defined. Whether that includes TDD as pre-requisite, or whether that means trying to be a Duct Tape Programmer is secondary to the ideal of crafting the best code possible within a set of interesting, creativity-inspiring constraints.

Broad and deep

A few years ago I had some interesting conversations with a friend of mine about whether education should initially take a student deep or broad. I don’t know that we ever answered that question, but we both agreed that a good education is ultimately both. At Microsoft, as at most big companies, I got to go deep. I learned what it meant to work on a single code base, in a single language. During my 6 years there I worked on two or three major feature areas. So much of the product development and marketing was handled by others, and many of them I never met or knew. I was able to gain a lot of knowledge about a very limited set of technologies, product areas, and functional roles. A big part of my desire for a change, any change, was to do something new. I wanted to come to a small company so I could at least be closer to the sales, marketing, and customer support side of the business. I wanted to change my technical focus, and learn more about new technologies: web development, new languages, whatever. It was time for me to broaden my experiences.

Make incremental improvements

When I told my wife that I had submitted my resume to a company based in New York City, her first reaction was incredulity: "New York City! I never want to live there!".  I assured her it was just for interview practice, because I felt the same way. I bring this up because sometimes our career goals will take us unexpected places. I personally would love it if Joel woke up one day, realized how much more profitable Fog Creek could be if it were based in Fort Collins, Colorado, and decided to move the whole company there. But I doubt that will happen. And that's ok. I realized, and so did my wife, that we weren't going to get the perfect situation at this point (especially in this economy). We knew even before the job search began that there would be some compromises. As it is, I'm extremely happy with the compromises we made, and we'll probably be at Fog Creek for quite a while. I expected to give up more and not get as much. But no, we don't live in New York City. They couldn't handle our three boys, so we're actually enjoying a great place in New Jersey.

Sometimes, be the worst

I know this advice has been around for a while in the body of software development career advice (links!), but that's another reason I made this move, and it's already started to bear fruit. I was by no means the best on my team at Microsoft. But I'd been there a while and I was too comfortable. I knew, coming to Fog Creek, that it would not be comfortable, that I would stretch myself technically, socially, and in other ways. But that wasn't just something I had to live with. It was a necessary change for me, one that I looked forward to. It was time to grow, to learn, to stretch.
In saying this, I recognize that you probably shouldn't go through your whole career this way. It would probably get pretty depressing if you always felt that you didn't quite measure up. Plateaus aren't bad things, they allow us to step back, to look over the things we've learn, to rest and recuperate in a way. And being the best is also a valuable position to be in, when you can mentor others and learn from their fresh new ideas.

And so...

At this point, I'm very happy with the move. I'm excited to be working on Fog Creek's new product, Kiln. I'm just as excited for the new version of Outlook to ship, and am itching to get my hands on a copy of Windows 7.
Life is good.

Whimsical Walk

In my last post I mentioned that I was doing some practice with the binary search algorithm. I wanted to approach it with a slightly different mindset and see what kind of an algorithm that led to. So I decided to think of it as a walk. I would go "visit" locations in the array and see if I should turn right or left at each one. Doing this in C meant that I could do some crazy stuff with arrays - nothing I would do in shipping code, but fun to play with nevertheless. Here is what I came up with:

 1 char ChopWalk(int value, int *array, int size, int *poffset)
 2 {
 3     int walkto = size / 2;
 4     int direction = 0;
 5     char found = 0;
 6 
 7     if (walkto == size)
 8         return 0;
 9 
10     if (value == array[walkto])
11     {
12         found = 1;
13         direction = 0;
14     }
15     else
16     {
17         if (value > array[walkto])
18             direction = +1;
19         else if (value < array[walkto])
20             direction = -1;
21         found = ChopWalk(value, &array[walkto + direction], direction * (size / 2), poffset);
22     }
23 
24     *poffset += walkto + direction;
25 
26     return found;
27 }
28 
29 int Chop(int value, int *array, int size)
30 {
31     int result = 0;
32     if (ChopWalk(value, array, size, &result))
33         return result;
34     else
35         return -1;
36 }

Practicing Binary Search

So for the last couple of weeks I've been practicing the binary search algorithm, as laid out by Dave Thomas here. I've done both iterative and recursive variations in C++ and then in C. I love the value of katas for learning new languages and features. I know both C++ and C, but doing this simple problem in both programs allowed me to work on learning new areas in each. First, in C++ I took the time to use the standard template library (stl), because I'm not very familiar with it. I just used vectors in my tests, but it helped me to become familiar with the stl documentation and the concepts of iterators as used in the stl.

Next, I did the same variations in C. This was fun because C is so basic, and it's been a long time since I coded in straight C. You don't worry about concepts like objects or functional programming (though they may help you think about the problem). It gets you really close to the underlying physical model of computation. You're forced to think more about how the memory is laid out, and how the algorithm takes advantage of that, whereas with C++ and the stl the whole problem and the solution are more abstract, just slightly more removed from hardware.

In addition to the languages themselves, it's also a chance to practice my use of tools. I used the work to hone my skills in vim, to understand our build system at work more fully, and to consider testing frameworks.

Practicing Prime Factors

Uncle Bob's tweet from a few weeks opened my eyes to the value of practice in honing my development skills, and led me to read a lot more about practicing and code katas. One of the things I love about having a kata, like the prime factors kata, is that you can focus on different skills and techniques each time through. You can do it in different languages, with different testing frameworks, using different text editors or build systems, on different operating systems, etc. I've done it a few times in the last few weeks, mostly in C++ (my current language for work projects). But I've used Visual Studio, vim, my work's build environment, and other variations. I still haven't used a decent testing framework, but that's one I want to add.

Having gone through the prime factors kata a few times now, there are some changes that I feel should really be made near the end. Ok, the rest of this post isn't going to make much sense until you at least read through the prime factors kata. Go do it now.

Commenters rightly pointed out that having the additional

if (n > 1)

clause added in test 4 isn't intuitive and violates the TDD principle of just adding enough code to make the tests pass. But they then added the caveat that without it the step to loops and the candidate variable in test 7 is pretty big for the refactoring step, mostly in terms of the mental leap. I agree.

But if you really do the easiest thing you can as you add tests, you don't run into that problem at all. The key is when you get to the test for finding the prime factors of 9 (i.e. the seventh test in the slides). The slides have you first creating a variable, candidate, to represent the number 2. This may makes sense as a refactoring step done before writing this test, but lets ignore that for now, and assume you haven't done it. Then the easiest way to get the seventh test passing is just to copy the entire while loop below itself and change the 2's to 3's. Not only is that dead simple (Ctrl-C, Ctrl-V), it also makes the following steps much more obvious. At this point it's easy to see how important the candidate variable is, so you create it, and increment it between the two while loops. Then the two while loops are identical so you just nest them inside another while loop. The remaining refactoring work to for loops is the same as the slides.