Transitioning - part II - oh, the expectation

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.