How to quickly enter someone else's project?

Question

Work organization

Share your experience in such situations.

Answer 1

All your knowledge gained on the project must be immediately recorded. Ideally in electronic form, but it is also possible on paper. This is your documentation.
Keep in mind that depending on the management, you can either be praised or, on the contrary, they will say that you are wasting your time and everything is clear. More likely to be the second!
For pumping karma, if you want, then pass your writings to the next rower.

Answer 2

They add fuel to the fire and architectural moments: some of their own terms for describing the functionality, their own rules for naming, building and other things.

This is fine.
I regularly come across where there is a permanent team - their own internal terms used only by them.
For example, in one cosmetics company, clients are called "aunts".
This is completely normal.
typical situation.
Do you want to solve some of your fictitious problem for a salary or is it still a problem for the company?
Asking is completely normal.
You are not showing your stupidity at all.
And you find out the features of a unique project.
And it is stupidity to try to do something cooked in your own juice, although there are more experienced colleagues at hand.
Who knows what you don't understand but yourself.
As an employer, I consider the inability to communicate at work to be a huge disadvantage.
He sits in a corner, does not ask anyone, does not know anything ...
What is he doing there? How is he doing there? So how is it supposed to be in our company? Of course not.
He does some self-invented garbage, and even for our money.
He solves some of his far-fetched problem, and not the problem of the company that he was hired to solve.

Answer 3

Bug fixing, in short.
Only an intelligent PM is needed to select tasks according to the level.
Those. at first, something light, to which specialists are simply squandered. Ideally, the module should also tell you where to look.
Then - bugs are more difficult, then even more difficult ...
Here you can already connect to the implementation of new features.
So you can easily and naturally get acquainted with the entire system, and not feel like a fifth wheel.

Answer 4

I do not work alone, there was no real introductory briefing, and I consider constantly running for help a very shameful occupation, besides distracting others from their work.

If a company does not have a well-developed knowledge exchange procedure (in the form of, for example, pair programming, or some kind of training, documentation), then apparently they don’t care about newcomers (a very typical situation), your questions will really distract a person who already has some tasks (accordingly, you will prevent him from performing these tasks), what to do in this case -> most likely no one will really help you (except for superficial advice), so you need to work out a scheme for studying someone else's product, here the most important skill is to work with debugging, learn experiment with the product and track changes.
I also recommend starting with the study of tests - the main logic of the application should be described there.

Answer 5

Is it embarrassing to run for help? So you don't run with the question "How?". If you need this job, sit down, take a tangerine and study everything you work with there. Guess what principles and methods former/current virgins used and already approach your hay with the question 'Did you think it that way?'.
When you get a job, you must take full responsibility for what you will do there and what the result will be. Therefore, sit down and study all their projects and databases, ask more questions about at least some relevant technical document, ask about patterns and everything else.
You will understand what was 'smoking' during development - you will understand how the architecture of the project (s) was built. Good luck!

Answer 6

Tarot cards, the stars can also help.
Don't know - ask. There is nothing like that when a new employee delves into and asks.

Answer 7

I do not work alone, there was no real introductory briefing, and I consider constantly running for help a very shameful occupation, besides distracting others from their work.
There is nothing to be ashamed of, especially at first. If they wrote an intuitively incomprehensible code and did not prepare any documentation, then let them deign to explain. I’ve been working at my current place for 3+ years, so I still periodically stumble across projects on misunderstandings 5-10 years ago that you can’t comprehend with your mind. Just ask.