On Not Being a Programmer
I used to be a programmer.
For years I’d sit at some computer or another hacking away at whatever was interesting or required at the time. It’s all I did. I may not have been a Rock Star(tm) or Ninja(tm), but I built stuff that worked and that clients liked. A lot of it.
When development was all I did, there were things that were critically important to me. Languages. Frameworks. Source control. Those sorts of things.
But these days I don’t do much development. At “Fusionary”:http://fusionary.com we have plenty of developers and builders who are smarter, faster and more clever than I’ve ever been. My job now is to make sure projects get done, using the appropriate tools, on time and on budget.
I have a lot to learn.
The first thing I learned since not being a programmer was that the critically important things — aren’t. For example…
h3. Frameworks
I love Rails. Once I started learning Ruby nothing else mattered. We shipped our first production ecommerce site built with Rails before Rails 1.0 was even released. And this was after 40% of it had already been built using PHP. It turns out to have been a good decision. I’m not sure I’d make the same one today.
I firmly believe that happy programmers are more productive. What I no longer believe is that there is One True Language/Framework that makes all programmers happy. We just launched a couple of sites built with “CodeIgniter”:http://codeigniter.com/ and the guys working on it had a ball. It was built quickly, professionally and with no whining about namespaces or inconsistent method names or anything. They just built it. The only thing I noticed was that it was easy to deploy and just worked when doing so. I did miss migrations, but other than that it made no difference to me. That was a surprise. You can build great apps using *any* framework/language. And don’t give me that crap about the poor PHP or .NET guys not knowing what they’re missing. They do, and they don’t. That surprised me too.
h3. Agile Development
Agile development methods work. Or so I’m told. As a developer, they make perfect sense. User Stories, short iterations, code reviews, etc all work great and I understand the value. The problem isn’t in working Agile, it’s _selling_ Agile then living with it. I have yet to run into a client who doesn’t understand the concepts. They seem to love it. I just can’t seem to figure how to execute once they disappear from the process, only to return every week or two with input on things we’ve already implemented without them. And without someone acting as a Proxy for the client who knows _exactly_ what we’re building, it’s back to educated guesses and biweekly demo meetings.
I imagine that I’ll get better at all of this, but right now I’m finding the transition from programmer to manager to be more challenging that I expected. I’ll buy some books, make some mistakes, and keep you posted.