Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
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.

Posted 09-11-2008 9:28 PM by sergiopereira
Filed under: ,



Business blog » Blog Archive » Transitioning - part III - enter the learner wrote Business blog » Blog Archive » Transitioning - part III - enter the learner
on 09-11-2008 11:50 PM

Pingback from  Business blog  » Blog Archive   » Transitioning - part III - enter the learner

Raif Harik wrote re: Transitioning - part III - enter the learner
on 09-18-2008 9:24 AM

Hi, just stumbled on to your blog.  I like this post particularly as I am in just this situation.  This is only my third dev job and by far the most advanced one.  First time agile, tdd, ddd etc.  The team is only four guys myself included and the other three are very senior guys.  They are all very nice and helpful which is great but it’s a bit intimidating.  Your post is reassuring and helpful for me at this time.  I was wondering if you have and thoughts on how long it should take a person to get up to speed on a pretty advanced framework.  I’m always worried that I’m taking too long to learn stuff and that I’ll either be perceived as sucking or get canned.


Raif Harik wrote re: Transitioning - part III - enter the learner
on 09-18-2008 9:27 AM

Looking further I see you're involved in Chicago  perhaps you know my team.  I'm at dovetail software.  Big brains there.  it's quite intimidating.


sergiopereira wrote re: Transitioning - part III - enter the learner
on 09-18-2008 10:07 AM


I do know Dovetail by its name and some of the folks that work (and have worked) there. You're among smart people. In my opinion, that's where you want to be. Better feel like you have a lot to learn than stagnated.

I can't give specific time frames because it obviously varies with each person and each environment. I guess the best advice is still find out who can help you the most and prioritize and learn the fundamentals of the business and the framework.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)