Do You Really Need To Be 8 Hours In The Office?

20 10 2009

This Dilbert strip

unproductive time

unproductive time

made me think for a little on questions like

  • what is productive and unproductive time?
  • how long should you work everyday?
  • should you keep to the rules like working day start/end hours?
  • are you an example for others?
  • should you screw your subordinates up if they are not being at their desks precisely from X am till Y am?

I have a very short answer for such questions: IT DOESN’T MATTER WHEN YOU COME TO THE OFFICE AND WHEN YOU GO HOME. UNTIL YOU PERFORM EQUALLY/BETTER THAN OTHERS NO ONE CAN POINT THIS TO YOU. IF SOMEONE DOES – TELL HIM “FUCK YOU” :)

We are not living to work, we are working to learn and have fun, to create. Let people working in fastfoods/banks/receptions/etc. be a slaves which should spend 8 hours every day believing this is very beneficially for the society. Good people should try to manage their life to spend as less time on routines as possible and to leave as much time for learning new things as they can.





Java Time

4 09 2009

LOL:

Please note that the all the deprecated methods and constructors of the Date class should never be used. They are from a time when the Sun people were confused about time themselves.

Source: http://www.odi.ch/prog/design/datetime.php





Neverending game

6 06 2008

It’s a midnight here and I’m trying to finish the delivery documentation since was not able to do that at office this evening. As usual this non-trivial task gives me a lot of inspiration and a lot of little lessons learned. In this process I need to check everything that I’m trying to describe. And almost always this happens to be the only moment when I can actually check anything by myself. When the iteration is in progress I don’t have time to look at the intermediate results, there are always some hot tasks to perform so I should trust my guys.

But each time I find out some little things that can put onto the face of the very good functional delivery a mask of incompleteness, so the customer will have a feeling that something could be better. After analysis of a lot of such cases I can draw certain conclusions on the nature of this thing and try to choose a strategy on how to improve it.

The first reaction when you see some little inconsistencies in UI or inconsistencies between two similar tasks implemented by different people is likely to be “WTF, how could they left such things not aligned !!!”. But thinking in the context of a Team I understand that everyone is in charge and everyone shares a part of the possible blame. Today I had a chance to see once more that Murphy’s laws are working very well. What is not described in the task definition and could be implemented and perceived by different people in different way WILL definitely be done differently.

That is why there is sometimes a temptation to analyze and describe everything ideally, provide the full complete specification. And the thing is that we should not do this. Ideal is not optimal in case of software development. Complete analysis and specification are very costly and hardly to be worthy in not-quality-critical systems. The optimal analysis is the one when a developer gets enough info to implement the thing without interrupting you too much. Here you need to count on the intuition of your team. The more intuition, experience and just a common sense a person has the less ideal should be your specification.

What can be done to increase that intuition level? How is it correlated not with that person but with me? Very simple: I must talk after each delivery and point out each time even those little things. Not blame, but point out. This can’t be done off course by spending just 8 hours of your time at work, to improve other people you should sacrifice your time but maybe this is one of the main things that improves me myself.

It’s very important to have at work a person who can always review your work and provide some advices, show you your mistakes or weak areas. Unfortunately, being a project manager leaves a very little space for such things especially in the projects where feedback loop from the customer is not strong enough. I guess all PMs must find a way of learning things without a teacher. And after all, who told that a teacher is needed when you want to learn :)