A couple of days ago I was talking to a friend and he asked me what some of the fundamental things were that caused me to change jobs. After thinking about it for a while, I think I can start to answer it in reverse - what new things I have seen that I hope every organization I work for from here on out will have.
The first thing that came to mind is just doing things that make sense. This seems like it might be obvious and something that people do anyway, but I assure you, it is not. It's not to the extent that I named this very blog after that very thing - does having a cement cutting board that will dull your knives really make sense? Yet I used one every day for months.
One of the biggest tangible things I can think of is using tools that make our jobs as developers easier. Making our jobs easier = happy developers. We use IntelliJ instead of Eclipse since you get a complete polished package with awesome refactoring tools. We (mostly) use RubyMine instead of TextMate for the same reasons. We use git instead of subversion because you get a much more powerful feature set. We use github instead of our own server so we have less operations overhead. We use rails instead of Spring/Struts/Django/.NET/etc. because we feel it gets the job done easier and faster.
The list goes on and on, and it's always a work in progress, but that's what's so great about it. If a new tool comes along that we feel will significantly make a difference, I guarantee you it will show up on peoples' machines right away.
The point of this isn't to say "you need to use tool xyz", but simply to say that it feels great to work for a place that is willing to invest in a toolset that lets you simply get work done.
It always baffled me before when I was told that I couldn't use a certain tool that had a cost involved (often under $100) because it was too expensive. If that tool had saved me even half an hour of time total the company would have broken even at the rate they billed me for.
One of the biggest examples of this I can think of involved code reviews. At my last company we had always tried to code review everything but had trouble making sure we were diligent about doing them. One day I decided that we needed something better. I started researching code review tools and found one in particular that looked really promising. There was a 30 day trial so I got it up and running in about an hour and we started using it on my team with great success.
The issues started when we tried to convince Those With Money to spend $500/seat on this tool. I completely understand wanting to make sure that you invest your money wisely, but the battle that ensued over this tool, when it had rave reviews from any engineer that used it, was lengthy and ended up with everyone upset and exhausted by the end.
The funny thing is, if this tool could prevent everyone using it from writing one bug every 3 months the company would have broken even on the cost in the first year of using it. (These numbers are based on their calculations.) We had already seen results much better than that in the first 1 month trial, and had already expressed other benefits such as knowledge transfer, reduced time bringing someone new onto a team, and cross-team reviews to name a few. Yet still the battle was fought every day for weeks until a decision was finally made.
(By the way, if you are doing code reviews, I highly recommend using Code Collaborator. It is well worth the price tag and was called out by others as the single biggest improvement in our engineering process that year.)
Probably the craziest situation that I have ever seen happened at another company I was working with. They had a development team of about 10 people, and all the engineers were given mediocre laptops as their sole development machines. To top it off, they were running a heavy webserver (Weblogic), had only 2GB of memory, and had 5400 RPM hard drives with software encryption used on every read/write.
To give you some data points - publishing code changes to the Weblogic server on my dev machine, a fairly pimped out Mac Pro, took about 12 seconds. To publish changes on their laptops took around 7 minutes. Really. I timed it. Twice.
This means that _every_single_code_change_ they did took them 7 minutes before they could see and test it. It was amazing to see their management continually shoot down requests for new machines and then complain about how unproductive this team was!
I guess what I'm really getting at, is working for a company that honestly supports you in getting your work done is an amazing thing. Does it cost more money up front? Yes. Will it pay off in the end? Absolutely. Is it awesome to get to use tools, languages, and frameworks that the developers like? Oh yeah.
So, until next time, keep your toolkit close and your knives sharp.
Monday, July 26, 2010
Wednesday, July 21, 2010
Why I like pair programming (and why I'm not leaving)
A few friends have pointed out a blog post from someone who recently left Pivotal Labs due to the fact that he didn't enjoy pair programming full time. (It's well worth the few minutes of time to go read it.)
I read through a bunch of the comments on the blog and the linking reddit page and most of them started as "Well I've never done paired programming but..." or "That's stupid! I did pair programming once and...", so I figured I would write up my own reply as someone who has done pair programming full time for around 4 months now.
Mark's post has gotten me thinking a lot about the whole pairing thing and whether it is all that it's cracked up to be. I'm always trying to reevaluate the practices and techniques I'm using, even if I do work for a place that has mandatory pairing on my agenda. (For the record, a few months ago there was a company wide forum where everyone reevaluated as well. The result was nearly unanimous for pairing full time.)
One of the biggest arguments that I heard from the post was that pairing doesn't allow for that sort of reflective, meditative approach to programming. You know, those times when you have a big problem in front of you and you need to spend at least an hour or more thinking about it and coming up with a wonderfully elegant solution. Some people are better at this than others, and Mike seems to be one of them.
In fact, my biggest challenge with pairing is probably the same thing. I like to think I'm pretty good at that technique myself, and I've had my share of cool ideas that have paid off from doing things that way.
However, something just doesn't sit right with me about that. Sure, that lone ranger style of coding can be a lot of fun, and you can feel very proud of your results at the end, but I've found that when pairing you almost always arrive at solutions that are just as good, and often better the first time around than doing them by yourself.
Just last week, my pair and I had a problem where I had a vision of how I thought a part of our system should work out. Part of me was screaming, "I know how to do this... I don't want to explain it, I just want to go off and do it by myself and get him to review it when I'm done!" However, because I was pairing, I found that my pair had some great insight into the problem, and, even though the vision was still mine, the end result came out way better than it would have if I had done it on my own (and I learned a lot from my pair along the way!)
I think that we often overestimate how well we do things the first time. Looking back at some of the code I've been the most proud of, I could convince myself I do it great the first time around. But the reality is nearly every single one of those things has been through a number of revisions that has gotten the code to the state it is in today. Had I paired on those features, I'm sure they would have ended up in a better place more quickly.
Ultimately, I think the pill I've had to swallow about this has been to give up the self for the greater good. As I mentioned, it can be a lot of fun and feel very rewarding to go off and do some meditative programming, but is that what is really best for the project? For the team? For your client? Yes, great things can come from that, but I've seen time and time again that you get to a better place faster by pairing. You also spread knowledge between team members faster, write fewer bugs, and generally stay more on course by writing less unnecessary code.
Additionally, I find the extra knowledge and learning I get from pairing helps make up for the lack of satisfaction I used to get from being the lone coder. There are many ways to collect paychecks as a programmer, and I can't fault someone like Mark deciding pairing isn't how they want to do it. But for now, I've decided to try to give up a bit of my pride, drink the kool-aid, and embrace pairing and the team centric atmosphere it creates. I can't ignore the results I see every single day of being more productive and having a better product to show for my efforts. Obviously you will have to make your own decisions for yourself.
P.S. Here's another post from a Pivotal person on the same topic. Also worth a read.
I read through a bunch of the comments on the blog and the linking reddit page and most of them started as "Well I've never done paired programming but..." or "That's stupid! I did pair programming once and...", so I figured I would write up my own reply as someone who has done pair programming full time for around 4 months now.
Mark's post has gotten me thinking a lot about the whole pairing thing and whether it is all that it's cracked up to be. I'm always trying to reevaluate the practices and techniques I'm using, even if I do work for a place that has mandatory pairing on my agenda. (For the record, a few months ago there was a company wide forum where everyone reevaluated as well. The result was nearly unanimous for pairing full time.)
One of the biggest arguments that I heard from the post was that pairing doesn't allow for that sort of reflective, meditative approach to programming. You know, those times when you have a big problem in front of you and you need to spend at least an hour or more thinking about it and coming up with a wonderfully elegant solution. Some people are better at this than others, and Mike seems to be one of them.
In fact, my biggest challenge with pairing is probably the same thing. I like to think I'm pretty good at that technique myself, and I've had my share of cool ideas that have paid off from doing things that way.
However, something just doesn't sit right with me about that. Sure, that lone ranger style of coding can be a lot of fun, and you can feel very proud of your results at the end, but I've found that when pairing you almost always arrive at solutions that are just as good, and often better the first time around than doing them by yourself.
Just last week, my pair and I had a problem where I had a vision of how I thought a part of our system should work out. Part of me was screaming, "I know how to do this... I don't want to explain it, I just want to go off and do it by myself and get him to review it when I'm done!" However, because I was pairing, I found that my pair had some great insight into the problem, and, even though the vision was still mine, the end result came out way better than it would have if I had done it on my own (and I learned a lot from my pair along the way!)
I think that we often overestimate how well we do things the first time. Looking back at some of the code I've been the most proud of, I could convince myself I do it great the first time around. But the reality is nearly every single one of those things has been through a number of revisions that has gotten the code to the state it is in today. Had I paired on those features, I'm sure they would have ended up in a better place more quickly.
Ultimately, I think the pill I've had to swallow about this has been to give up the self for the greater good. As I mentioned, it can be a lot of fun and feel very rewarding to go off and do some meditative programming, but is that what is really best for the project? For the team? For your client? Yes, great things can come from that, but I've seen time and time again that you get to a better place faster by pairing. You also spread knowledge between team members faster, write fewer bugs, and generally stay more on course by writing less unnecessary code.
Additionally, I find the extra knowledge and learning I get from pairing helps make up for the lack of satisfaction I used to get from being the lone coder. There are many ways to collect paychecks as a programmer, and I can't fault someone like Mark deciding pairing isn't how they want to do it. But for now, I've decided to try to give up a bit of my pride, drink the kool-aid, and embrace pairing and the team centric atmosphere it creates. I can't ignore the results I see every single day of being more productive and having a better product to show for my efforts. Obviously you will have to make your own decisions for yourself.
P.S. Here's another post from a Pivotal person on the same topic. Also worth a read.
Subscribe to:
Posts (Atom)