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.

How to negotiate your work as a developer?

Effectivity has a different meaning for a manager and for a developer. As a developer you know about the task how complex it is. In case of managers sometimes you are doing something using really all your power, you think you were really fast and the management is not satisfied with your, in other cases you do something easy and the management will be really satisfied. Crazy…

The point is that as a developer one of the most important soft skills is the knowledge, how to sell your work. How to negotiate with the other how complex is what you are doing. If you are negotiating well you can make the management more satisfied even if you keep do the same work as before. It can be also useful to know how negotiate your work if you are working directly with the customer or if you are discussing with other developers.

So the goal is to show someone else, who is most of the cases not so experienced with the topic, that your task is taking a bit longer. These people often things that “you just need to add one more button, it shouldn’t be complicated”. What it means in the reality? You need to setup the environment, understand the existing code, change the frontend, change the backend, setup the communication between the frontend and the backend, test your functionality and update the documentation. Furthermore you need to take part all the meetings related to the topic. And all of this takes time, pretty long time, even if the functionality itself is not complex.

Earlier I have written about how to do an estimation. Now the topic is how to let your manager/customer understand your estimation.

If you are simple replying that “Well, to add this button will take me three and half days”, then the answer will be simple “no way, it is too much”.

First rule: always ask some time to investigate the task. It makes the feeling that you are doing a really professional estimation instead of bullshitting and of course you can also consider all circumstance which can influence your estimation.

Next rule: split your task into several subtasks (more is always better). And make an estimation for each of the subtasks.

Like:

• Setup working environment (get source code, compile it, install dependencies): 4 hours
• Read all documentation and understand the current implementation of the button functionalities: 4 hours
• Plan how to add the new button with the expected functionality: 2 hours
• Add button to the frontend following the current design: 2 hours
• Implement related functionality to the backend:4 hours
• Implement unit tests for the new functionality: 2 hours
• Connect backend and frontend: 2 hours
• Do functional level testing on multiple operation systems and fix potential bugs: 4 hours
• Code review and integration with the current code base: 2 hours
• Attend related meetings (planning, demo, review etc.): 2 hours

SUMMARY: 28 Hours

So now you showed that is takes 28 hours, which is exactly three and half working day. Most likely some of the points are a bit overestimated, like most likely integration won’t take 2 hours, but nevermind, at each task there are some unpredictable issues which takes time (not working compilation, magic bug, huge git conflict etc.), you can use the overestimated time there. Now since you have a nice detailed list noone can really tell anything against your estimation.

You need to always see the following: for most of the subtasks are used either 2 or 4 hours as estimation. It is on purpose: 2 hours is small enough, so no one starts to negotiate that “Could it be done in 75 minutes?”. No, 2 hours is short enough to be acceptable for any task. 4 hour means that it is more complicated than the 2 hour-long subtasks. Against that it is also difficult to negotiate: if the other task takes 2 hours and this one is more complicated then let it take 4 hours, which is a bit more than 2, fine. If your estimation for a subtask would be more than 4 hours split rather the subtask in multiple one. Because if you are telling that “it takes 10 hours” then it is easy to tell that “It should fit into 8 hours”. But if it is splitted into 3 clear subtask no one will argue.

It is also important: find names for the subtasks which are easy to understand also for the one who are not technically deep in the topic. It makes the feeling for the manager/customer, that he totally understands what you are doing (even if it is not true) and it makes more trust.

When you are talking about your estimations user phrases like “based on the experience from previous tasks”, “it is similar to one of my previous tasks”, “last time unit testing took also so long” etc. It makes the feeling the you are really professional and you really do what you are doing.

If the customer/manager still thinks that it takes too long you can just tell, that “yes, I see, this is current estimation, we can make it faster but leaving xy sub functionality”. So always offer a limited functionality which takes pretty clear less time for your to be implemented, but never tell that you can do the same functionality in less time, because it makes your whole estimation meaningless.

These are all my tricks I used at negotiation, I hope they are helping also for you! If you have other good strategies feel free to share them!

How to understand the managers?

All software developers need to corporate with managers and it also helps a lot for you carrier to have a good relationship between you and your managers, since mostly the managers can decide about your promotion, salary, project etc. Quite often the personal goals of a developer and the goals of a manager are going against each other and that means conflicts between managers and developers. To avoid such situation as first step all developers need to understand, responsibilities and goals of managers. By using this knowledge you can get better results from the discussions with your managers.

