Nothing like a long 3-day weekend to help forgetting about the old problems from your previous job. This should help making room for the upcoming avalanche of new information and ramping up on the new gig.

Show me where the North is

I'm also taking this short interval to revisit my previous experiences of changing jobs and what waited for me on my first few days. I think that in all the other transitions only once there was an orientation process in place to assist the new guy learning the ropes. The common approach has always been to give a brief half-day or less introduction to the system, show how to get the source code, show the database diagram, meet your team leader, webmaster, DBA and manager, then go fix some bugs or build a prototype of a new feature.

I can't say that style of orientation (or shall we call it hazing?) can't work. It may work for some types of developers and worked for me, but it's risky and painful. It's also fuel for misunderstandings and propagation of myths. I won't lie and say that I could completely understand the entire system just by reading the source code and outdated documentation, it often happened that I had to grab any chance I had with more senior team members to ask questions that other developers in the same situation as myself could not answer.

The phases of a new job

I wanted to write this before I even look at the source code that waits for me because I don't want my new team mates thinking I'm talking about their master-piece. Again, I'm referring to my previous job/client changes.

One thing that invariably happens with me when I start reading unfamiliar source code is that shock of dealing with different coding styles, different coding standards, different 3rd party libraries, and sometimes different programming languages (or versions).

A lot of the discomfort is caused by superficial issues like naming conventions that temporarily obscure the understanding of the important characteristics of the system. We shouldn't be distracted by these conventions or code formatting style. What we are really trying to understand and get up to speed with is how the product was designed and which are the important components and identifiable patterns we need to adopt. It's okay to start off writing code with disagreeing naming styles, these things are easy to fix. Misusing or not using the design principles applied in the rest of the code is way more costly to fix, demanding more careful refactoring.

Once we start to see through that noise, we will finally be able to understand the why's and how's of the system. With that understanding comes an increasing sense of admiration for the code. I'm not saying that you will agree 100% with what you see, but at least you can feel more confident that you know what you're stepping on.

With that confidence in place we can start to identify places in system where cracks can start to show or more appropriate solutions for some of the issues. In general, we start to be able to contribute more than just code, but also design options.

Last night I attended another LCNUG meeting. I think it's great that we have this new group forming in the northern suburbs of Chicago. It's definitely not easy for us suburbanites to attend CNUG's meeting in the West 'burbs or even the Chicago ALT.NET meetings downtown. It's special convenient for me because it's only 10 minutes from home.

This time the presentation was about Silverlight. Tim Stall gave us a very nice and engaging rundown of this new technology — it was not your off-the-mill introduction talk. The questions from the audience were very interesting and Tim was very honest about the strengths and shortcomings of the tool. It was especially interesting to discuss ways to bring SilverLight into your organization.

Consulting engagements are supposed to end, even after 4.5 years. So, yes, my current assignment with the client is scheduled to end this week (is this job change season?). I didn't honestly expect it to last that long when I started but I guess the balance is positive.

With the end of the assignment my current priority becomes making sure I leave applications that can be maintained by the in-house staff. I can see at least 3 aspects that can impact the success or not of the transition — but only of them can be dealt with at this point. Read on.

1 - Design with maintainability in mind

That's where a truly successful transition starts. Of course there are situations where maintainability is not at the top of the list (think short-lived applications,) but we wouldn't even be talking about transition in those cases.

For all the other situations, which has been most of them for me, maintenance has to be factored in during the pre-coding stages of the project. That's when your senior developers will use their experience to identify potential support trouble in the solution design, before they come to life.

On that front I believe we did a good job within our limitations. I believe the applications were conceived with careful consideration to maintenance and, whichever parts of them created maintenance overhead, happened because of honest ignorance — not sloppiness. So check that off.

2 - Involve the maintenance staff during development

Without becoming annoyingly obvious here, it's always beneficial to have more than one developer knowledgeable about any one part of the application. Be it through code reviews, pair programming, or some other mechanism.

That's especially true for consulting engagements. Raise the red flag whenever you see a situation where only consultants/contractors are working on a project that is expected to be maintained by the client's staff.

Unfortunately the prominent structure of a project team at this client only included a single developer — sometimes an employee, other times a consultant. That was not something that I was ever in a position to change. I raised that flag but... oh, well. Whatever.

3 - Knowledge transfer of the parts you own

