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

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.


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


Programmers and soft skills

Who are the famous programmers? Everyone knows Bill Gates and Linux Torvald. A lot of programmers also know Uncle Bob (Robert C. Martin). Why did they become famous? Are they so deep technically? For sure they are technically good, but there are a lot of programmers all around the world who are technically awesome and almost no one knows them. Why are they special then? They know something what others are lacking. These are the so called soft skills: good communication, marketing skills, self management, time management, great presentation skills etc. These skills are making them different, these skills are making them outstanding. And these skills can help every programmer to get a better job, to do a better career and to be more successful. There’s something great: you can improve these skills any time. And it totally makes sense to improve these skills. This is the way to success.

How to improve soft skills

As I just mentioned you can improve these skills anytime. One hand most companies realized how important these skills are, so they are offering trainings for these areas. Join these trainings!
On the other hand you can read a lot about them on the internet or you can buy some nice books.
But what is more important: these are practical skills. It is not enough to learn the theory. You have to use them in your daily life. You can always pay attention on practicing them as much as possible. And not only during work. You can practice them at home with your family or with your friends as well.

The most important soft skills for programmers

Time management

As a programmer have to answer emails , participate in meetings, help the other colleagues and be done with your tasks until the due date. This is really challenging. Either you are doing a lot of over hours or you are starting to use some time management technologies, like prioritizing your tasks based on their urgency etc. Without good time management skills it is really difficult to survive as a programmer.

Self management

If you want to do a career you need to be able to find the right positions for yourself, you need to see when do you have possibilities to prove your skills, you need to know when is the right time to change. And you need to be able to show to others that you are working well. Most programmers who are not getting promoted only because their outstanding programming skills, they are also able to sell their work to the management.


Programming is not the profession of lonely wolves, even if several people things that it is.
Programming is teamwork and to be able to work in a team you need very good communication skills. You need to understand the problems of the others, you need to ensure them about your solution and you need to be able to communicate your status in a very clear way. You also need to communicate to your managers and in several cases to the customer as well. It is really important to communicate to them in a nice and clear way. As a first step I would suggest to learn about assertive communication.


As a programmer, especially if you are on a higher rank you have to do several presentations. These are either technical presentations (kind of trainings) or presentation about the content and the state of the project. These presentations should be done in a professional way and you need to learn it, what does it mean exactly.

Stress handling

Working as a professional programmer is mostly stressful. Stressful because of the strict due dates and because of the conflicts inside the developer team or between the team and the management. You need to be able to handle this stress in a proper way, otherwise you become either aggressive or depressive, worst case both of them. And this can have a negative impact not only on you and on your work, but also on your family and on your friends.

Basic marketing skills

You need some marketing skills if you decide to do your own business, it is pretty clear. But also as a developer if you are looking for a new job you need to do a kind of self marketing. You are basically a product on the developer market and you have to sell yourself for the highest possible price.


As you have seen you need several soft skills to be successful and a developer, but luckily you can learn them easily, it takes just some time.


Motivation and developers - what is in the background?

Most of the software companies are suffering from the high fluctuation of their employees. It makes them big difficulties and their are losing a really huge amount of money on recruiting constantly new people and ramping them up.
On the other hand it is also bad for the developers if they can not find a place for themselves where they are  feeling comfortable.
So the situation seems to be bad for everyone, but as for now there’s no solution for that.
Of course I also can not solve it, but I took some effort to analyze the situation a bit to have a picture about this whole process.
There are of course different people, different situations and different decisions which are not covered by my model, but I tried to cover the most typical career paths.
The purpose of this analysis is to help for the developers to find their optimal place as fast as possible and to help the employers to keep their employees.
It was prepared based on my own experiences, but I am interested in other opinions as well.

The model

I just prepared a short state diagram to have a graphical overview of my model.

If you start to work at a new place (mostly new company) you will start as a novice. This covers the first weeks and months. This is about introducing yourself and exploring your new place. In this period you are having the first contact with the team, with your new boss and with your new customers, you have to show your best side. On the other hand, you need to understand the working process and the technical background of your new project and achieve your first tasks. You need to prove that you are good enough to work there.

