Review and refactor plans

 

Such like in software development, we must be agile in our personal life too. There is not enough to create and complete our plans. Our life always changing and we should be prepared to the changes. That is the reason why I regularly review and sometimes refactor my plans.

Review and refactor goals

Introduction

I had a great training plan that should cover all of my learning for the next year: I have decided to gain a basic knowledge about web development using .Net related technologies. My goal was creating a clone of a Microsoft Todo site on my own and on every step, I wanted to learn some new stuff.
There is only one fix point in our life. That fixpoint is changing. Life does not care at all about my goals. We got a great push at my employee and we must change our technology stack. We have to use a Java stack instead of .Net.
That basically means, for me, there is no reason to finish my learning plan just because I do not even know if I will be able to use that knowledge at all. Instead of that, I will learn Java stack.
For me, that is not a big change but a change. It is relatively small change because I will still work on a web project. That means I still have to learn web development. But the technology stack will be another than the chosen one.

Reviewing plans

Reviewing our plans is really simple. We just have to go through on our goals and check their progress and their purpose of existence. By checking progress, we can review our time estimates. We can see if we need more or less time for a given kind of topic and we can modify our deadlines. When we are reviewing our goals, we can validate if we still need for a given goal or maybe we have to alter them or drop a goal at all. Maybe we can reprioritize our goals and add new ones.

How often

I think the scheduling is very important. If we review our goals every week, we will be stuck in the first step and go nowhere. For me, the best way to review my goal is really simple: I create an event into my calendar in every quarter to review my progress and I review my goals every year.
Between these checks, I just Trust the process and do my job as good as it possible.
Do not forget. These are not rules, just recommendations. As I had already given an example, in the beginning of this post, sometimes I just cannot wait until the next goal review session – In that case, I just do it as soon as possible to avoid to do unnecessary work.

How to review our goals

For each goal, and each larger step, I ask the following questions for myself:
– Is that goal still valid? Do I have to complete it?
– Could I make progress? Can I hold my deadlines?
– Do I need to refactor the goal or align more time?
– Has the priority changed during the last period?

Question list
Go through question list

After answering these questions, I will have a list of actions that I have to do.

Refactor plans

After the review, there comes a refactor. The result of the review progress is an action plan. I just go through my action list and do all of them. After that, my review and refactor session is complete. I just open a beer and start to work.
Do not forget to refactor all the key points
One thing that I cannot tell enough time: It is really important to check the deadlines, priorities and our committed time that we want to spend on achieving our goals.
There is no reason to just simply modify our goals without thinking through the deadlines. Also, lifestyle changes and it means maybe we cannot spend 15 hours of learning in the week just 10. Skipping these can cause some unacceptable results on our next review session.

Closing thoughts

As you can see, making our plans is not enough: we have to be prepared for change. There is no reason to fear the change or fight against it. We just have to accept it and make it as less painful as it possible. Also, as much as we can we have to be proactive instead of reactive.

Remote code review

Code review is one of the best tools for developers to make good quality software. Code review means you show your colleagues your work, they read your code, ask questions and give you some advice about improving your work. A good review can greatly decrease the number of bugs, so if you work in the environment, where it is not common to do code reviews, I highly recommend to introduce it.

When I was a junior developer there were only one person who I was thinking about: It was me. I have written my code, sent a mail to the team to ask for a code review and went to the next item on my to do list. Today, I think this is the most inefficient way. Imagine that you get an email to review a code and you know nothing about the task, about the requirements, generally you are not familiar with the context.

Do not worry, it can be worse: what will happen if you get the same email with high priority and you have to throw away your current work and try to figure out the code that you see. You will ask a lot of questions about the task and interrupt the other side multiple times to get the picture. That is the perfect way to waste working hours of several people.

How to do code reviews

The best way to do code reviews is as follows: do everything that needs to be done to minimize the interruption of the reviewers time and help them do their work as fast as possible. I know my teammates and I almost always know who will do the code review. The reviewer has to be able to allocate time to the review, so my job is to gather all the necessary information form him/her to be able understand the task and get the picture and schedule a review meeting for the next day. The reviewer will have only one job: accept the meeting and take time only for the review. Actually I solve two problems with that:

  1. I create a time window for the review. There will be no interruption at all.
  2. Reduce the number of possible questions. The code review will be more effective.

Code review as a remote programmer

If you work remotely, you become an invisible developer. You cannot just walk to your colleague to schedule a meeting for the next day and prepare him or her to the code review next day. And you also cannot sit down next to the reviewer to help to understand your code.

Actually, we live in the 21st century so we have really great tools that can support us to do the proper communication. I give you some examples of software  I use every day and they are very useful if you want to do a code review online:

  • We use Outlook. This is a great tool. If I want to schedule a code review session, I just use the scheduling assistant, so I do not have to disturb the reviewer to find the proper time. I pick a good and short topic for the meeting, e.g.: ‘Code review – Refactor new login flow’ and I always fill the description with the necessary information that helps to understand the change.
  • JoinMe is the next great tool. I can create a personal URL that contains a single link. If you schedule a meeting in Outlook, you can add the place. As I am invisible in the office, the place will be always a JoinMe link with my personal URL. It is easy to remember and the reviewer has nothing else to do but click on the link.
  • A great diff application. Yes, I know. If we use proper version control, we have pull requests and we can check the diff easily. However, I always find some exception and for that case, I have an application installed called WinMerge and I am able to show any kind of diff with that.
  • A great diff tool for version control. Sometimes I have to check some diff in my local computer. If you have ever tried to use the embedded diff in SourceTree, you know it is terrible. I recommend to set up P4Merge. It works perfectly with SourceTree.

Human factor

As a developer it is easy to forget, but we work with human beings. That means we can have any kind of software toolset in our repertoire if we do not care about our colleagues. It is really important to know the people that we work with to be prepared for their reactions.

My examples for my boundary personality types

The easiest personality type: the silent thinker. The analyzer.

I know a guy who needs no instructions at all. He is a typical thinking machine. I put the ticket into the machine, it processes it and sends the output. That is the example when you do not have to schedule a meeting. You will receive a whole list with his findings and you can talk all of them in a short call later.

My hardest type: the important man.

I know an other guy who thinks he is the most important man in the Company. If you want to ask him you have to be prepared. If he has any question, he calls you immediately. That is the hardest type. I had a lot of painful code reviews until I could figure out the solution.

He does not need any written information at all: I just have to call him one day earlier, tell him that I really need his help and it would be great if he could help me on the next afternoon to walk through my work. After that, I tell a brief introduction about the task and tell him how much time I will need next day.

Actually, I tell him the very same information that I would write down to the meeting description for other people. I can write down the description and read that for him, it does not matter. He will never ever read the description. He just needs to know, that I need his help and he is really important to get the job done. Next day, I call him again to tell I could finish my job and I kindly ask him sacrifice some of his time for me to check my work.  He says ‘OK, show me what you have’ and we are already in the finish. He does the code review.

Handling different personality types

I only introduced two examples: the easiest person type and the hardest person type. Actually every person is different and they have different behavior. You have to analyze your colleagues and find the best way to handle each of them. Maybe it is some extra effort, but it has huge benefit and  it will help you a lot during your daily job.