3/20/2019

Working With a Remote Developer Team

Thanks to the internet, the whole world has changed a lot during the last 20 years. New professions have appeared and the earth has become more international. There’s much more cooperation between people from different points of the world nowadays than ever before.

These changes have influenced the life of software developers as well. Can you imagine developing without an internet connection? No? Me neither.

There’s another big change: Earlier developers worked either alone or with people sitting in the same office, but today, it’s different. You can have team members from all around the world.

More and more companies have offices in multiple countries, and they are building international teams. It is totally normal to work with colleagues from India or from Russia, even if you are sitting in Germany or in the U.S.

I have also worked with remote teams on several projects, so I already have some experience with it. During the previous day, I was working with developers from India and Ukraine. I met a lot of nice people and learned a lot about their culture, which made this cooperation very nice and colorful. However, such cooperation is never easy.

It always takes a long time to set up an effective team structure, and both sides need a lot of patience due to the different work habits of the remote team members. All things considered, I really enjoy working in such a mode, and I hope I will have more chances for that in the future.

Why Companies Opt for Remote Developer Teams


I see two big advantages of this working model from the company’s point of view.

The first advantage is that it is really difficult to find good developers in places like Silicon Valley or Germany and at all places where there’s a lot of tech companies around. The big tech companies are usually located near each other to be able to set up good connections between them. On the other hand, there are several countries around the world that do not have their own big tech companies, but they have plenty of software developers, so it’s better for the big tech companies to build up parts of their teams in these countries.

The second advantage is all about money: There are the so-called best-cost countries, where there are developers who work for less than half the price as workers from other countries, and with such a salary, they still make far over the average in their country.

I don’t know how long this working model will stay so popular, but it is just becoming more and more popular every day. If you are a programmer or you are leading a programmer team, there’s a good chance that one day you will contribute on such a team.

Advantages as a Developer to Work With a Remote Team

When I was a child, I always wanted to have friends from several different countries. I was curious about how they were living and what their habits were. Later, as a student, I had a chance to meet some people who came from other countries, but still not many. As I started to work at an international company, where we worked with remote teams, I achieved what I wished I could as a child. Thanks to this working model, I gained several colleagues from all around the world. They usually visited us, and I also had a few chances to visit them to travel to such countries where I had never been before. I learned a lot about their culture and habits. I also learned different ways of thinking, which helped me a lot.

So, working in such a structure gives you a chance to get to know people who are living far from you to taste their food, to get familiar with their culture, and sometimes also to visit their place. Traveling around the world on the company’s dollar sounds good, right? Furthermore, it is also a good chance to learn languages, especially to learn English, since that is the language used at most of the companies.

Main Challenges of Working With a Remote Team

As usual, along with the advantages of this working model, there are also several disadvantages. But let’s think in a positive way and call them challenges instead, and see what solutions are possible.

One of the biggest challenges I experienced is the limitations of online communication. If you are working in the same office with your colleagues, you can just ask them anytime if something is not clear—you can show them your monitor, get quick support, and it is really convenient. You can also hear what your other team members are talking to each other about, even if you are not directly involved in the discussion, so later, if you are facing the same issue, you know who can support you.

Furthermore, a lot of really informative discussions are happening out of the office: in the canteen during lunch, in the kitchen next to the coffee, or at an after-work program in the evening. These are all ways of communication that cannot really be done with a remote team.

Also, quite often, the remote team members are not native English speakers, which can also cause some misunderstandings.

Another issue with communication is the time difference.There could easily be several hours’ time difference between the two parts of the team, so the working hours do not really match.

Last but not least, I need to mention cultural differences. If your team members come from a different culture, they can have a different religion, and different habits.For example, it was really surprising to me when all my team members disappeared for a while after lunch. Later on, they told me that they were praying. It was a normal daily routine for them, and something totally new for me.

There are also differences in the working culture. For example, I’m working in Germany, where I have to give three months’ notice of when I’m resigning my contract—more than enough time to find someone new to the position and transfer all the knowledge. As I was working with people from the Ukraine, they had a notice period of two weeks. From the two weeks, it was quite normal that they took some holidays. So they had maybe six or seven more days in the office. You simply had no chance to keep the project stable if a key member had just left.

Best Practices for Working With a Remote Team

How is it possible to work effectively and solve so many challenges? Try these tips that have proven successful for me throughout my experience.

Meet Regularly


At first, it is really useful if the members of the team are visiting each other sometimes. It is good to meet personally with your team members so that you can also get familiar with the culture of your colleagues. The communication is much better between people who know each other.

It is a good idea to organize business trips for the ramp-up period of the project and for bigger workshops. On the other hand, such business trips cost a lot, so most companies are really limited.

Trust in Your Teammates to Work Well


Based on my experience, the most important tool needed for cooperation is trust: You need to trust in the knowledge of your colleagues, and you need to trust that they will achieve their tasks before the due date. If you are checking the status every day, that will just demotivate the remote team.

As you start to work with a remote team, first try to understand their working style and let them understand your working style. After that, try to set up your cooperation in a way that fits all working styles.

Always handle your remote colleagues as equal partners. Try to set up a core working time when all parts of the team are in the office. Figure out the time frames when the remote team is normally not available (due to lunch, praying, etc.) and don’t call them during that period. Also, synchronize your national holidays.

Clearly Understand the Tasks


In most cases, one part of the team has more information about the tasks because they have more experience with the topic or they are at the same place with the product owner, who can answer all questions regarding the tasks. This part of the team is responsible for transferring all necessary information for the remote team.