This stage can end up in three different ways.
The first one that you or your boss decides to not continue your work there. It can happen either if you are not fitting well to the team or to the project or if the workplace does not satisfy your expectations, so you decide to leave.
Otherwise you are staying at the company. But it makes a big difference in which way you are doing it. The first way is that your boss has the impression that you are better than expected. In this case you will be in focus and you will get several opportunities to grow (new responsibilities, new roles, etc.), but this means of course also higher expectations against you. If you are accepting this challenge you are becoming a rising star: being always in focus, getting new challenges and good career opportunities for the future. There are such people in each and every organisation who are reaching new levels of the hierarchy pretty fast. But this status also has a dark side: most of the cases you will irritate your co-workers who are working there already for several years and now having such opportunities.

But it also can be that you are “just” fulfilling the expectations and you are becoming a totally average “grey” co-worker. You are part of the team, you are contributing, but you are not really stepping further in this stage of your career. It is also fine for a while, since you can learn a lot during the first period and you can feel the lack of high responsibilities. There’s sometimes opportunity to change from this state to be a rising star, but it is not typical. Usually it only happens if something is happening with the current rising star (changing to another place etc.).

After sometime you are changing your state again, for some people it is coming sooner, for others it is coming later. Being a rising star is exhausting on long term and the magic of chilling as a grey co-worker also does not take forever.
From now on there are two opportunities again: finding your comfort zone or becoming unsatisfied. And the best part, that the same is happening both with the rising star and with the grey co-worker.
As rising star you will grow until a while, but once you will reach the state when you feel that it would be uncomfortable for you to take over higher responsibilities. For some people it is a position of leading a small project team, for others it is a CEO position, it is up to your personality. In the ideal case you can keep this position for you which makes you really happy, so that you can just work from your comfort zone in the next decades.

But it also happens (unfortunately really often) that you are not reaching this state, because always more and more responsibility is pushed on you (you can keep the one which is comfortable for you), you don’t agree with the direction of the company or your salary is not following your new roles and responsibilities. Of course there’s several additional potential reasons. In this case you are becoming an unsatisfied employee.

As a grey co-worker you also have these two options: finding your comfort zone, or becoming unsatisfied. There are several people who don’t want to have high responsibilities, they just would like to do a job, which is kind of OK for them and don’t make much stress on work. If such persons think that their place in comfortable (salary is acceptable, the project is fulfilling their expectations, there a good work-life balance) then they are finding their comfort zone as an average developer. They are usually the one who are living a stressful and well-balanced life, their are doing their tasks, but nothing more and they are happy with that.
But if the average developer would like to reach more (getting higher responsibilities etc.), but their doesn’t have a chance for that they will become unsatisfied as well. It can also happen if other conditions are not optimal (salary, work environment, work-life balance etc.). It is important to mention that each developer needs different kind of motivation. For some of them work-life balance is very important, for others it is more important to have interesting projects etc.

As a boss (team manager etc.) you need to know your employees and their motivation of work. You also need to understand in which state they are in their career and what is their future expectation. If it is so you can set up actions which can keep your employees at the company.
Pay attention: if the circumstance is changing it possible that employees from the comfort zone are changing to be unsatisfied and it is also possible to happen in the other way around. But this is unfortunately not so typical.

From being an unsatisfied employee there’s a highway to burn out. Burn out is bad for both parties: developers with burn out are depressive, demotived and not effective. They are just making the team slower and they are suffering at going to work day by day. From burn out there’s no way back. If you reached this state the best what you can do is to change company as soon as possible. But it is better to do this step before reaching the burn out state.

After leaving the company you need to do a restart at a new place and it will be pretty clear more difficult then your start at your previous place: you are older, you are having less motivation, you would like to reach everything faster what is mostly not possible.

What are the consequences for developers?

First of all you need to decide what is the position what would make you satisfied. Maybe you can figure out at the beginning that you are pretty happy as a simple developer without high responsibilities. In this case you have an easier way to your comfort zone.

