Showing posts with label rampup. Show all posts
Showing posts with label rampup. Show all posts

8/02/2019

How to ramp up for a software project as fast as possible?

Introduction
If you are working as a software developer you have already faced with the situation that you are starting on a new project, where you don’t understand anything, but you should start to work on the tasks as soon as possible.
Of course it is not an easy situation, but it goes much faster if you are doing the ramp-up process in the correct way.
And if you can understand the project fast you will be encountered as a good professional.
I collected some suggestions based on my own experiences below. I hope they can help you.

Tips and Tricks

Understand the current and the expected functionality

Before going into technical details you have to understand two things: what is the program currently doing and what is its expected behavior once the current task/project is done.
You should start this process by reading the requirements or the user guideline if they exist. Then you should start the program and play with that. Try to figure out as much functionality as possible and make notes. Collect also questions in the meanwhile and ask them from your colleagues before going into technical details.
Reading the already existing test cases can also help a lot.
Never start the implementation of the new function until it is not 100% clear how it should work, what should be its outcome.

Get a technical overview

Once the functionality is clear you should get a technical overview. As part of this you should read the technical documentation and the software design if exists. You should focus on the following points: which technologies (language, framework etc.) are used for which purpose, what are the main components of the software and how are the components communicating to each other (which interfaces are used, what is the information flow etc.).
In this stage you should setup your development environment, checkout and compile the source code and run it on your own.
You can also draw some diagrams for yourself to get an overview.

Identify smaller parts of the code

Once the high level components are more or less clear you can go deeper for the ones which are relevant from your tasks. If you are analysing a piece of code (class, function, subcomponent etc.) always concentrate on the following questions: what are the inputs, what are the outputs, how does it produce the output based on the inputs (which algorithm is used etc.) and who is using the code.

Don’t get lost in the details

At the beginning you don’t need to understand every small detail. If you already have an overview and if you have an idea about which part of code needs to be modified, you should just jump into the water and start to implement the first part of your task. You will understand the details during work.

Ask in a structured way

The best if you can understand as much as possible based on the code and the documentation. But most of the cases it is not giving a totally clean overview on everything. In such cases you should ask your colleagues. But you should do it in a professional way:
  • Collect what do you already understand and what is missing
  • Collect your questions on a paper
  • Tell briefly your current understanding to your colleague and ask if it is correct
  • Ask your questions
  • If something is still not clear try to ask by focusing on the still open points.
  • After the discussion make notes and check everything again

In the beginning always ask your colleagues to review what you have done

Since there can be some misunderstanding in the beginning, it is good to ask your colleagues to review your changes in small pieces, even if it is not part of the company culture. Be always open on critics and suggestions.

Summary


Every start is challenging, but if you are doing your ramp up in a well-structured way you can make it much easier.

3/07/2019

10 Points to make your ramp up faster at your first workplace


Don’t think that you are the best

It can be that you  were part of the best students at the university and you could achieve all tasks there. It is also most likely true, that due to you fresh studies you are more up-to-date with the newest technologies than you colleagues. But your colleagues has multiple years experience in the field you are working in. It was always a bit strange for me, but as a student I thought that I’m good and as I started to work I was encountered as a beginner. It’s totally true, I had no experience, so it took me much more time to resolve tasks than for my more experienced colleagues. Luckily it changed with time. That also happened that there was some kind of used practice at the company which seemed to be totally useless for me. I just clarified it with my mentor and I understood their decision.
To summarize this point: you will be encountered as a beginner and you are a beginner in fact, count with this fact and if you are doing well you can change it with time.

Be patient

As you are joining a new company at the beginning you need to wait a lot: wait for your hardware, wait for you licences, wait for your access to the source code and wait until your colleagues find time to clarify topics for you. You need to be simple patient. Your colleagues also have their tasks, most of the cases with a due date, that’s their first prio. You can be sure, they will support you as soon as they can find time.

Pay attention on what your colleagues are doing

You can also use the time, until you are waiting. You can also learn a lot without blocking your colleagues. Simple keep an eye on them and try to understand what and how they are doing. You can also check their commits in the version control system, check what was their task and how they solved it. You can also check what kind of meeting are they attending and what is the scope of these meetings. So that you can learn really a lot without blocking others.

Collect keywords and google them

At the beginning for sure you will hear a lot of keywords, technologies which you have never heard before. If you hear such a keyword just take a not and later if you have free time google it and try to understand what is it about. If it is still not 100% clear you can of course ask someone, but then you can already ask more directed questions. It makes a much better impression. So instead of “but what does MVP stand for?” you can just ask that “I’ve heard that you are using the MVP pattern in your architecture, could you please clarify how is the presenter layer working?”. Sound much better, right? You can reach this point after 10 minutes on Google.

Collect a list of questions

Do not block your colleagues with each and every question. First try to collect a list a questions, make sure that the one has some time for you and go through on all questions in the same time. Take notes about the answers. It is much more effective, than just asking something in every 10 minutes. And it is also much more effective than “please tell me everything about your project”.

Be patient at working on boring tasks

Most likely at the beginning you will get some boring tasks. Do your best on them and so that you can get much better tasks soon. If you are not achieving the boring tasks with good results you will never get more interesting tasks.

Communicate your issues

Let always your team mates, mentor and manager know what are your current issues. For example if you are blocked, because you don’t have access to the code, don’t just sit and wait, but let your manager know that you have this issue and it blocks you at work.

Build connections

For building your career it is really important to know the right people at the company. During your first weeks try to get know as much of your colleagues as possible. The best way if you are doing some short talks in the kitchen, during lunch and so on. Always try to figure out who is the person, what is their role at the company and for which project are their working for. You can also take later on some short notes (but don’t do it during the discussion!).

Do regular feedback to your managers

That’s normal that at the beginning you don’t know your managers, so that you also don’t know their exact expectations. It is a good practice to ask them for a feedback regularly (maybe once a month) in the first period. So that you will be able to see if you are working in the right way or not.

Be hard working

In the first month do really your maximum, to make a good impression.

+1. Pay attention on work-life balance


This is a special point and it is maybe does not really stand for the first months. I just realized that there are a lot of workaholic developers, especially young ones at their first job. This means the one would like to fulfill all the expectations. That’s why he is working a lot, does regular over hours. So that their manager will give them more and more tasks, so they are working more again. And they are starting to cancel or shift their private programs, choosing to work in the evening instead of meeting with their friends and so on. This kind of working style is leading easily to a burn out, so try to avoid it! On the other hand it is also not always the right way to build up a good career. You will considered as the guy, who is overtaking every shitty task and not as the guy who can achieve every difficult task. And it makes a really big difference. Always set up the priorities of your life and keep them always in front of your eyes.

How I prepared my first online course

Since long I didn't publish anything here. It's because I was busy with some other topics, but now it's time to share the result...