Kung Fu Project Support

Probably each of the programmers had to deal with a new or not new job with the need to support the “alien” project.

The programmer manages to write code compiled or interested in, but not everyone understands.

Everyone reacts to the "alien" code in different ways. Some throws in a cold sweat, others clenched teeth understand. It so happened that I watched this process from the inside, as an outside observer, as a team leader and as an expert transmitting my code to a “newcomer”
')

We help to learn the kung-fu of someone else's code to a “newbie”

Situation. The new one has come to your team. Abstracting from its capabilities, as there are bison, which move mountains, but there are few of them, and I also prefer to help them.

Sitting beside and explaining is not very effective. It is impossible to make read documentation or bugtracker with several thousand reports to understand the background.

And it's not about laziness ... it's not about her. Someone is trying to deal with this, and I believe that a good programmer should be lazy, but not stupid.

Yes, and each "new" comes, as a rule, with great potential and enthusiasm. Sin is not to use!

Therefore, the first task that I give to the newcomer to work on my team is Code Review. If I do not forget, then I warn you that you have to fix bugs yourself.

The second task is to correct or write unit-tests for basic operations or to supplement existing ones. And if you already have them all, then make sure they check all situations.

Thus, in one or two weeks I get a full audit of the written code, written unit tests, and a fully “entered” specialist who has an understanding of what he is dealing with and huge plans for refactoring.

Quiet, peaceful and without revolution :)

We study someone else's code

Being in a new place, anyone is experiencing a lot of stress. New team, new building, ridiculous questions (“where is your toilet?” :)) and unknown code :)

There are ideal cases when a team leaves the bison, and you stand in its place - the main thing here is not to spoil it ... and yet it is often the other way around - the code looks like a Borodino field after the battle. Confused, repetitive, often written hastily under deadlines, without tests, documentation, bugtracker. Nearby, the manager is tearing at his hair and says he needs to be quicker, and in fact he wants to show himself, not to get stuck in the study and not to frown.

It is good if the team leader will act prudently, give you time and simple tasks for you to get comfortable. And this also does not always happen.

As I did in such cases. I honestly warned that I need at least two weeks to understand what has been done and how it works, immediately getting acquainted with those. Assignment and development plans.

"Wound up" if there is no bugtracker, described the functional (cards) in the wiki, wrote unit tests, did code review.

In the end, I got the tools to control myself from the wrong steps, the employer saw the concrete results of my work.

Getting ready to send code

For me, getting ready to transmit the code is like breathing or doing a constant refactorig ... It's not just the warrior's internal philosophy - constant readiness for death, I don’t burn bridges, I like to have people from old work who can recommend me in my resume.

I do not comment on the code, I am writing it understandable. I have long taken the rule: if you want to write a comment, I select the code in a method with an adequate name.

I practice pair programming when writing a new functional or refactoring the old one with the most powerful programmer from my team. This allows you to write code that is understandable.

I am writing unit tests on a new functionality, and then proceed to the development of code.

Before you start writing code, I am writing an article (tech. Assignment) about how the new feature will work.

I divide the task into subtasks for no more than 20 hours of work, expose dependencies in the bug tracker.

I leave the link to the “main” bug in the wiki, where I describe the feature. In the bugtracker I describe hacks, if they exist :)

All this makes the transition from work to work enjoyable, there is time to buy cakes for the old team and leave a good memory of yourself :)

Celebrate the arrival of a new team, it is good to recommend yourself, not to spoil the reputation.

I love my job :)