Skip to English translation

Δοκίμασα χθες την τεχνική pomodoro για να κάνω λίγη δουλειά στο ResxTranslator. Την τεχνική την πληροφορήθηκα από αυτό το άρθρο. Η λέξη pomodoro είναι Ιταλική και σημαίνει ντομάτα. Η τεχνική pomodoro λέει ότι δουλεύεις για 25 λεπτά σε ένα task και αυτό το task το λες pomodoro. Μόλις ολοκληρώσεις ένα pomodoro κάνεις 5 λεπτά διάλειμα. Κάθε 4 pomodoro κάνεις ένα μεγαλύτερο διάλειμμα, π.χ. 10 λεπτά.

Στο Mac χρησιμοποιήσα ένα δωρεάν πρόγραμμα ονόματι Pomodoro για τη χρονομέτρηση. Δουλεύει αρκετά καλά και έχει πλάκα γιατί χρησιμοποιεί το σύστημα του Mac για σύνθεση φωνής.

Νομίζω ότι από τη στιγμή που ξεκινάς να δουλεύεις με μια τέτοια τεχνική, βάζεις από μόνος σου το μυαλό σου σε μια λογική ότι «τώρα θα δουλέψω χωρίς να κάνω τίποτα άλλο π.χ. e-mail, twitter, κλπ». 25 λεπτά χωρίς διακοπές και ενοχλήσεις.

Όμως και τα πέντε λεπτά διάλειμμα είναι σημαντικά, ιδίως αν ξεχνάς να τα κάνεις μόνος σου. Πολλές φορές τυχαίνει να δουλεύω σε κάτι χάνοντας την αίσθηση του χρόνου. Είναι καλό να σηκώνεσαι από την καρέκλα λίγο, να ξεκουράζεις τα μάτια σου, να τεντώνεσαι, κλπ. Επίσης ένα μικρό διάλειμμα σε βοηθάει να ξαναοργανώσεις τις σκέψεις σου.

Ακόμα η τεχνική αυτή βοηθάει στο να καταγράφεις τι έκανες και πόση ώρα ξόδεψες για αυτό. Το μόνο που χρειάζεται είναι όταν τελειώνεις ένα pomodoro να γράφεις τι έκανες. Στο τέλος έχεις μια πλήρη λίστα του τι έκανες εκείνη τη μέρα. Και είναι πιο εύκολο να θυμηθείς τι έκανες για 25 λεπτά παρά για μια μέρα.

English translation:

Yesterday I tried out the pomodoro technique in order to do a little work on ResxTranslator. I first heard of this technique by this article. The word pomodoro is Italian and it means tomato. The pomodoro technique says that you work for 25 minutes on a task and that task is called a pomodoro. Once you finish a pomodoro, you take a 5 minute break. Every 4 pomodoros you take a longer break, for example 10 minutes.

I used the free application Pomodoro on the Mac to help me with timing. It works pretty well and it's kind of fun because it uses Mac's Text to Speech feature.

I think that once you start working with a technique like this, you bring by yourself your mind in a state that says "now I will work with no distractions, no e-mail, no twitter, etc". 25 minutes with no interruptions and no distractions.

The five minute break is also important, especially if you forget to take breaks by yourself. A lot of times I happen to work on something losing the sense of time. It's good to get off the chair for a while, rest your eyes, stretch a bit, etc. Also a small break helps you reorganize your thoughts and ideas.

Furthermore, this technique helps you to keep a log of what you did and how much time you spent doing it. All you need to do is write down what you did for that pomodoro once it's done. At the end you will have a full list of what you did on a day. And it's much easier to remember what you did in 25 minutes than what you did in a day.

The following list presents a few ways to screw up a project. Please use it only to save your project and not otherwise. Using this list for intentionally screwing up a project is forbidden.

Don't write documentation. Why spend time writing down stuff that nobody reads anyway? Instead use face to face conversations where everyone leaves happy with their own conclusions. Make sure that you don't include in these conversations other people that might benefit from them. The best thing to do is keep them out of the loop and let them continue with their work. Don't communicate the results of these conversations with e-mail or any other tangible means; this can lead to proof and proof can lead to documentation. If you do send an e-mail, follow the same rule and don't send it to anyone who might actually gain knowledge from it or provide additional or different information. Every bit of knowledge must be kept in a "he said she said" level, so that nobody can be held responsible about anything.

Don't respect the coding guidelines. Code is poetry, poetry is art and art should be free. Don't listen to the lead developer who insists on maintaining a coding style. Live for today and forget about tomorrow. All these warnings that ReSharper (or anyother tool) display are for informational purposes only. If the compiler can read it, then the other developers can read it too. Extra bonus if you type in documentation in broken English that only you can understand.

Don't write unit tests. You know that it works. You tested it from the GUI. Once. Well, sort of. Anyway, it doesn't matter. If the other developers find out that it doesn't work, they probably are the ones who broke it. Claim that "it worked on my machine" and "I don't know what happened". It's a slim chance that they will be able to present evidence that they didn't break. If the others feel unit tests are important, they can write them themselves. You've got better things to do, like, write the actual code. You're saving the project while the others are slacking off writing unit tests. They should give you a medal!

Don't communicate with the others. If you do something that will affect others, don't tell them. If they are smart they will figure it out themselves. Why distract them anyway? They're busy. And it's a minor change anyway, right?

Don't ask for help. This is a special case of the previous one. If you are not sure about something, don't ask for help. Instead, assume how it should work and just write some code. Ideally, sneak-in the code and don't have it reviewed by another team member. This ensures that other people will consider it a fact. Think of all the endless meetings you just saved your team.

Bonus for international teams: Don't speak English (or whatever language that the entire team happens to speak). Effective communication is only done by speaking in your native language. If you are the most knowledgeable person in the team, this ensures that your job safety is guaranteed, at least until your company goes bankrupt, for some other unrelated reason of course. If on the other hand you're the person who knows the least, you can continue to work happily while the others discuss in their own language about how the feature you've been working on for the past week should be dropped altogether.

If the developers in your team are doing one or more of the above, your project will probably fail in some way. If the developers in your team are doing all of the above, you can rest asured that your project will fail so bad that people will actually discuss about it in the years to come and even refer to it as "that failed project".

Final tip for managers: If you are a manager in such a project, don't make the mistake of firing the person or persons who have repeatedly practiced the above examples, especially if you're the one who hired him. That will make you look bad for hiring an incompetent developer in the first place. Instead, let the mess continue, with the sane developers sinking further more in despair. This way, all the developers will look bad, but you won't, ensuring that your bonus is not harmed in any way.