@Mark:
I worry about the same “when you leave” problem at my job. I work pretty independently in a variety of languages on a variety of projects. I love the freedom and flexibility this gives me, but it also scares me. I can’t expect anyone else to pick up all the work I currently have when I leave. I can tell you though, that coding for the lowest common denominator is not the answer.

Code well and demonstrably expect others to code well. Simply expecting more of people won’t get results. They need to know you expect greatness, and to see that you are willing to work with them to do it.

Seeing how things have been left here after others’ departures, I now only expect that certain people will pick up certain parts of my workload and code base upon my departure. I also have come to accept that someone refactoring my code or even rewriting my apps isn’t bad. It isn’t my ideal, but hopefully they’ll improve my algorithms if not my code, learn something from my code, or at least wait till requirements have changed to start in on it. It is good for them to have my model of how something can be done, but my way isn’t the only good and reasonable way. As long as their way still produces solid code that meets requirements, it doesn’t really matter to me.

By my guess, I’m still many years away from leaving, but I’ve already started making premature, but conscientious decisions about who I would pick to take on which of my projects and have started using them individually as my resources for bouncing ideas off of and after I make a design decision, I let them know, usually in an e-mail what I chose and why. In addition to my regular documentation, which I often create from these e-mails, he or she now has a linear chain of reasoning on the design decisions for the project that I would hand them if I needed to. If they leave before I do, I still have that same chain and can bulk forward it to someone else, or just bundle it into the regular docs as an added resource.

I’ve also started a lunch group where once a week someone presents a new skill or paradigm they’ve learned in the recent past. This has varied from lesser-known keyboard shortcuts, to AHK scripting demos, to better ways to talk to people (“Hey, are you OK today?” is very pragmatically different from “What’s wrong with you today?” even though they’re semantically very close).

Aside from the obvious benefits of learning new things and networking, this lets me see who else is interested in learning for the sake of learning and what their interests are. These are the people I would want to pick up the more interesting and challenging things that I leave behind. They also turn out to be really cool people to eat lunch with.

@~

What you’ve described of your journey reminded of something Alan Kay said in “The Early History of Smalltalk”, a paper he wrote years ago:

“A twentieth century problem is that technology has become too ‘easy’. When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can. Couple this to even less sophisticated buyers and you have generated an exploitation marketplace similar to that set up for teenagers. A counter to this is to generate enormous disatisfaction with one’s designs using the entire history of human art as a standard and goal. Then the trick is to decouple the disatisfaction from self worth–otherwise it is either too depressing or one stops too soon with trivial results.”

I have a couple questions.

It sounds like you found a company that was willing to throw away the legacy stuff and start fresh. How did you convince them that you were the one to help them do that? I would imagine with a resume that only had prior work on typical database apps. that you wouldn’t come across very convincingly. Did they have someone who was perceptive interviewing you who could see that despite no prior experience with doing this on your part that, “The Force is strong with this one”?

You talk about being “the lone developer”. I’ve explored a corrollary of this idea: What if you leave? Who will carry on the work you started? I think you have the right idea about what you’re doing. It sounds like you have advanced the “state of the art” for the company you work for, and that’s definitely a good thing IMO.

I had a conversation with a friend of mine last year kind of along these lines. He thought the whole exercise of learning more advanced computing through software was futile, because while I may be smart and able to get this stuff, 98% of the programmers out there are totally unaware of what any of this stuff means (commonly referred to as “code monkeys”). He said that “when you leave–and you WILL leave,” they’re not going to understand a wit of what you wrote, and they’re going to just scrap it and use typical run-of-the-mill solutions instead, because that’s what they understand. My question about this is how do you leave a legacy behind so that “when you leave” there will be people to replace you who will continue the work you started? That’s a big question I have, and I think it’s critical for strategies like yours to succeed. I wish you much success!

You ridiculous monkey. Of *course* you’re one of those guys. The tagline of your blog:

_(notes from an average programmer studying the hard stuff)_

No surer sign than that of the presence of “one of those guys.” (Or girls.) There’s no such thing as programming geniuses. We’re all average programmers, and some of us work on the easy stuff, and some of us work on the hard stuff. Keep working on the hard stuff long enough, and people will go “wow, you’re a programming genius.” Because they think programming geniuses exist in the first place. The whole point of the idea of a programming genius is that it’s an excuse not to work on the hard stuff. There’s really *no such thing*.

You’ll see it happen in a couple years, and you’ll go, “Wow. Hunh.”

See you.