To avoid misinterpretations of the tasks, the best practice is to use written communication forms that are visible to the whole team, such as ticketing systems, chat groups, and e-mails. Provide all the information to the remote team, let them read through it, and then let them ask questions. If you are not sure about something, check the points with the product owner before answering them. Always document all questions and answers in written form.

If you are in the remote part of the team, always try to get a clear understanding of your tasks. If you don’t understand, collect your questions and send them to the so-called “local” team. Do not start to work on your tasks until you are 100 percent confident as to what you really should do. It is also good advice to create a short implementation plan and discuss it with the team before the implementation, especially if you need to change multiple components in the code.

If any questions come up while working, feel free to write to your team members. To clarify such questions, a short call with screen sharing is one of the most effective ways.

To integrate all the changes on the codebase, it is a good practice to have one dedicated software integrator who reviews all the changes, integrates them into one code, and tests it.

Learn to Work Effectively With a Remote Team


Working with a remote developer team has become much more common in the last couple of decades. Communicating with coworkers from around the globe is quite challenging, but it is doable if all parts of the team are handled as equal partners.

If there is respect and trust within the team, and the communication is done in a clear, well-documented way, there is no distance too large to work effectively and productively with your team members.

3/13/2019

I’m new from the university - Let’s understand different roles

At most of the software companies there are several different roles: project manager, team manager, software architect, lead developer, technical leader, software tester, scrum master, product owner, junior software developer, senior software developer, system engineer, requirement engineer etc. If you are new in the world of software companies it can be quite difficult to understand the meaning of these roles. It’s because sometimes the same role has different names at different companies or the same name means different role. Plus some of these roles are really similar to each other, but still not the same. In this chapter I’m trying to give an overview about the meaning of these roles. But at some companies it can be different.

Trainee:
This is normally a position which you can take over as a student. Normally it’s a part time job and you can support the developer team with implementation of tools or smaller features. This is normally the first step of your carrier.

Junior software developer:
A junior software developer is normally a software developer who has less experience and can work independent on features and software components, but still need regular support and leading from the more experienced colleagues. You can take over such a position normally after finishing your studies/working for a while as trainee. This is really a good position to learn a lot about software development.
Senior software developer:
It’s up to company, but normally your next career step after being a junior software developer is something called simply software developer or you are going to be immediately a senior software developer. A senior software developer is an experienced software developer (usually has at least 5 years of experience), can solve problems independently, can choose between technical proposals, has a good overview on the overall development process, can make solutions for new problems as well. Normally a senior software developer should be able to support the junior colleagues.

Software architect:
A software architect is responsible for the design of a software. That means a software architect is creating software design and makes sure that all the implementation is following the design (normally it’s done by code reviews). A software architect needs to have a very good overview, needs to know the related technologies well.

Technical leader:
At some companies each project has a technical leader. A technical leader is normally someone who can take technical decisions and who is technically responsible for the product. A technical leader is most of the cases overtaking the software architect tasks as well.

Lead developer:
Lead developer is typically a role at smaller companies. It is usually a mixture of technical leader and project manager.

System engineer:
The system engineer roles exist usually at products which has a close relation to the hardware (embedded development etc.). A system engineer is usually not deep in coding. A system engineer needs to plan how the whole system will work: why inputs are provided in which format, what are the states of the system, which outputs will be provided, what are the corner cases and limitations of the system. The system engineers are using quite often some modelling software (Matlab etc.).

Requirement engineer/Buisness analyst:
A requirement engineer or buisness analyst needs to understand what is the expected behaviour of the software in different use cases and document them in a clear, non-ambiguous way. They need to think about corner cases as well. Requirement engineers are usually not deep in code. This role is quite often overtaken by system engineers.

Software tester:
A software tester is someone who is creating test plans based on the requirements of the system and after that runs manual tests or implements automated tests and book the result in the correct format. A software tester needs to understand the requirements well and needs to think about corner cases. Most of the testers know some scripting language and test framework for automated tests.

Project manager:
The project manager is responsible for the planning and tracking of the project from budget and time point of view. That means: it needs to be planned: what will be done, when and by whom and the project manager needs to track it. If something is going wrong the project manager needs to identify and help to resolve the issue (like needed trainings, missing inputs etc.). Usually the project manager has direct connection with the customer and needs to report the state of the project to the higher level management. The project manager is responsibility is that the project needs to be done in time and inside budget. At some companies the project manager activities are shared between multiple managers (one is only responsible for time planning and tracking, one is responsible for the budget etc.). The project manager has normally some technical knowledge, but most of the cases the project manager is not deep in code.

Product owner:
Product owner is a role in scrum projects. The product owner is the one who has a good understanding of the project goals and requirements and who is creating clear user stories from these requirements. The product owner is setting the priority of the user stories and well. The product owner is always available for the development team but is not part of that.

Scrum master:
Scrum master is a role in scrum projects. A scrum master is supporting the team to keep the scrum process. A scrum master can be a developer as well in the same time.

Team manager:
A team manager is responsible for a bigger team and multiple project. The team manager is responsible for hire new colleagues, do regular feedback meetings with the employees, identify needed trainings and send the right colleagues to the trainings, supporting employees to reach the next step in their career path, motivating employees, identifying and tracking goals for the employees, do resource plan between the projects etc. A good team manager has experience in development, project management and has good interpersonal skills.

I hope it helped a bit to understand these roles. But as I said there can be big differences between companies.

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