Archive for the ‘Idjums’ Category

Seeing the Forest for the Trees, or, Seeing the Trees for the Forest

When I was younger, I used to paint quite a bit.  There were many times when I would be gritting my teeth, feeling the tension in my neck, frustrated at being unable to get something just right or not being able to see what I was missing.  I would have to walk away for a couple of hours, days, weeks, or months (in the case of the one behind my bed, years).  When I would come back and look at it with a fresh mind, it was so easy to see what was wrong.  Bad proportions, not enough shadow, need for detail in more areas, whatever.  But I would pretty much always be able to see it the instant I set eyes on it when I came back to it.

This system that we’ve been building since June is in a very intense phase of testing, and there have been times when I spent a full day beating it up.  I wouldn’t be able to see anything new at all, but would know the system was not bug-free.  Intensely frustrated, I refused to give up because of the time limit imposed.

This was the wrong decision.

By taking just a few minutes and walking away, I was able to come back a little more clear-headed and calm and get a fresh eye on things.  It can be the same way when you are writing user stories; you think about something for so long that you feel like you have everything, then when you go to put it on the board you see that a piece of acceptance criteria is blatantly missing.  Or when you’re developing something and you miss something really obvious because you’re so mired in the details.

This could be a post promoting pomodoro, it could be promoting an iterative process, I don’t really know what it is.  I guess what I’m saying is that sometimes you need to make sure that when you’re creating something, it’s good to step away and come back with a fresh eye. 

Take 5 and get a little brain massage and come back to it; “wasting” five minutes to  recharge/reset your brain is better than thrashing for an hour and ending up completely frustrated and with holes in your project.

“More Haste, Less Speed.”

Definition: The faster you try to do something, the more likely you are to make mistakes that make you take longer than it would had you planned it.

Our team recently completed two rather large projects with fairly short deadlines.*  Having overseen both projects beginning to end, it was easy to see the patterns of burnout and people feeling rushed.  Throughout the life of both projects, the questions, issues, and general quality of the product was fairly consistent.  Riiight up until the end.

In the last month and a half or so of each project, the quality of what was being produced really dropped and the number of bugs skyrocketed.*  Every story that I’d test would get kicked back multiple times, a lot of them getting kicked back immediately because the program would blow up as soon as I tried to test the feature.

Feeling a lot of pressure as a deadline approaches is natural.  Burning out after 6 straight months of 15-hour days and no vacation is natural.  It’s easy to just say “work at a sustainable pace,” but it’s hard when you are right down to the line and things keep coming.  The main thing is to try to recognize when you are feeling like that and when your code is unhealthy and attempt to mitigate it.  If everything you are writing is getting kicked back, try to find a solution to get your mind back into a productive state.  If you don’t, the end will be much more frustrating, as you will have to continually rewrite code and work on the same stories and rush to try to patch things to meet your deadline.

What can you do to get your mind back into a productive state?  Smoke a cigarette?  Go to Starbucks?  Sit in your car with some death metal blaring?  Change your socks?  Try to find something that works for you (everyone is different).  I’d love to hear some ideas/solutions in the comments.

 

*note: we are closing out the second one, it’s not actually done yet.  But you get the idea.

*note: the quality of the last half of the second project was markedly better than that of the first one, so kudos on team improvement!