Work during your first week and months based on that: if you don’t want to be a rising star just try to do the same level as the others, otherwise do your best. If at the end of this period you can already see that it won’t work at all at the company don’t hesitate to leave, instead of reaching the burn out state very fast.

If you are becoming a rising star try to keep a balance and not to grow to fast, because then you are losing the chance of reaching your comfort zone. And the most difficult: tell stop in time.
If you are a simple “grey” developer just do what is expected: not more, not less. And try to orient yourself to a position (project, topic etc.) which makes you happy.

If you are grey developer you still have some chance to become a rising star if you want. In this case just try to do your best and be patient.
If you reached your comfort zone try to keep it, try to avoid changes which can bring you out from this state.

If you are becoming unsatisfied let’s figure out if you still see any chance to find your comfort zone. You can talk about that to your boss, you can evaluate the opportunities. But if you see too low chance for that: change company before it is too late and don’t waste your time!

What are the consequences for employers?

As a boss (team manager, team leader etc.) you need to protect your employees from reaching the burn out state. It is even better if they are not reaching the unsatisfied state, but from that state there’s still a way back. If you find any of your employees in unsatisfied state support them to find their comfort zone to be able to keep them as a valuable long term employee.
Next to your rising stars, always pay attention also on your “grey” developers, understand their goals and support them to reach it.

If your rising stars are telling “No” accept their decision, it is very important!
And maybe one last point: if you can see at new colleagues that it won’t work at all, just resign them as soon as possible, otherwise both of you will have a lot of difficulties. Sooner is always better in such situations.

Do you agree with these points? Or you have other experiences? Don’t hesitate to share them!


How to perform a code review?

At most of the companies and projects there is something called four-eyes principle. That means noone is allowed to make changes totally alone, at least one more person needs to approve the changes. One popular implementation of four-eyes principle is doing code reviews. As alternative you can do pair programming. But what is a code review? How to perform it in an efficient way?

What is the goal of a code review?

Code review is one quality gate for the implemented code. The goal is that other (often more experienced) colleagues are checking the code changes, makes suggestions (so called findings) and decides if the code can be merged, or still some changes are needed?
The results of the code review needs to be documented.
The goal of code reviews is to achieve a better code quality and to share experience inside the team.

What is to be checked during a code review?

The first goal of the code review is to check for potential bugs in the code: check if the code is doing what is should, check for mistakes like usage of uninitialized variables, endless cycles, incorrect handling of memory, dead code etc.
Furthermore most projects should follow a predefined coding guideline. This guideline is up to the used programming language and it is describing how the code should look like: which missconcepts needs to be avoided, what should be the order or declarations, how to name your file, which language elements can or cannot be used, how to name your entities (functions, classes, variables, etc.), how to organize your code etc.
During the code review it should be also checked if this guideline is followed or not.
At last suggestions can be also made for the developer of the code how could it be done in a better way.
It is important that several of these points can be checked by automated code analyzer tools (dead code, naming conventions etc.), it is always a good practice to use such tools.
It is also a good practice to have a common checklist about what should be checked during the review. So that the reviewer can go through that checklist point by point to make sure to not miss anything.
It is also a good practice to make a difference between major and minor findings. Major findings are must to change and minor findings are just “would be nice to have to be changed”.

Possible ways of performing a code review

There are two main ways of performing review: do it online (face to face) or do it offline. The online version takes more time, but it has some benefits.

Online review

Performing code reviews online means that the author of the code sits together with one and more other developers. The author shows the code what he implemented and describes their implementations details and design decisions. The other developers can ask questions and make suggestions at any time.
A protocol should be created, which contains every point of the review meeting.
The big advantage of this way, that the reviewer can understand better and deeper the implementations, decisions can be clarified in a fast way and the author of the code get a detailed and direct feedback.
In case of too many findings the review meeting needs to be repeated once the findings are fixed.

Offline review

