Transitioning - part III - enter the learner

Turning the table

So here I am, the guy often in charge of assisting new developers get up to speed with my designs and code, facing the diametrically opposite situation.

Like many other developers, I have changed jobs more times than I'd like to. I love the chance to learn from a new industry or platform, I just wish the transition wasn't as traumatic as it frequently is.

I've seen developers hit the ground running, but I've also seen other developer struggle and run in circles not knowing how to proceed when faced with the new environment.

I believe each place has its own challenges but it's still possible to follow some guidelines (or more like heuristics) to optimize the whole ordeal.

Humility - leave that big ego at home

This may be sad news to you, but it's probable that you'll be facing several brick walls. That has nothing to do with your skills or how great a problem solver you are. It doesn't matter. The environment is new to you, possibly the business itself is completely foreign too.

So ask! You will not be perceived as incapable just because you ask too much. Yes, at least try to solve the problem, but don't go thrashing for hours and hours. You have too much too learn and not a lot of time.

Identify the key players

Maybe you will be introduced to the team in you first day and tons of job titles will be thrown at you. Don't spend too much energy trying to remember who has what position in the org chart.

More often than not, these titles have very little to do with the actual role each individual plays in the team or project. Just because someone is labelled senior developer it doesn't mean that that person's contribution will be more effective or regarded than that lowly intern that is on a Summer job or even somebody not directly in the team, like a business user.

Knowing who really has the information you need should always be one of the priorities in your first week at the job.

Identify the real mentors

You know how that is, someone gets the task of being the assigned target for your questions or for pairing with you for a tour of the system. What may not be obvious is that your assigned mentor may have been appointed and not volunteered for that task.

It's possible that there are other members in the team with more inclination for mentoring or that is better at explaining things. So why was not that person chosen to be you mentor? Who knows... Too busy? He/she was on vacation when you started? Bad management? It's uninportant. It happens. It sucks.

Bottom line, disregard the assignments and go for the gold. Once you discover the mentors in your new team. Jump at them. The real mentors will be happy to make themselves available to assist you.

Pick your battles - everybody has defects

The temptation to point out problems is ginormous when you start. It's understandable. You want to show something you know, to contribute, to become valuable, etc.

The unnecessary risk in that is putting yourself in an antagonistic role. It's hard enough being the new guy. Being the guy that came to make us look bad is definitely undesirable. The system had those problems before you got there, chances are nothing serious will happen if you wait a little longer to understand the ground you're stepping on.

Unless you were brought in specifically to review or address a particular problem, exercise your best judgment and don't stick your finger at every little flaw. Everybody has shameful code in their source control log.

Learn the business, talk the talk

New job invariably brings a different way to do business, maybe a new industry altogether. We will do a huge favor to ourselves if we make an effort to learn this new business. Learn the jargon, learn the business model, learn why your end users are using the software, learn about the competition... Learn.

In any semi-serious shop, just knowing the business lingo should give you a head start in understanding even classes and table names in the system. Not to mention you will be able to sustain a decent conversation with the business stakeholders more quickly.

Jump at the opportunity

To top it off. I've seen these countless times, and it still saddens me. Everywhere you go, every team, every project, there's tons of stuff that could be better if someone dedicated some time to it. Unfortunately the lack of initiative is a plague that affects not only software development but pretty much every field. It probably had more to do with sociocultural roots than being a bad professionals.

How many times you've heard complains or suggestions flying by in team gatherings along the lines of: "Have you guys ever used a wiki? It would be cool if we had one", "Our [ bug tracking | source control | logging component | 3rd party controls library | insert pet peeve here ] sucks, I wonder if there's anything better out there", "We seriously need to take the time to document this API", "I hate doing this every time. This should be automated". Let's try not to look at these statements as merely problems or chores that represent the status quo and be prepared to deal with them. In reality these are examples of opportunity. Things that nobody in the team likes or knows how to do. More importantly, many of these can have a direct impact on how well things work, more than it may be apparent. Oh, that's right, they can be fun too.