Programmers and soft skills

Introduction

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.

Communication

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.

Presentation

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.

Summary

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?

Introduction

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?

Introduction

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.

Summary

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?

Introduction

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.

Summary

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.