How to manage your holidays?

Let’s take an easy, but great topic today: the topic of holidays.

I think holidays are very important for programmers, that’s the time when you are really leaving your life, except is your work is your life.

The amount of your holiday is pending on the country where you are leaving and your company, but the big question is: how to use your holidays exactly when you need it?

At most of the companies there are critical periods from holiday point of view: the periods when all the colleagues would like to have holidays (summer holiday, christmas holiday etc.) and the periods which are critical from project point of view. The first ones are quite predictable, the second category is unpredictable.

At the beginning of my carrier I made the mistake: I thought that it is enough to request for my holidays two weeks earlier. So in the mid of the summer I just decided to visit a festival, I requested my holidays and the answer was: “sorry it is a critical period right now in the project, you can’t have holiday now”. Ok, shit happened. For the next year I set up a strategy regarding holidays which is working well. This is the following:

Plan your year in the beginning of January and request for holidays. Plan holidays for the fix yearly programs and try to predict when be enough from work (it is good to plan some day in every third month based on my experience). That means you are the first one who is requesting for a holidays for the critical periods, you are the winner. And in January nobody knows when are the critical project periods, so it can’t be a reason for rejecting. Later on if someone is telling that there’s a critical period during your holiday and you should cancel your holiday, you can simply tell, that you already reserved something for that period.

If your plans are changing in the meanwhile you can still reschedule your holidays, your chances are still not worse than without planning.

This is easy and nothing special.

And just a short suggestion: never cancel any planned holiday because of work pressure!

All the best!

RelaxedProgrammer

How to handle projects with bad code quality?

The today article is a bit more technical as the previous ones. I think all the programmers have some experience with bad code quality. The first rule of “shity code” is that it was always done by someone else, but not by yourself… At least that’s what I’m always hearing. So I don’t know where are the guys, who are writing the bad code, but once I would be glad to drink a beer with them. The second rule is: the code quality of the project you are working on is always the worst code you have ever seen.

First of all there are a lot of books about how to write nice code. The Bible of this topic is the book “Clean code” from Robert C Martin. But it’s only mentioning how to write a nice code from scratch and not mentioning how to deal with an already existing bad code.

One solution is for sure to refactor the code base, in a lot of situation is means rewriting in fact. But at most of the projects there’s no time or budget for that, so your manager will say a clear “No”.

That means you need to live together with the bad code: stupid naming, monster functions, shared variables, super classes which are responsible for thousands of things and stupid comments. Let’s see how to survive in such an environment.

If you need to understand what the code is doing the best way to do is to go through the code first and after that try to debug it. It is complicated and time-consuming, but that’s the best what you can do in such a situation.

But how to deal with code extensions? If someone needs to add some small functionality or change the current one quite often I see the following solution: “this code is already a big chaos, so let’s just put some new lines to the existing functions or comment out some of them and we are done”. This is the worst what you can do. You are simple encreasing the chaos and the code will be always just worse and worse. First of all: never comment out any line of code, if you don’t need simple delete it. On the other hand: if you need to add something new to such a code always try to add it as seperated as possible: try to create your own class or function which is well designed, has a clear interface, clear responsibility and good code quality. And now the only thing what you need to do is to call your new functionality from the old code. You are not decreasing the quality of the existing code and you are doing your work with a good quality.

If you are more motivated you can separate some part of the old code as well every time when you are adding new functionality. That means you are not only separating your new code the a new class, but you are also separating some code from the class where you are calling your class. And at separation you can do some small corrections as well: better naming etc.

With this method sometimes you need to code a bit more, you need to think a bit more, but your code will be always just better and better instead of being worse and worse.

In my view dealing with code quality is something what is there during the project lifetime: from the very first design plan until the last bugfix.

Do you have different experiences?

See you next week!

RelaxedProgrammer

How to deal with stress?

In this article I won’t tell you any secret magic which counts down with all the stress during your work and I don’t wanna write like a “positive energy coach”, because I think it makes totally no sense without some more concrete points. But if I ask any of the good software developers about that what is the most difficult part of their work, some of the following expressions will be part of the answer for sure: pressure, stress, too much work. So I think it makes sense to talk about this topic.

The stress if there for everyone, the most common sources of stress are time pressure, technically difficulties, bugs and communication with colleagues and customers. Some of the developers can handle stress quite well, some of them have a worse stress handling skill. Usually the ones with better stress handling can reach better positions during their career, better work-life balance and all things considered they are happier.

When I was a beginner sometimes I had the feeling, that I’m the only one who is under stress and the more experienced colleagues are not under pressure. Later I realised that it was not true at all. They were stressed as well, but they could handle it. Later on during the years I learnt to handle it in a better way, but sometimes I’m still having difficult weeks. These are the most important points in my view:

• Always know what is your motivation to work there, why you are doing it at all. For example my motivation is to bring the best life quality to my family what I can. For that I need a job with a good salary and with good work-life balance. Next to that it is making me fun the develop my technical skills. Find what is your real motivation and think about that in difficult situations. It’s giving you some energy.
• Try to always do your best, but not more than that. So if you have a challenging task first of all try to understand before starting with that if you are able to achieve it in time and if you have the needed skills or not. If not ask for support in time. After that try to do your best during your working time. But if it is not enough to finish the task in time, don’t worry, always think that you did your best.
• Always communicate in a clean way. If you are seeing in advance that you won’t be done in time, just tell it to your team and manager, avoid surprises. But of course always make sure them that you are doing your best. Unless doing it in this way the others will think that you are not motivated enough.
• Don’t let yourself stuck in uncomfortable situations. If you’re feeling yourself uncomfortable, because of your tasks, colleagues etc. always let your team lead/manager know that you are feeling uncomfortable with the current situation. That is the way to give it a chance to change your situation. But you need to know, most likely it won’t change immediately, sometimes it needs some time.
• Never communicate in an aggressive way with your colleagues and customers. If you are angry rather go down and walk a bit or drink a coffee before writing your e-mail or talking to your team mates. Always try to tell them your point in a calm way. Aggressive communication is just generating a stressful working environment.
• Don’t think that other projects are running better. I was working at different companies on different projects, but one thing was common: the project was always behind the schedule. As I was talking with other programmers they had similar experiences. It’s so because that’s one way how managers are trying to let work done faster: if something is running on schedule let’s reschedule it and let the project have less time/workforce.
• Never forget: if you are a good developer you will have a job even if your project or company is failing!
• Go through on previous articles about How to manage your work time and How to estimate your tasks.

These were all of my points, but I hope you can extend them with some new ones!

All the best!

RelaxedProgrammer

How to say no in a nice way to a meeting invitation?

Most of the software developers hates meetings. Especially if they have no additional value for the development.

Ok it is clear, some of them are boring, but still needed. On the other hand some of them makes totally no sense for the whole development team. Of course just to decline a meeting is really not nice. What else can you do?

First of all never attend any meeting which has no agenda in the invitation. If so, then send an answer and ask for the agenda. Once you have an agenda go through and check which points can be relevant for you. If there are no relevant points ask the organiser why he/she invited you and what he/she would like to discuss with you. If there’s no “good” answer, you can simple tell that you feel it unnecessary to attend the meeting and if it’s ok you won’t join.

If only a part of the points are relevant for you, then you can suggest to the organiser to organise the agenda in a way that all relevant points are after each other and you are only attending to that part and not to the other ones.

If most of the points are relevant, but you still don’t wanna attend then check who are the other invited ones. If there’s someone else who has more or less the same knowledge in the relevant topics as you (like a teammate) then tell it to the organizer that you think it would be more effective (effectivity, it is an important keyword if you wanna ensure a manager!) if only one of you would attend. Once the organizer said yes to that ask the colleague if he/she plans to attend the meeting. If the answer is yes you don't need to attend.

All things summarized never tell "no" directly. Try to show that it is not really necessary for you to join the meeting and try to show that participation on the meeting would decrease your effectivity.

That’s the way what is working for me, but if you have any better idea feel free to share with us!

RelaxedProgrammer

How to estimate your tasks?

Effort estimation. That’s something what you need to do quite often if you are working as a developer. It depends on your company’s working structure and methodology how often and for how big tasks do you need to do it, but it is almost sure that you need to do it.

More and more companies are following some agile software development methodology, in this case you need to estimate only smaller tasks, or if a task would be too complex you should propose to split it into multiple tasks/subtasks.

If your project is following some classical methodology (V-model, Waterfall etc.) or you are a more experienced developer and you need to support new projects with some high level estimations, then it can happen that you need to estimate really big tasks (months/years of work).

Doing a proper estimation is not easy at all, but it is really important for the management, since they can plan the work after your estimation. So if your estimation is too low the management will still expect from you to done the work inside the estimated time. That means you will be really under pressure which is of course bad for you, so try to avoid it. Too high estimation is basically good for the developer (OK, it can be boring if you have nothing to do), but bad for the management, since they are even paying for the part of your time, which would not be really necessary for the task. That’s why managers always try to ask you to decrease your estimation. But how to do a proper estimation?

First of all try to split the task into subtasks: try to have subtasks, which are easier to estimate, like implementing one well specified functionality etc. At this step don’t forget about non-implementation tasks: technical planning (design), code review, testing (manual testing still takes some time), documentation etc.

As next step you need to estimate all the subtasks. Here always try to do it based on some similar tasks which you have already done in the past. Do not estimate your time in a way, that if you sit down and just concentrating on this then you may finish it in 4 hours, because usually it is not the case. Calculate it in the way how you are really working on a normal day: you are drinking a coffee, having a cigarette, doing some short talk with colleagues, checking your e-mails and in the meanwhile you are working on your task. Rather say: OK, I can do it in one day, with a comfortable velocity. Count always with possible bugs: maybe your first implementation won’t work as is shall and it takes some time to figure out the root cause. Or maybe you will have some issues with the version control system.

Especially if you have less experience with the task it is a good practise to do two estimations parallel by two developers, compare and discuss the results later.

One more trick: always try to work with some predefined possible estimations: like 1 hour, 2 hours, half day, one day etc., then it is easier to decide to which category does your task belong.

In the end you have a list of subtasks (to do list) with some estimations. So that if someone asks you why is it 1 week and if it could be decreased just refer to the to do list. If your manager would like to decrease the working time always propose to decrease the to do list as well, like: if I don’t implement 100% code coverage unit tests, just 50%, then I can save 2 hours on testing etc. But never decrease your estimation without changing the to do list, that looks unprofessional!

What are you tips and tricks for estimations?

I wish you a nice day and good luck at estimation!
RelaxedProgrammer