First see really briefly what are your main goals as a developer: you would like to have enough time to work on your tasks in a comfortable way, you would like to use the most modern technologies and try out all your ideas, you would like to participate on technical trainings, you need a good salary and good work-life balance. Most of these points costs money for your manager, but you can ensure all managers about your needs if they can see that it is beneficial for them as well.

As many companies so many different manager positions with different role description. I would like to focus on two main type of managers: the project manager, who is responsible for a project or subproject and the team manager who is responsible for a developer team. In some cases the two responsibility is owned by the same person. In other cases these roles have a different name. And of course there are other manager roles, like sales manager, but most of the cases they have less connection with the developers.

The team manager

The team manager has a team of developers. Usually the team manager’s responsibilities are the followings:

• Find the right team members (do the interviews etc.)
• Support the integration of new team members to the team
• Monitor their performance and skills
• Let them improve their skills in a defined direction based on project needs (for example sending them to trainings, find a proper mentor for them etc.)
• Provide the right developers with the correct skills and experience to the projects
• Collect feedback from project managers
• Do regular feedback sessions with the team members
• Setup goals for the team
• Organize off-work programs for the team
• Do decisions about salary changes
• Decide about holiday requests
• Remove the members from the team which are not fitting well into the team
• Regular feedback to the high management about the results of the team

That’s a lot, right. And to be able to do that the team manager needs to have a technical overview to identify the needed skills and good interpersonal skills.

There is one more important thing: most team managers has its own budget. That means the team manager is also responsible for some money. Here the incoming is from the projects achieved by the team. For example if the team is finishing with a milestone of the project there’s a predefined fix price coming to the team budget.

The costs are the following: salary of the team members, training costs, costs for equipment (computers etc.), cost for the office (rental fee, coffee etc.), costs for off-work programs etc.

Until the incoming is more than the costs everything is going well, otherwise the team manager will have certain issues. The project prices are usually designed in the way that if the team can achieve the projects within the planned time frame the team has profit and everything is fine. This will happen if well-motivated people with the right skills are working on the project. If you are in such a situation (you are working effectively and successfully on your current project) you will have a good chance to get higher salary. Or for example if you can prove that taking part on training is making you more effective on your project then you have a good chance to be sent to that training. Otherwise not, your manager won’t pay for a training which if not making your daily work on your current (or upcoming) project more effective.

Let think about situations like ramp-up time of a new team member. This is something called overhead, it costs a lot (salary, trainings etc.) but doesn’t earn money directly. Such periods need to be planned as short as possible. That’s why for example changing projects too frequently is not a good idea.

As summary: the goal of your team manager is to keep the budget balance in positive, so what ever you are asking from him need to refer to the fact that you work producing a good money for the team in the past or the investment would make you able to produce more money in the future. Of course it is not the best idea to use these words, but you should keep these thoughts in your mind.

The project manager

The project manager is responsible for one project or subproject. The goal of the project manager is to make the customer satisfied and to make the project beneficial for the company. So the tasks of a project manager are the followings:

• Regular communication with the customer
• Create time planning for the project (including main milestones, etc.)
• Create cost planning
• Create resource planning of the project (how many developers with which skills are needed in the different periods of the project)
• Track all progress in the project
• Regular reporting to the high management
• Organise the project meetings

What is important here: it is not a goal for the project manager to make you happy. His goal the reach the milestones in time. If overhours are needed for that the project manager doesn’t mind. If you are not working well the project manager will send a request to the team manager for an other developer. The goal of the manager is just to keep the plan.

The project manager is also responsible for the project budget. From cost point of view it means: the incoming is the paid price by the customer. The costs are the money paid for team manager for the work of the developers, the costs of the meetings, software licences and the travel costs.

So if a project manager asks you to do overhours he is just trying to achieve his personal goal. On the other hand it is good to have a good relationship with the project manager, because he is giving feedback about your work to the team manager, which can strongly influence your career. To be able to achieve a good relationship try to help him at planning phase with estimations which are as good as possible and then try to achieve them.

As summary it is good to have a good relationship with your managers. Never forget: without them your wouldn’t have a job, they are also part of the big machine, just like you. To be able to have a good relationship always try to understand their goals and try to support them to achieve these goals. That’s the best what you can do.

How to give feedback to your boss?

Most of the developers has some kind of feedback discussion with their boss. In some cases it is regular (every month, every half year etc.), in other cases it is only done if it has a purpose.

A lot of programmers have the feeling that these meetings are basically just getting the orders from their boss for the next time. But it should not be like that. It should be a bidirectional feedback session.

