penitent, turbulent, multiplex!

I’ve been using the ExpressionBlend 3 SketchFlow trial lately to drum up some Silverlight prototypes. If you’ve seen the videos for SketchFlow, you probably noticed the little bit where he attached a DragDrop behaviour to a listbox and poof! Everything worked!

Well, that was a bit of smoke and mirrors. That behaviour doesn’t ship directly with SketchFlow at all. You can find it in the Snowboarding sample application and drag it into your project directly if you want, but that only works for WPF prototypes.

After hacking around a bunch of things that I would consider bugs in the Silverlight 3.0 SDK, I managed to port this behaviour to Silverlight. So, if you want to drag and drop items between listboxes in your Silverlight SketchFlow app, this one is for you.

Get it here: SilverlightDragDropCopyItem.cs

You just have to drag it into the [blah]Screens folder of your project, and it will show up under Assets -> Behaviors.

The article that I mentioned in my last post has been published in the Fall 2009 issue of ACM Crossroads:

http://mags.acm.org/crossroads/2009fall

You can jump to it by clicking on the “Career Advice: …” link on the front cover. Unfortunately, I no longer have a print subscription to Crossroads, so I won’t get to see my work on paper. But I know it’s out there

Now to start working on the next one…

I am apparently going to have an article published in the fall edition of magazine which I will leave unnamed until the issue is actually released. I don’t want to jinx it.

I think I’m going to work on the powerlifting article next. I also had a bit of inspiration at the 2009 Toronto Code retreat, where I threw together a solution to Conway’s Game of Life using signal processing primitives from SICP (unfold, map, reduce, etc) in Python. I should probably write that up as well.

Finally, I’ve been putting a lot of my spare effort into a script for a videogame… so looks like the writing bug has hit for realz. It’ll probably get even worse when the sun disappears and I stop spending so much time on the beach.

In day-to-day conversation with other developers, a lot of points of debate tend to surface fairly often. A handful that I’ve run into recently:

1. XML should/shouldn’t be used as a data storage format
2. The best/most maintainable way to approach concurrency for performance is X
3. The best/most maintainable way to approach concurrency for responsiveness is X
4. Object-oriented programming is better than / worse than / the same thing as functional/straightline programming

And so on.

One of the few things that graduate school taught me is that a lot of problems that identify as “new” have actually been treated rather thoroughly somewhere back in the annals of time. It’s somewhat embarassing to have to learn this lesson as a software engineer, I think, since we’re a pretty young field as far as intellectual disciplines go.

I suspect that our ignorance of the past is because a lot of the good discussions surrounding them are in the primary literature, which for some reason tends to bring out a stubborn streak in many of the practitioners I know. I think that by suggesting articles from academic journals, some might feel that I’m being snooty, stuck up, or otherwise just showing off my education. I haven’t quite figured that one out yet. But it happens.

However, I feel like people are missing out. There’s some really good stuff out there. For example:

• To address point 1, the aptly-named Michael Stonebraker wrote a great paper on why XML is a terrible data storage format. (Thanks to Rachel Pottinger, my data management professor and supervisor.)
• When researching point 2, I came across a bunch of wild algorithms from the early 80s for parallelizing problems that appear inherently sequential, like searching linked lists. These were written for the Lisp machines, which had hundreds of 1-bit “processors”.
• When talking about point 3 in an operating systems course, we read a pair of papers (here and here)that each put forth reasons why events or threads were more appropriate for this task.
• Point 4 has been discussed cogently in some very old books, many of which I babble about incessantly (the Structure and Interpretation of Computer Programs, and Object-Oriented Software Construction).

It seems counterintuitive to me that so many current problems could have been so well addressed such a long time ago, but I guess it’s the nature of academia to predict (or invent) problems long before they actually become a pain point. The result of this is summed up nicely by Michael Stonebraker in the paper I linked above:

Most current researchers were not around for many of the previous eras, and have limited (if any) understanding of what was previously learned. There is an old adage that he who does not understand history is condemned to repeat it. By presenting ‘ancient history’, we hope to allow future researchers to avoid replaying history.

I think this one goes without saying in almost any discipline. Having a mentor — someone who is wiser than you in some aspect of what you are doing, and hearing out their suggestions — will always stretch your brain. Of course, it can take a while to find someone you click with and who also has the time for you.

While you’re hunting for a mentor, you can get the next-best thing by reading the writings and the code of “famous” software engineers. Books like Programmers at Work and Beautiful Code are great for this sort of thing. And tons of very clever people write open-source software that you can peruse.

While seeking a mentor is a somewhat obvious way to improve, inverting that relationship by looking for a mentee — even when you’re very green yourself — is, in my opinion, a great way to improve as well. Einstein’s old adage of “You do not understand something unless you can explain it to a six-year-old” comes into play here.

I’ve had quite a few opportunities to teach intro-level computer science and software engineering courses, and these experiences clarified a whole bunch of things for me in a hurry. As I sought explanations and examples that would click well with an entire class, I started to learn what methods of organizing programs in the small would communicate well across a broad audience. I try to carry those lessons over into “real-world” projects, so that other developers can (hopefully) make the appropriate modifications to work I’ve done regardless of their skill level.

Plus, working with people who are just starting their journey is refreshing. Their optimism and the breadth of (often strange) approaches that they take to problems that to us are old hat is a lot of fun.

So, get out there! Give, take, interact. Humans are the interesting part of this craft, after all.