#ifdef

What We’re Learning

Michael Levin, of the NFJS tour,  ate a box of questions for breakfast. We need a side of answers to go.

My greatest take away from BarCampRDU this year was the Coder to CTO session. It wasn’t the session itself and I’m not particularly interested in being a CTO. It was something that was said.

Know Why You’re Doing This.

Is it for money, prestige, time, leadership, recognition, location, independence? Whatever. There isn’t a wrong answer. Just know why you’re in the game because that’s how you measure success and also how you frame the disasters. It hit me like a ton of bricks.

For those of you who know me well, you know that I left my startup in March for a more traditional enterprise job. After the head smack in Saturday’s session, I realized that I haven’t been completely honest with myself about what and why. Honesty is a quality that is at the center of the best personal relationships I have. So why is it so hard to come to terms with it solo?

I decided to turn the statement inside out and think about things and situations I can’t do without; just to see what I can learn about myself and see if I can get a little closer to knowing the whys.

• Education – I’ve worked in many so many interesting problem domains: machine vision, GIS, image processing, interactive television, telecommunications and network security. Truly, one thing that has made work life enjoyable is learning some of the intricacies of these spaces. Just can’t give this one up.
• Build automation – If our little startup can automate network encryption appliance builds in an embedded C++ environment, then I don’t see any reason why your Java enterprise project can’t do that and more. Not negotiable. Transparency needs to include the build status.
• Test First – For me, test first is good enough. In an embedded environment, our compile-test-edit cycle just wasn’t fast enough to create algorithms with TDD. I’m cool with that. But, there’s no way your enterprise development environment with the fancy IDEs should not have unit tests. It’s just too easy these days not to do them.
• Agile Interaction – The emphasis just has to be on shipping quality code and not on burnt offerings to the process gods. There’s so much to say about this point. I’ll just say that I need to be around people that get this concept and five minutes of conversation will get me there.

So really… Is this news to anyone? Because I was working in an embedded environment with a strongly typed language, sometimes I thought that maybe we weren’t keeping up with state of the art. But, we had check in builds, full nightly integration builds with unit test execution and live network verification. We would have automated the regression tests too, except that many of them relied on unprogrammable test gear. Our system test group watched the nightly build results and pulled builds they wanted to test and release.

Now I come up for air and see the state of the builds in some local companies, it just makes me want to pull my hair out. Thanks to those of you who shared your horror stories. I had no idea. But I am glad your frustration has driven you to seek some solutions.

How did I do? At least I can refocus on the things I can’t do without. I need a few more quiet hours to reflect on the why.

I’m no stranger to language refresh. I’ve gone from assember to C, then C++ to Smalltalk to Java back to C++ with STL and Boost and recently back to Java. My current infatuation is Groovy. There’s so much possibility there to reduce the development friction of Java apps. But as Steve Yegge put it recently, you get to a certain point where you really need to be careful about what you take on.

If you have any ideas, thoughts along those lines to help me out or want to share a similar decision you’ve made, I’d sure love to hear about it. Cruise over to my new tangle and drop me a line. Thanks in advance.
No foreheads were actually harmed in the construction of this journal entry.