Are you victim of Stockholm syndrome?

I recently listened to a podcast called ‘Developers Life’ where a couple of developers and project managers talked about some rotton projects they’d worked on and how it’s sometimes hard to get perspective and realise that some projects are so bad they’re more bother than they’re worth.

When you’re a developer or project manager working in a framework like Scrum, Kanban or Agile, you can usually look over at the wall and see a big white board with the name of all the projects, and all the stories pertinant to them. The stories will all be in different states: ready for dev, in development, in testing etc.

From a success point of you, you and your team might be cracking the project and delivering the code to the client; but there is another issue you may need to consider. Can you remember how long the project has gone on for? Did you notice that customer or product owner keeps changing their mind all the time, or do you feel they’re doing other things to unwittingly sabotage your work? Did you find out yourself implementing the same functionality again and again?

I know it’s the client’s money, and I know it’s the money that pays your wages and enables you and your team to buy all the fancy toys for you want or need. However even though money is good in the short term, in the long term the happiness of you and your team is much more important. Bad, negative projects are out there all the time and what’s even worse is that you could be working on one right now and you haven’t even noticed! If you are, than I am sorry to say – you could be victim of Stockholm Syndrome!

Stockholm Syndrome, as many of you probably know was observed in Stockholm, when, “bank robbers held bank employees hostage for 6 days. The victims became emotionally attached to their captors, and even defended them after they were freed.” (source:

Imagine that, 6 days in a terrible environment with violent people. Could this make you lose your “common sense” ? Now, how long have you worked on these bad projects? They last for longer than 6 days don’t they? You might be working in great environment with great people, which this actually could be much worse, because the beast is out there and you didn’t notice. You are a victim, and you should be freed, but how you can tell if this is really the situation you’re in?

Don’t worry, there is a way to recognise what’s happening. One solution could be found in doing retrospectives. It’s good practice to do retrospectives because it allows you to improve your process and you’re taking an active role in solving any problems with the project or the team. It’s about upfront communication. That means if you notice there are repeating complaints about the customer or project’s craziness, you can let everyone know and solve the problem quickly and for good.

Another way to realise that there’s something wrong is Pareto principle ( also known as 80/20 rule. In short, roughly 80% of the effects come from 20% of the causes. That means you can spend so much time and effort to keep going on a nightmare project, but the income and achievement just doesn’t match up. The last way is outside observation by somebody who is working in your company or for your company, but not on the same project. This person could give you proper insight.

Do you have any other suggestions of how to be aware of Stockholm Syndrome in your project ? If yes, then share it with us please :).

Pair programming with your mind

My last post was about pair programming. Recently I start working on a small project where I can’t pair with anyone. So I started thinking “what could I use from pairing even When I’m not ? “.

My first thought was to act as if I was, so I would have to act as 2 different people. I should change my t-shirt and wear a hat or just put on glasses and change my hairstyle every time I change from one persona to another, but this could look really strange and potentially have detrimental consequences.

Another thought was, “Hey what are the advantages of pair programming which don’t depend on the other person directly” ? The answer is a better understanding of code, cleaner code and faster development. But how exactly would I achieve this? Let’s find out!

Better understanding of code

Better understanding of code is based on the fact that you explain your implementation to your partner. You can still do this, and very often you are actually doing it without noticing.

If you are speaking or just mumbling to yourself out loud then your brain is using different parts then if you were just “thinking” about the problem. So if you ask yourself out loud “Why doesn’t this work?” or “Ok this points to that if the value is….” then it is same as if you were speaking to someone else. Even if you ask yourself “What would Mr X do?”. Than you force yourself to look at the problem from a different perspective it would also help you.

Faster development

In pair programming you usually switch between each other for short time periods or small problems. This could be easy implemented and the answer is sprint. Pick small timeframe (10 minutes) in which you can implement some functionality. Then you set your watch or phone or some tools that you can download and start. You will see that you are trying to finish your code in the time limit (including your tests of course ;-) ) which will speed up your programming.

Cleaner code

Cleaner code is basically only about you, and because nobody is watching, you tend to not care that much about sanity of your code.

When I start programming in Ruby my friend who taught was really strict about code sanity. Every time when I paired with him, he would point out every small thing e.g. end of the line, space between operators etc.. So I was forced to care. Since then even when I’m not pairing I always make sure my code is clean enough to satisfy his sanity check. So imagine somebody who’s got your respect and is really anal about clean code. Try to not disappoint him.

These three rules will help you in your “virtual pair programming”. If you have another technique feel free to leave a comment!

How to tag SVN branch on the server from Git repository

Image the following situation:

You are using SVN on the server and to deploy on the server you have to TAG release. You are using Git on your local machine and you have following commits.

Image the following situation:

You are using SVN on the server and to deploy on the server you have to TAG release. You are using Git on your local machine and you have following commits:

Task is to create the SVN branch from first red dot and than add the another commit marked with the black dot.

Git version

To do that in Git  is what you would expect:

reset the master to last commit that you need (red),

1: git reset --hard SHA_code

than create and switch to new branch

2,3: git checkout -b name_of_the_branch

and cherry-pick the commit/s.

4: git cherry-pick -x SHA_code

Git SVN version

Reset master to red dot

1: git reset --hard SHA_code

create and switch to new branch

2: git svn branch name_of_the_branch (this create branch on the server)
3: git checkout -b local/name_of_the_branch name_of_the_branch

and cherry-pick the commit/s.

4: git cherry-pick -x SHA_code

and push changes on the server

5: git svn dcommit

to tag this branch on svn type

6: git svn tag tag_name

Note: if you did not checkout the branch in proper way (svn way – step 2) you will tag the master branch