New joiner - how to hit the ground running

IamtheWalrus

I have recently joined an Investment Bank as an agile contractor. I have no financial experience but have about 8 years development experience. I would say I'm mid-level. As I am a contractor, I frequently join new projects where I have to get up to speed quickly. I am not bad at this but it would benefit me if I was better. The issues I have are:

• Learning the business domain from scratch.
• Understanding the client's culture.
• Understanding the client's technical culture.

I use a 'pick things up as I go along' approach but wonder if there is a tried-and-tested approach I could adopt. I learn by pair programming, chatting to the right people, taking notes, reading material in my free time, doing tutorials of the client's tech that I'm not familiar with.

I find that I often get overloaded with information and sometimes struggle to prioritise the information I get, knowing what's crucial or not. I also get very stressed initially and am afraid to ask silly questions and make mistakes.

Can anyone give me any ideas?

GreeBo

I find it best to start implementing something small, perhaps making a small change to something already in existence, then just build on that.
You are a contractor so typically they are expecting you to start producing, especially if you are on an agile team where you could have 2 week iterations.

You dont actually need to get 100% up to speed on the domain or the whole code base, no one can or does in the first few months/years.

Try to avoid panicking and thinking that you are crap and should be further along than you are, just start implementing things, ask others if you are not sure how certain things are done in that env.

smcelhinney

Thats a good approach to have.

Generally as a contractor however, I like to leave things in a better state than I found them with most roles, I always do an "on-boarding guide", or modify one that's already in existence. I accept that as a contractor, sooner or later I will be replaced by a full-timer. That's the nature of the business, and your reputation is only as good as your last contract.

Start taking notes of practices that you've implemented, save any build or deployment scripts that you might write. It's great to be able to hand over a document to your employer the week before your contract is up, it makes it easy for them to transition a new person into a role, and they'll have a good impression of your professionalism, ie. are more likely to recommend you to a future employer.

The days of "implicit knowledge" vs "tacit learning" are well and truly over; leave the place in a better state you found it, and you'll never be short of work. Contractors who keep information to themselves in the hopes of becoming indispensable are quickly found out.

Good luck in your new contract Walrus!

GreeBo

smcelhinney wrote: »

Thats a good approach to have.

Generally as a contractor however, I like to leave things in a better state than I found them with most roles, I always do an "on-boarding guide", or modify one that's already in existence. I accept that as a contractor, sooner or later I will be replaced by a full-timer. That's the nature of the business, and your reputation is only as good as your last contract.

Start taking notes of practices that you've implemented, save any build or deployment scripts that you might write. It's great to be able to hand over a document to your employer the week before your contract is up, it makes it easy for them to transition a new person into a role, and they'll have a good impression of your professionalism, ie. are more likely to recommend you to a future employer.

The days of "implicit knowledge" vs "tacit learning" are well and truly over; leave the place in a better state you found it, and you'll never be short of work. Contractors who keep information to themselves in the hopes of becoming indispensable are quickly found out.

Good luck in your new contract Walrus!

I think it very much depends on why you were hired and what they want you to do.
If you are joining an agile team as a dev then I'm pretty sure they expect you to start producing, going off an documenting the entire current SDLC isn't going to win you many friends if they team is not meeting its sprint deliverables.

That approach is fine if you have been brought in to specifically look at process/documentation etc.

counterpointaud

If the team is using a project tracking system then reading back over closed tickets as well as looking at open tickets can be very informative about many aspects of the workflow (and politics).