Thoughts on Diversification

I recently watched Rob Conery's talk from NDC2010 on his concerns about Microsoft. It's a good talk, and if you work with Microsoft tech at all (especially it it's your main technology, as it is mine), then you owe it to yourself to watch it.

Done? Good.

Rod describes the talk as 'incendiary'; I disagree. Personally, I didn't think anything in there was off the mark (although he should have left out his Twitter fight over Azure pricing, but whatever). He's right – Microsoft, overall, is not nearly as interesting as they used to be. He implores 'Microsoft developers' to look outside of Microsoft at what else is out there, and wants Microsoft to start pushing boundaries again.

None of this is really a surprise to those of us who have always had a foot outside of the Microsoft world; hell, the only reason I got a foot in the Microsoft world is because it paid the bills. I've been a Python fan since the first time I saw it, 7 or 8 years ago; one of my co-op jobs in University was working for a (sadly, now defunct) company that integrated Jython into the management software for their hardware platform. Before that I taught myself C++ after cutting my teeth on QBasic. I used Java and Ruby in University courses; the OS of choice was mainly Linux.

Knowing only one tech stack is extremely limiting and, honestly, foolish. Focusing on one is often a necessity dictated by needing to eat, but you should be keeping an eye on what other communities are doing, because you never know when it might be useful. It's truly unfortunate that many programmers didn't know about the beauty of functional programming until Microsoft introduced LINQ and F#; I've been using those techniques in Python for years and missed them horribly when working in pre-3.5 C#.

This doesn't just apply to programming. Some people recommend learning one new programming language a year; I agree, almost. I think you should learn one new skill a year. Last year I built myself an office, doing all of the carpentry, drywall, and electrical myself (with a little help from friends and family, of course). This year I'm learning how to cook properly (and have developed an unhealthy obsession with Alton Brown). Next year I plan to finally learn how to play the guitar and understand music theory (we'll see how that goes). Someday I hope to rebuild a car.

Step outside your comfort zone. Learn something new. What you find just might surprise you.

Biting Off More Than I Can Chew

I was going through the “Repositories” folder on my machine, looking at all of the stuff I’ve downloaded since, well, the last time I went through this exercise. This time around, a lot of it is stuff I’ve tried to get working on IronPython. Here’s a sampling:

• Django
• setuptools
• Trac
• Genshi
• Mercurial
• SCons
• CherryPy
• docutils
• moin
• pygments
• pymarkdown
• nose
• sqlalchemy
• IronRubyMVC

On top of that, there’s the stuff I wrote: NWSGI, IronPython.Zlib, adonet-dbapi, and more.

Unfortunately, I just don’t have time to track all (or even some) of those any more. Debugging things is also pretty difficult – IronPython is getting good enough that the only bugs are really obscure. It probably takes me ten times longer to find a bug and isolate it into a testcase than it does for Dino to fix it. There are other things in real life that have changed as well, drastically reducing the time I can spend on this stuff.

Somewhere along the line I developed a weird sense of duty to make that list of stuff work on IronPython, even though I didn’t have a use for most of it. Realistically, getting all of that to work, and finding all of the little corner cases of Python that they exploit but IronPython doesn’t implement, would be a full time job.

So, I’m cutting back. Way back. IronPython-wise, I’m only going to focus on the stuff I’ve written (and yes, I will be getting Beta 2 of NWSGI 2.0 out soon), and Iron[Ruby|Python]MVC . For me, those are going to be the most immediately rewarding, and I can also stop worrying about the others.

Now, with all of that said, I have an offer: if anyone wants to work on the top part of that list (up to and including SCons), I’ll help get you up to speed on some of the issues with those programs, and some of the tricks involved in debugging them (hint: Debugger.Break). This will be  limited-time offer, valid until I forget the details of the program in question. I really want to see these things compatible with IronPython, but I just no longer have the time to do it myself.