2 brains are better than just one

12 11 2008

I haven’t been here for a while. Just was too deep in my work and only today allowed myself to take a look what’s going on in the blogs of my friends and make some comments.

Because today was a really good day. In my current project I have a release on Monday and still in my favorite (but most complicated) module there are few really dirty bugs that makes this module to look not that nice as it might be. I came today to the office somewhere at 3 PM with a strong intention to fix one of the problems and a belief that I can really to this. My current understating of Flex allows me to analyze almost any piece of code written by any developer and make there needed changes in case of trouble. I’m lucky that all guys in my team are quite autonomous and can take almost any task by a simple input (sometimes I use a sticky yellow note, write there a short description and stich to the guy’s table) and start working on it without disturbing my concentration on some more difficult thing. So thank you guys for this, I love you all.

There’s a one good mate in my team, Max, who is my primary force for that module development. I worked out few necessary management thigs and then we sat together with Max at my laptop and 4 hours were analyzing, debugging and fixing a trouble. We won. I realized this day few very important things:

  • there are tasks in software development that are unarguably better to do with a friend, not alone. I would not be able to fix this bug without Max, definitely. And he was not able to fix it without me in few previous tries.
  • sometimes quite simple (at the end when you find it) problem can cost you really a few days of work to fix.
  • even BEST, ingenious developers mistake
  • fixing bugs can be just a good quest, a good game and a lot of fun if you perceive this activity positively
  • diagrams and visualization of complex activity chains helps invaluably when you try to understand a complex mechanism created by other person. We created a set of sequence diagrams for different functional flows of that module and then benefited a really from having this before our eyes. Max really cool in doing this, he showed me that Enterprise Architect can import Flex packages and convert it into workable items in diagrams. Once again I appreciated how good tool EA is.
  • sometimes you need to sacrifice personal life and some fun to get the things done at your work. Today I planned to meet one girl, an old friend of mine, who I have not seen for a while. But at 6 PM I was still in the middle of the task so I just called her and told “Sorry baby, we can’t meet today, I have a work I must to do.” I felt that this was not a thing she wanted to hear but she’s a good friend and tomorrow will be ok.

So: if you see that some person in your team can’t do some thing despite of working hard on this – go and help. If you trying to do something and it doesn’t gets working – go and ask for a help.





Minimalism

2 10 2008

After few monthes on my current project in result of situation and advices of few guys I’ve understood and accepted a kind of “minimalism” mindset.

You don’t need 3 colors (green, yellow and red) to indicate the state of parts of your project scope, really. You need only 2: green and red. When results are needed it always ekther “working” or “non-working”, “sellable” or “non-sellable”, you can go to customer and show it or you can’t.

The same goes for “done”, “not done”, “in progress”. You need only “done” and “not done”.

This is the essence of delivering and result-orientation.