Glimpsing the garden over the wall

Monday 2 October 2006

Luke Plant has written a plaintive post about the difficulty of learning nice programming languages, but not being able to use them at work: Why learning Haskell/Python makes you a worse programmer. I know just how he feels, because I was in that position up until a year ago. It’s difficult knowing that there are better tools out there, but having to work with what feels like stone axes during the day.

In my case, I was using C++ and C# during the day, and Python at night. I found a few ways to cope with the distance between the two worlds.

Get inspired. Sure, you can’t express yourself in C++ the way you can in Python. But you can try to bring some of the dynamic or agile ethos to your static waterfall world. Maybe you can think about using functions as first-class objects, or start an automated testing effort. It’s difficult, but if they’re good practices in the open-source world, they’re good practices in your environment. Be the change you want to see in the world. It’s not all about what language you use, it’s also what you do with it.

Side projects. Anything I did on my own time, I did in Python. This allowed me to explore the new world, and to express myself in it. Examples of this work were Nat’s World, and the software that runs this blog.

In some ways, side projects only make the tension worse. Your fun project scoots along nicely with the new tools, while work continues to be difficult. Part of this may be because of the tools, but keep in mind: there’s a reason they call work “work”. Side projects are always more fun than real work, and you may be mis-attributing the reason for the joy. Maybe it isn’t Python that makes the fun project fun, maybe it’s that you get to pick the project, and you don’t have to deal with Deadwood Dirk in the next cubicle! Your side project has no deadlines, no business goals, and so on. Side projects are a good way to stretch your skills, focus on areas of interest, expand your influence, and build new connections. But they aren’t “real” in the hard ways that work is.

Tools. When an opportunity arose at work to create a tool, I wrote the tool in Python. This is how Cog came about, for example. There’s bound to be some friction at work when the tool is introduced, since others there may not be able to maintain it. They may even view it with downright suspicion because it’s written in a “toy language”. But if writing it in your dream language gets it built when sticking to C++ would keep it from being written, then you should write it in Python and present it as a fait accompli. If it does a useful job, it will be accepted, and you’ll have infiltrated the fortress walls with your language of choice.

Network. Read the newsgroups, read (or write!) a blog. Join a Meetup group. You can hang out with people that think like you do, and you won’t feel like an outcast anymore. And they’ll probably sympathize with your crummy work stories.

Get a new job. This of course is easier said than done. But jobs using the new languages and environments are more and more prevalent, and may be more possible than you think. And if you do get a new job, you can finally test your theory that work would be easier if you didn’t have to deal with C++ (or C#, or VBscript, etc).

Yearning for better tools and languages is nothing new. Even once you get your dream development environment, you’ll wish it were better. Doing something about it is the challenge.


> Get a new job.

A good place to start:

And if I may humbly suggest here as well:
> They may even view it with downright suspicion because it's written in a "toy language".

Then tell them it's just a prototype. Set up a big meeting to see who has the resources to re-write it in a "proper" language. ;-)
One thing I'd add to your list is that depending on how your job is structured, some "side projects" may be able to be part of work -- things above the level of tools. Part of my job (at a technical school) is building internal and external facing web apps. The first revamp of the main site was in PHP because that was a "safe" choice given our server limitations at the time. Everything since then (an alumni site and two internal-use sites) has been developed in Django /Python. The first one of those was small, side-project-like, because even I wasn't sure at the time (late 2005) that this was going to be a viable production strategy, but now I'm sold and itching to convert the main site itself.

All that said, I may not be a good test case -- I suspect I could develop our entire website using Seaside or Bourne shelll scripts and nobody except our IT guy would know the difference, as long as it worked.

I also like Ed Davies' crafty prototype strategy.
I never said Python was a "toy language" and even in my book you would have lost points if you wrote it in VBScript!

It might have been me that suggested an approach using vendor specific C++ compiler enhancements like [cog attributes] - This most certainly would have involved more pain and suffering as well as resulting in a narrow domain of applicability but we all know how projects like that build character.
Ned you said it yourself in an earlier post.
The new generation of languages/tools make the easy part of building your application (making it do what you want to do) easier.
The hard part (figuring out what your application should do, in all cases)
remains as hard as it ever was, Python, Erlang, C# or whatever...

At the end of the day it's all 1's and 0's, eh?

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.