Ultimate Pomodoro?

What is the major problem of using the Pomodoro Technique? I think it's a sharing one. You see, when you're "in the middle of a pomodoro", no one really cares - your team mates will go on interrupting you anyway!

So, you need to synchronize it somehow. Setting a single timer per team is a bad idea, for the obvious reasons. What I suggest to do is to invent some kind of a Pomodoro Server and track your current status there (team-wise or project-wise). Of course, the policy should be invented for all team members to check this status before interrupting another person.

Sample feature list:

• Notification when required person's pomodoro has finished
• Integration with your corporate favourite IM client as a plugin
• Integration with popular issue tracking systems via plugins
• Speach recognition to simplify items entry
• Flexible hotkeys for all frequent actions to make things even easier
• Statistics gathering to analyze and boost personal productivity

Hope to find some time to figure it out in a further detail... Frankly speaking, already tried some of the most popular open source voice recognition tools. It seems that either my microphone, or my English, or these tools, or its' settings, or alltogether are too bad to recognize anything but "one [pause] two". With 25% accuracy. Sigh...

About coding

I want to separate two different kinds of coding.

First is handwriting code from scratch, which is a good old not-reusable-bad-to-support approach. It gives me a great pleasure, because I know what to expect and when I solve a Task, it's clear what I've done to complete it. I mean, it's all so clear and predictable, that nothing can spoil your pleasure of getting things done. I used to code this way somewhere about seven years ago writting C++ utils in MS Visual Studio 7.

Nowadays, things are different. I'm developing Important Enterprise Java Applications, and the coding development sequence looks like this:

1. Find an appropriate Library or Framework.
2. Choose the one which either the trendiest one (in this case all your further actions will be more painful), or the wider used one (of course, in this case everyone will think that you're starting to lose your grip on modern hi-tech).
3. Try it on some sample application (though, this stage will not give you any useful information at all).
4. Try to plug it to your existing application, consisting of Frameworks, Libraries and running on Servers. Configure it (that's where you start hating both XML and lazy developers who suddenly appear not being able to write any meaningful documentation at all). That's where the vast majority of time gets spent.
5. Fix all bugs and side effects brought by that all-new yet-another Framework. You won't be able to spot all of them fast enough of course, so this stage virtually never ends.

So, in this world the pleasure of getting things done is usually comes at step 4, when you finally manage to squeeze your brand new part into the puzzle. But that's not it - it has nothing in common with the first Predictable Big Pleasure, and this makes a huge problem for me. Somehow, programming (which is such an interesting and exciting thing in fact!) doesn't make me happy anymore - it became just a job.

And exactly that's why I'm really looking forward to start coding in Ruby, to see if it's that good, as they say.