If the first two items were taken care well, the knowledge transfer can be just a formality. The less effectively we take care of #1 and #2, though, the greater the pressure on #3 will be.

When transitioning parts of the application that you're the only one that is familiar with, then there are several things to consider: existing documentation, the background of the people taking on the application support, the fancier parts of the code, the embarrassing parts of the code, and the design principles behind it all (if any.)

I think documentation is important but it only goes so far. There are many things that will require sitting in front of the screen, opening the code and/or database, and explaining how things flow.

It's also important to know the style of each developer. If you are dealing with a data-first type of programmer, then you have to make sure enough time is given to discuss the database design. Conversely, if the developer is an objects-first subscriber, the business objects in your code will deserve some more attention. The type of developer you are will also affect this discussion.

I try not to be excruciatingly detailed in the transition to avoid burning out the other developers before they even start touching the code. I try to leave some things that seem clear enough to be discovered by them as they go.

Lastly, if possible, stop taking on support tasks for the application being transferred and have the new crew take care of them while you're available to help. This will also help guiding the knowledge transfer meetings.

In my case I knew I was in trouble for being the only developer on the project(s) so the transition meetings became inevitably numerous and lengthy. In a way I was lucky that I knew I'd be leaving the client more than a month in advance so I could prepare better for this. Being with that client for such a long time also helped knowing the other developers well enough to make a list of items I really wanted to ensure got the necessary talk time.

I don't think it is possible to leave the client thinking 100% of the possible issues are understood, but we are doing a responsible job of covering our bases. At minimum I know the code is in good hands.

Good advice is always welcome. Do you have experiences to share? Anything I could take care of in the next five days?

I will be at the Codeapalooza on Saturday, September 6th. This will be a free event with numerous sessions covering many different topics.

I haven't made up my mind yet on which sessions I will attend but I'll be helping the event organization in some capacity. I already noticed that two of my friends Aaron and Chris will be presenting at the same time and, worse, two topics that interest me a lot. I'll probably just be in and out of sessions throughout the day.

One of the best things about being at these events is the chance to reconnect with old friends and make new ones. If you are in the Chicago area and attend Codeapalooza, come and say 'hi' or, if you're like Chris, you can say 'ol&aacude;'.

This week I experienced something that made me feel more confident about the viability of JavaScript as a first-class language in ASP.NET development. And I'm not talking about JavaScript's capabilities — those I have re-discovered long ago — my concern had always been how well other developers in my team would receive it.

For the last few days I've been meeting with a few other developers in my group, transitioning the support of one of my applications to them. Thanks to our quasi-regular brown-bag sessions, the understanding and acceptance of some architectural traits of the application, like the Repository Pattern and use of IoC containers (Castle Windsor in our case,) were fairly painless.

I always carried that uncertainty that when I started reviewing those .js files with them things could get ugly. These developers are pretty bright, real .NET ninjas, but hadn't yet used a JavaScript library like Prototype (or YUI or jQuery or MooTools or [insert favorite here];) and I used Prototype and script.aculo.us heavily in this project — which should not come as a surprise given some of my involvement with that library.

Unfortunately, without getting into too much analysis of teams and project management, I worked pretty much solo on this project, without enough code reviews and, heaven forbid, zero pairing sessions — again, that's not the point of this post; it's definitely the big reason behind my anxiety, but let it alone for now.

The day finally came for me to explain the UI portion of the application. Everyone thought the richness of the UI, the carefully applied visual effects, and the generally pleasant user experience were very interesting and they were curious to learn how it had been done. They knew I was using some JS library thing but I'm pretty sure they had never seen JavaScript applied to that extent.

I started explaining what is the most important thing for me, that you definitely need to use JavaScript libraries and that it is important to understand the language a little better. Without getting into a JavaScript lecture, we started discussing some of the basic features of Prototype, its global functions, why it does what it does to the native objects, and how JavaScript makes all that magic possible.

As soon as I started showing how clear and well-structured good JavaScript code could be I could see the light bulbs go off and some of those folks — that I knew feared JavaScript for being an unmaintainable mess — suddenly realized that there was this whole new world of production-grade, nice on the eyes, and expressive JavaScript code and techniques that they had been missing out the entire time.

I'm not done showing all the Prototype features used in the project yet, but I'm sure we will cruise through them and also script.aculo.us. Who knows? Maybe we even spend some time understanding JavaScript and its oft-misunderstood prototypal-inheritance model.