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.