Sometimes I just like to sit back and code something. Free from deadlines. Free from requirements. Free from issue systems and planning teams. It's so liberating to free ourselves from the shackles of business requirements and simply do something we want. It's important for managers to recognize this to grow healthy and productive teams.
The dreamer versus the engineer
I'm not sure I've ever gotten up in the morning thinking I'd like to prioritize some issues today. I got into programming because I wanted to make the computer do something. I loved how a few lines of text could produce such wonderous effects.
While working on a business project, it's easy to lose sight of the artistry of programming. We're inundated with the reality of code not being the goal, and continually told to stifle the perfectionist. But what if we desire to produce a stunning piece of code? What if we want to try out something new?
Commercial software development is about producing products and cares little about the artistry of the code. It doesn't mean we have to suffocate the dreamer in us. Indeed, that would be a poor thing to do. We need to learn how to separate it from the engineering aspect of our work and understand the difference.
Code golfing
I frequently find myself looking at the code over on Code Golf. This stuff is the antithesis of proper professional coding, yet I find myself saying, "cool". There's certainly an appeal to this ultra-compact code, and many people revel in its production.
Trying one of the challenges is fun. I don't need to win or even come close. Often it's enough to think about a solution in my head.
Perhaps code golfing is not for you. There are several other competitions and other puzzles out there. But maybe you like to find your own challenges instead. Or possibly you saw something on a blog and want to replicate it.
Be wary of jumping into online competitions. The gamification of the systems can quickly lead one away from having fun. Feel free to turn a blind eye to the reputation points and only do what you find interesting.
Managers, make the time
My excursions are not always completely irrelevant. Quite often I want to "fix" something on my current project. Something that is bugging me, but will never get enough priority to justify the change.
It's not always a bad thing to focus on the wrong parts of the project. If as a team lead I see that George desperately wants to add a pet feature or refactor an ugly module, it might be advantageous to let him. George might end up refreshed, with enough energy to tackle the boring issues. We can't let ourselves be so wholly lost in the business valuation of issues as to ignore this human aspect.
If we're working 50+ hours a week on the same project, the time for artistry rapidly diminishes. It's not that we don't like what we're doing, but let's be honest, a lot of necessary things are far from invigorating. Having the time to try new things can be hugely rewarding to individuals, and the project as a whole.
A lot of team members, if given the time to explore, will actually take that time and work on the project. Amina may write the new deployment she always wanted. Luca may clean the cobwebs out of the reporting module. Mia may go off and write about debugging on her blog, giving the company a human side. Sure, Oliver might use the time to build a monitor that counts the remaining beer in the fridge, but hey, it's good for a laugh and makes him happy.
Rejuvenate the dreamer
And that's what it's about in the end, having a team of happy, interested programmers. Our productivity in coding, our ability to write clean code, is directly related to how rewarding we find our position.
I think being given this flexibility at work is one of the signs of having a good job. A manager who understands the need for side projects will have a better team. If you're unlucky and work is nothing but stifling, then you need to find the time on your own. Often the negatives of a position are more related to one's unhappiness than the job itself.
In any case, take the time and do something fun with it. We'll all be happier for it.
Top comments (1)
I think this is a really good article, and it makes an important point about motivation.
It reminds me of a situation I was in on a past project. I was doing some maintenance on an application. Initially, we were given a fair amount of freedom to work on our choice of bugs in the issue tracker. I would usually start with a difficult, high priority, issue to work on.
Once it was done, I was often pretty tired, so then I'd look for a few easy quick hits. Sometimes they wouldn't be particularly high-priority issues, but they took very little time to fix. The feeling of being able to close several bugs in a short time renewed my energy level, and I felt ready to tackle something harder again.
Later on, they changed the policy, and we were told to only work on the top priority issues. Sometimes I couldn't find anything easy in this list, so I had to slog through one difficult issue after another. I strongly suspect that my overall productivity went down as a result.
I understand that when a client is paying, they should be able to direct what is being worked on. Still, I do believe that if you want to get the most out of your developers' efforts, it is wise to give them some leeway.