For offline review it is good to use some kind of online tool. In this case one or more developers are reviewing the code changes offline on their own at their computer and adds their findings and questions in the tool. Then the author of the code needs to answer the questions and fix the findings. It needs to be repeated again and again until the reviewer does not approve the changes. The advantages of this method are that the reviewers and the developers doesn’t need to be at the same place, they can perform the review in different time and different reviewers can review totally independently from each other. The disadvantages are that the reviewers are not going so deep into the details, in case of a lot of questions it can take long and the author of the code does not get a detailed (verbal) feedback.

Who should review the code?

It is always up to the project. In case of some projects any developer can perform a code review (usually in more agile teams). This is usually the case if the team members are on a similar level of knowledge.
In other cases the review must be performed by some domain experts, technical experts or software architects. Multiple reviewers are always welcomed. This is usually done in structures with a lot of different expert roles.


Code reviews are important quality gates. The best way of performing reviews are always up to the project needs. But anyway it should have a clear and documented process and documented results. Otherwise performing code reviews can be just a waste of time.


What is requirement management and why is it needed?

Whenever my wife sends to me to buy food I have fear. I have a fear that I’m not buying the right food, even if I try to do my best. The issue is that I go to the shop and check my list, the first point is “milch”. And at this point I have no chance to fulfill the requirements. I can not fulfil them simply, because they are not proper. How much milk? Which brand? How many percent of fat should be inside etc. etc. What can I do? I can call my wife. She’s not available...at least most of the cases. Then let’s do some assumptions and by two liter of the most famous brand. In 99% of the cases it was not really what my wife expected...So how can make it better? I can check her list before leaving home and think about the potential questions, so just ask: “and how much milk do we need?” “which branch do you prefer” etc. and notice her answers. Once I think that everything is clear I can leave.
And of course that’s not everything. Sometimes she’s calling me as I’m in the shop: “Sorry, I forgot to tell that we need sugar as well” or “I changed my mind, I cook something else”. That’s something called requirement change.
In other cases I go to the shop and I realize that all beef is over. What can I do (especially if I'm too lazy to go to another shop)? Call her, announce her and try to come up with alternative, like “There’s no beef, but what about chicken?
And since my goal is to be a good husband I do everything to make my customer (khm wife) happy. And since I’m also a lazy programmer, I try to avoid double work, which is in this case the situation that I need to go back to the shop again.
This is something called requirement engineering on high level: try to understand the customers expectation, document them in a clear, non-ambiguous way, think about corner cases, make questions in case of uncertainty and track also the change requests. As a requirement engineer you are the transfer layer between the client, who is often not technically deep in the topic, and the programmer. You need to translate from the language of the customer to the language of the programmer. At some companies it is a dedicated role, but in several structures it is also a task for the developers.

Functional and non-functional requirements

There are two big groups of requirements: functional requirements and non-functional requirements. Functional requirements tell information about the functionality: what should the software do. Most of the requirement are functional.
Non-functional requirements are for example defining the environment (which operating systems are supported, which other programs needs to be installed) or the hardware needs (minimum RAM etc.).

How is a good requirement?

A good software requirement is unambiguous, clear, easy to understand, testable, atomic (can not be split into multiple requirements) and independent from the implementation. Practically you should avoid the complicated phrases, use simple sentences without “and” and “or” and always think on the level of user. That means don’t write that “the database layer should do … “. The user has know idea about the database layer. The requirement should be written really on the level of user. Usually the requirements are in present mode and built up by using the world should and shall. Example: “By clicking on the load button the “Open file” file browser window should be opened.” 
It is also good if you are attaching a high level test cases, how to test your requirement. It makes it more understandable.

How to document requirements?

The requirements needs to be documented in a version controlled format where all changes are stored and traceable. Each and every requirement need to have an identifier, so that it can be linked to test and to design/implementation. The requirements needs to be ordered. A good strategy is to order them by features. By reading the requirements the reader needs to get an overview about the software, so the requirements needs to be written in a structured way.
There are several software which are specially designed to maintain requirements, but they can even be stored in a simple text file.
Certain versions of the requirement document needs to be shared with the customer and discussed point by point.

How to handle requirement changes?

Requirement changes needs to be also documented in the following format: what has changed to what, which time, what’s the purpose of the change and in which software version need the related functionality be changed. With this manner you can avoid a lot of discussion with the customer.

Requirement and agile?

In most of the classical agile processes (Scrum, Kanban etc.) the requirement engineering is not part of the process, a requirements are documented in user stories and their can be overridden by any later user story. However in such an environment it is also possible to have one central collection of requirements and in case of complex systems it can help a lot on long term.


Of course requirement engineering is a complex topic and this short post can not go deep enough. Some people also things that requirement engineering is old fashioned, but based on my experiences it is very useful if you are working with clients, it can make your life much easier.


What is continuous integration?

Nowadays programmers are hardly working alone, most of the cases they are developing as a part of a team. Sometimes this team has just 3-4 members, but there are several huge projects with over 1000 developers. To organize their work is not easy. Not only from management point of view, but also technically.
First of all it is needed to track the different versions of the software. For that purpose there are several different version control systems (like Git, SVN, Mercurial etc.), but most of the cases it is not enough to have a version control system, you need to also make sure that the different versions are correct.

What is software integration?

Software integrator is a dedicated role at several companies. What does it exactly mean? Different components of the code and different part of the components are done by different team and different developers. They are all doing their part and sometimes doesn’t have an overview on the whole software. So in the end they are all done and they realize that even if their part is doing what is expected their code can not work together. Sometimes even can not build. It is because of different interfaces, different expectations from interfaces etc. Or simply after integration the software is becoming too slow or it is using to much memory. There are also different standards (coding guidelines etc.) which are not followed correctly in all code. These tasks are all the responsibility of the software integrator to make sure each part of the code is fulfilling the requirements individually and then merge them into one codebase and make it work. This work sound maybe easy, but most of the cases it is challenging. Furthermore it takes a lot of time. Just imagine, you are getting the work of several weeks from 10 developers and you need to make them work together...it’s a nightmare, right? Luckily there’s a strategy which make it easy, it is called continuous integration.

What is continuous integration?

The idea is continuous integration is not to wait until the chaos is becoming too large, but integrate the software as soon and as often as possible. Every day, or even after each change. Of course manually it is not possible, so the idea is to automate as much as you can. First of all you need a version control system, which is following the actual status of the code.
There are several checks which you can run automatically on your code base:
  • Build the whole code
    It is especially useful if you are working on multiple compilation targets, so you can build it for all of them
  • Run unit test
    As already discussed in my post about Test Driven Development it is also good to cover your code with unit tests, so that you make sure that the others who are changing your code are not breaking the already working functionality
  • Run higher level tests
    You can create also automatized component or integration tests and you can run them any time to check if the already implemented functionality is still working
  • Run static code analyzer
    There are several tools which can run a static check in your code. It can detect potential bugs (like usage of uninitialized variables etc.) and it can also check for the expected coding style or give suggestions for more effective code
  • Run dynamic checks
    There are several tools which can detect typical missusages like memory leaking or hanging of the program
  • Do measurements
    You can always measure the runtime of critical scenarios or the memory usage of your code. You can even measure the code coverage
  • Run additional scripts up to your needs
    It is always project dependent. For example in one of my projects we had a script which collected all TODO comments from the code, so that we could make sure before the release that all of them are already resolved.
You can run all these checks in any state of the code and give feedback immediately to the developer team though a status monitor tool or by e-mail notifications. So that the team has always an idea about the current state of the code base. It is a good strategy to keep all tests green.

Scale your system

To run all these checks on your code can take a really long time if you are working with a huge code base, especially because compilers and static code analyzers are usually extra slow. So it makes sense to run everything all the time, because it would cause a too long feedback loop. If you are getting the notification first after one day that your code broke something that does not help a lot. So you need to scale your integration framework.
A set of checks needs to be run after each change of the code base (after each commit), like compilation and unit test.
You can also set up a nightly job which is running several scripts every night on the code, so that the developers are getting feedback every morning: compilation, unit tests, higher level check, some part of the static analyzers.
Plus you can set up a job which is running all the checks, but this one you are letting run only for example once a week or before a software release.

Use frameworks

You could implement it all yourself with some scripts, but fortunately there are several frameworks which are already supporting this kind of functionality.
One of the most popular is Jenkins. First of all it is free. It is also very flexible. You can set up several kinds of jobs with several trigger actions. You can setup also different kinds of notifications. It has a plugin for several external tool (GIT etc.), but you can integrate any tool with a short script on any scripting language (python, bash etc.). It is created nice reports and diagrams which you can just show to your management.
What I want to say here is that you can setup such a system easily and fast and it makes a lot of benefits.

Define your integration strategy

You need to also design your integration strategy. If you are integration every change immediately to the final software then what can you do if it is breaking the build? It needs to be fixed and in the meantime everyone is blocked. That’s why it is a better idea to run first the checkers and integrate it to the main version only if all checks based.
There are also processes where you are developing the different components independently and you are only merging some dedicated “release” versions of the to the main software.

And there are much more strategies. You need to decide what are you merging to the main software when and how. Most of the strategies has its own advantages and disadvantages. You need to define which one is fitting the most to your project.


How to do a proper technical training for developers

Most developers really appreciate to have a chance to take part on technical trainings paid and organized by their company. It is really a good opportunity to learn something new and make the daily work more effective. There are professional companies offering trainings, but at several companies there’s an internal training system, where trainings are held by the employees of the company. Unfortunately a part of these trainings is just a waste of time and money, because they are not transferring the knowledge in the right way. To do a proper training is not easy at all, next to the outstanding technical knowledge very good presentation and teaching skills are also needed. In the post I collected several points based on my experiences which you need to act if you are holding a training for developers. And I think most of these points are valid for any kind of training.
  1. Know the knowledge level of your audience

    Before the training you should understand what is the current level of the group. You can have some personal talks with them or you can send around a short questionnaire some days before the training. You can also do a short introduction round at the beginning where everyone can tell what is their experience. Adapt your training based on this information.

  2. Set up an agenda, but also a bit flexible with that
    It is necessary to have an agenda for the training where you are collecting which topics need to be addressed. But also a bit flexible, if one topic requires a bit more time don’t change to the next topic without really finishing it.
  3. Less is often more Don’t try to address all topics. Try to collect the most important ones and let your audience understand that topics better. Addressing many topics usually means that the audience does not understand any of them properly.
  4. Plan breaks
    Noone can pay really attention on you longer than 90 minutes without brake. After 90 minutes at least 15 minutes long break it needed.
  5. Don’t plan too much for one day
    It is not effective to plan too much for one day. Sometimes I attended trainings which were 10 hours long. I don’t remember anything from the last 3 hours. The training shouldn't be longer than 8 hours per day (including breaks).
  6. Teach way of usage instead of pure facts
    It makes much more sense to show some working examples instead of showing slides with a lot of data, especially in the IT world. Everyone can find the raw data on the internet. A training should be more practical
  7. Be interactive
    Always try to communicate with your audience, ask them about their experiences, ask if they understood everything clearly, check if their really understood. You can also do some team work session.
  8. Do practical exercises in teamwork
    If you are doing practical exercises (like implementing a small program) do it always in teamwork. So that the group members will talk to each other about the material and they will point out themselves what they don’t understand clearly or if they misunderstood something.
  9. Concentrate on practical usage in their situation
    Always try to find examples from the field of your audience. So if you are doing the training for people working in banking sector don’t bring you examples from automotive business.
  10. Be open for questions
    Always ask it your audience have questions and give a full answer. Never tell that “sorry I don’t have time to answer this question”.
  11. Check what their understood from the training
    It is not enough to broadcast the information. You need to make sure if your audience really understood what you are talking about. If not just try to explain it from another perspective as well.
  12. Be available after the training
    A training does not finish at the end of the day. Your audience retrieved a lot of information, they need to process it, to try it out in practice. Most likely they will have questions after some days of weeks. Be available for such questions, either online or schedule a follow-up meeting.

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, wh...