Of course your boss has some long term goals with the team and has some plans with you personally as well. These meetings are normally about these goals: giving you some personal goals which are supporting the long term goals of the team and giving you feedback if something is going wrong. It’s up to your boss, but sometimes this is the whole content of your meeting and nothing more. Luckily the good bosses know: without good and enthusiastic employees non of the team goals will be satisfied. That’s why good bosses are asking the employees as well what they are feeling what is their feedback. But to give a correct answer on these questions is not always easy. Some of the developers just telling that everything is great, even if it’s totally not true. Others are starting to complain about everything. These are not so effective strategies. In the first case your boss will never know your problems, so most likely they won’t change. In the second case after a lot of complaining your boss won’t take care about your problems.

But how to do it correctly?

First of all, let’s prepare yourself for the meeting. Think about the time period since your previous meeting and collect all the point what you have successfully done: achieved milestones, good customer feedback, achieving a small part of your goals defined with your boss, changing something what was a negative feedback last time. And think about the things what were not going well as well. If you missed something try to find the reason why (you were busy with some other tasks etc.). Next to that always try to think about that what was positive for you and what was negative for you in the last period.

On the meeting always let your boss start the discussion and never stop him/her talking, even if you strongly disagree with something. Always wait until you are directly asked. In the first part of the meeting always try present your results: always start with the success stories and after them mention some of your failed achievements. Always try to tell that you did you best, but unfortunately it was not enough. Like: “Unfortunately we were late at the delivery, we worked hard on the milestone, but a tricky technical issue came into the picture and it took a lot of effort to solve it. At the end we found a good solution, but it was unfortunately too late, hopefully next time it will be faster.”.

As next stage of your meeting try to tell your feedback to your boss: always mention some positive things what you like (good team, interesting tasks, flexibility etc.) and after that you can change to your negative feedback. Always try to tell them with a positive attitude and try to present your related ideas. For example: “Unfortunately we need to do too often over hours which I don’t really like. Of course I can understand that it is needed sometimes. I think it could be much better if we could extend our team with a new developer”. If a problem if coming back and back again you can be a bit more strict, you can tell that “this problem is there since months, I already told you multiple times and it is making me demotivated”. But important is: never make surprises to your boss, don’t be too aggressive if you are mentioning a problem for the first time.

Most likely your boss has some feedback for you as well and most of the cases it has some negative part as well. The important thing is: always take questions related the negative feedback, even if you are strongly disagree. “What do you exactly mean with this point?” “How could I do it better?” etc. And at the end just tell that “OK, I’ll try to change it”. Then your boss should be happy with this reaction, in fact he/she can’t tell anything against you after that.

At the end of the meeting most likely you will talk about your next goals. Your boss has most likely some ideas and probably you have some ideas as well. Let your boss present his own ideas first. After that you can answer in such a way: “ok, clear, I like this idea, however I think in this way it would be more effective”. And here you can present your own idea. Pay attention: always keep some parts from the suggestions of your boss, but always bring your own ideas with some good reasons. If you are doing this part well then your boss will think that you agreed his idea, but in fact it’s mainly your idea, which is totally different than his idea was at the beginning.

One more important thing: always try to document everything from these meetings, it can be helpful later on.

The next important point: if your boss is not organising such meetings with you, but you have a feedback you can always ask your boss for a feedback discussion. Your boss will think that you are highly motivated and that’s why you are asking for a feedback. But after his feedback you are free to present your feedback as well.

At last never forget: of course your workplace is important for you, but you are important for your workplace as well. If you don’t like something there always try to change it. And the first step of every change is to give a clear feedback!

How to manage your working time?

Most of the programming tasks have a due date for yesterday, but best case until end of the day. At quite a lot of companies it is a common practise to ask you to not to go home until your task is not done or asking you to cancel your holidays because of the current work situation.

On the other hand however people thinks that programmers have no life, most of the cases it is not true. Programmers have family, hobbies, friends and need for simple having rest.

And there is something what is called work-life balance by HR people, first it can sound as bullshit, but it is very important in fact, it is very important for you.

So normally you are working on a task which has a due date. And this due date is usually earlier than it should be. What can you do?

• Do some over hours/work on the weekend or during your holiday and finish it in time
• Being late with your task
• Show to your manager before starting your task that it is not possible to finish your task in time before you’re starting it

What will happen in case of the first solution: you are working when you shouldn’t. You will achieve the due date. Your manager will be satisfied and will find your next task immediately. So you can continue to work on the next day and you are loosing the time to spend with friends, family or having rest. On long term if you are doing it frequently your manager will know that you can achieve the critical tasks in time and will assign all urgent tasks to you. And this situation will happen to you more and more often. On the other hand your boss will be satisfied with you, but to be honest at most of the companies it is not honoured enough.

