Sooner or later, if you’re developing software, you’re going to find yourself thrown in at the deep end, tasked with working on a project that is unfamiliar to you. This happened to me a few months ago when I started my new role at Remote and soon found myself working on a key project for an important client.

It’s fair to say, that if you find yourself thrown in at the deep end on a development project that is unfamiliar to you, the initial feeling, is something close to sheer panic.

On day one, there are so many things you don’t know.

What architecture has been employed, which database technology is in use, what technology stack?

And perhaps even more importantly, you don’t understand the business domain. You can start to investigate the software, but does the terminology employed in the code match the real-world?

The good news is, once you find yourself at this point, the very worst part is already over.

That feeling, that you know literally nothing, is brief. From here on in, your picture of the domain and the app can only become clearer.

I’ve found a few tactics that work for me when faced with that initial voyage of discovery.

1. Ask your colleagues for help

It’s tempting to skip this part.

After all, those colleagues are probably busy, they have their own work to be getting on with, you don’t want to disturb them.

But it’s so much easier to build up a picture by discussing it with someone else, than it is to sit there, locked in your own head with panic setting in, trying to fathom it all out by yourself.

If you have lots of questions (and you probably will), it may be better to batch them up then request a chunk of time to go through them.

This is much less disruptive for the other person than being interrupted every two seconds as you think of something else.

2. Request an overview of the project

It’s tempting to jump straight into the work but a high level overview of the project is always useful.

Try to get a feel for the business domain. Which people are involved, what are they trying to do and how does the software help them do it?

This all important context ensures the work you’re about to undertake is anchored by an understanding of the bigger picture.

3. Don’t be afraid to talk to the user/client

Depending on the nature of your role, the work (and the clients), this may or may not apply.

The thought of approaching the client with questions is daunting, but in truth they’re best placed to answer any questions you have about the feature/bug fix you’re working on.

It might be worth checking with a colleague that the client is approachable, but assuming they are, you’ll get to introduce yourself and build up your knowledge of the business domain.

The client usually knows their business inside out and they’re unlikely to reject an opportunity to go through it with you, especially if doing so increases the likelihood that you’ll solve their problem.

4. Use the tools - Prefix

Let’s say you’re looking at a database, full of tables, and a big web project. It can be really difficult to work out which pages interact with which database tables.

Prefix is perfect for this. It’s easy to install and will then show you which web requests and database calls are being made.

Once it’s installed, any requests to your local IIS (or IIS Express) web sites will show up.

You can see details of exceptions, database calls etc. by clicking on any of the requests.

5. Use the tools - SchemaSpy

A common issue when exploring any project is understanding the database schema.

If you point SchemaSpy at your database it will build up some documentation that shows which tables there are, and how they relate to other tables.

This is particularly useful if the database has well defined relationships.

In Summary

It’s daunting to approach any new (to you) project but hopefully these tips help.

Whatever happens, remember, that initial feeling of being completely lost is temporary and it won’t be long before you’re the “go-to” domain expert to whom everyone else turns for advice!