In case of the second option your task will be done late. Of course your boss and manager will be unsatisfied. There won’t be any feeling of success from your side. And you can block your colleagues in their work as well, since they may are waiting for you or for your inputs. It is a loose-loose situation.

The third solution it the one I would suggest to follow. For that you need to be able to estimate your tasks as precise as possible. It’s up to the company and working model who is estimating your tasks. It’s either you or one of the most experienced colleagues of you. If it’s you then it is pretty easy. Otherwise always check the estimation/planned due date before start to work on the task and if it is unrealistic for you let your manager know about that. Always inform your manager about the followings: what if a realistic due date in your view and how did you calculated it (show him all subtasks you identified and their estimations). If there is a possibility to skip any of the subtasks to make it faster (not testing a part, less documentation, less nice solutions etc.) let always mention it with advantage and disadvantages. Then it should be clear to your manager that your task won’t be done until Tuesday, only until Thursday. He can adapt his plan and you won’t block the others. And you can finish the task until Thursday without doing overhours.

Of course there are situations when it is not possible to change the plans such way, but most of the cases it is possible.

This is the way of working which turned be best for me to be successful in my work and having time for my family and friends as well.

If you have any other idea feel free to share it with us in a comment!

All the best for you!
RelaxedProgrammer

How could your manager understand your technical issues?

Talking about technical issues with managers, this is really a challenge, but it is quite often needed.

When is it needed:

• When you have a really good idea and you need an agreement from your manager to work on that. 
• When you need more time to finish your task as estimated. 
• When you need help to finish your task. 
• When it is technically impossible to finish your task with the current requirements. 
• When you need to show to your manager that you did something really great. 

Why is it so challenging? However most of the managers never forget to mention that they were developers at the beginning of their carrier, practically it happened in the previous century or in their previous life. To be serious of course they were developers, but it happened several years ago, so their knowledge is not really up to date and they forgot already a lot. On the other hand mostly they were not the best developers, that’s why they have chosen the manager carrier path.

So your first option to present your issue to tell it with every details in the language of developers, like:

“There is a potential memory leak in this class, because there’s an exception thrown in the desctructor before the deallocation of memory.”

Most likely your manager won’t understand why is it a problem at all so he/she will just ask “Is it a major or a minor bug in the system?”, “Does the customer know about that?” or something similar. Additionally he/she will probably feel frustrated. I think that’s not what you want. But of course if you are talking to an other developer or to a software architect this is the right way to tell it.

Second option is to present the problem like presenting it to you grandma who has no clue about programming, like:

“My code is doing what it should, but there is a small chance that something is going wrong.” The answer will be most likely be: “A code shall work always as it should, quality is very important for us, why are you implementing bad quality code?”. And he/she will think that you are totally stupid. OK, still not the expected reaction.
So what to do know?

1. You need to bring some technical details, but not too much.
2. You need to describe the technical background, even if it should be trivial for a developer.
3. You need to make the feeling to you manager that you are sure that he/she is understanding every technical details, like:
4. “I’m sure you understand that if you are not deallocating the memory it will cause memory leak”
5. Always start with a short introduction: what you code shall do by requirements, what is it doing know, what is the missing functionality.
6. Always mention the estimated time as well what you need to fix the issue.
7. Always mention the benefits of your change from the view of the user, like: the software will run faster, won’t use so much memory etc.
8. Talk slow and calm, look confident.

An example:

“I need to implement the shopping list functionality. I estimated 8 hours for this task and until now it took 7 and a half. Right now I can add elements to the list and modify them later. I have already implemented the remove element functionality, but when I was checking my code I realised an issue. The issue is the following: an exception is thrown in the desctuctor of ListElement class if the element does not have a valid id. The problem is that the deallocation of the memory is done after this exception and you know, now there’s a risk that the memory won’t be deallocated, which causes a memory leak. To analyse and fix this issue I need one more hour. After this fix the program will work as it shall and the memory usage will be optimal.”

Of course it is not taking one hour, just 15 minutes, but now you can have a long cafe break. And you manager will have an idea about that what you are doing, will have the feeling that you are doing something important and of course you can have some extra time to fix it. Furthermore he/she will have the feeling that you are a good developer who is finding bugs, communicating them in the right way and who is confident in technical work. On a technical level he/she will understand that something was wrong at memory handling and in our case it is enough.

Maybe it won’t work with every manager, but for me it helped a lot in my carrier.

What are your experiences? Do you have any other tips?

Best regards,
RelaxedProgrammer