Lately I have been struggling to find time to code. As a lead on a team the size of ours my day is usually peppered with meetings, CI server shenanigans, process questions about blocked story cards and occasionally a really fun bug. Every one of those things is enjoyable in it's own right and help the team move forward but I definitely enjoy the times when I can get my fingers on the keyboard.
When I am given the opportunity to dedicate some time to coding outside of the job I like to make the most of it. Whether it's the local user group meetings or the weekly lunch time code club, I genuinely look forward to sitting down for a bit and doing nothing else. There is no substitute, as they say. And these days it doesn't really even matter all that much to me what language I am writing.
At many of these events, however, I have found myself disheartened by the number of people who are unwilling to take the keyboard. Actually, that's not the whole truth. I find myself disheartened by the number of people who will tell you at length how they would approach the problem, but don't seem to be doing much, if any, coding.
I started to write a bit here on why I think this occurs, but in all honesty, I don't really care all that much and I am probably wrong anyway. What I will say is that about six months ago I was at a Global Day of Code Retreat event here in Columbus, Ohio. During that day one of the constraints put on me was to pair with another developer silently for roughly an hour. And during that time my pair partner and I turned out some really decent, very expressive code.
Afterward we both agreed that the silence limitation turned out to be quite eye opening. We confused the hell out of each other a few times and rewrote each other's stuff more than a few times but once the debate in code was over and the dust settled, we had gotten further on the solution than with any of my other pair partners all day. Even if we hadn't though I would still say being forced to express my ideas solely in code was refreshing. As it turns out developers can have a perfectly fine discourse right in the editor and arrive at a very good end result. Furthermore, we don't have to live with a busted idea for more than the time it takes to revert or refactor.
So I say fight the habit to socialize every idea before you lay it down in code. Resist the human urge to gain acceptance ahead of time and get your ideas written and compiled as fast as you can. Code it. If it stinks, recode it, or throw it away. That's what git reset --hard is for right!? Go forth and be awesome...or be wrong. Who cares which? Just be coding.
Tuesday, June 4, 2013
Thursday, May 30, 2013
Standing Up for Stand Up
Earlier this week a disagreement occurred amongst some technical team leaders regarding how stand up meetings should be held. One camp felt the meetings were becoming a bit cluttered. The team is a remote team and several interested parties from the home location like to participate in the daily stand up via Google Hangout. One of a few complaints is that the cross site communication makes the stand up kludgy. There are regular interruptions to repeat things, for instance, since the microphone is directional, etc, etc. Other annoyances were also noted.
The other camp insists that the good that comes from the cross site participation far outweighs any headache it causes. The home location values maintaining a strong relationship with the remote team and accepts the soft costs of doing so. As is usually the case, both camps are correct and are now entangled in a very fine grained philosophical disagreement.
But none of that is as important as the fact that it caused me to gut check my own reasoning and make sure that I was staying true to the principles that guide me as a leader. You see, I believe that a human being's best work is the result of a harmony amongst the many forces acting on that person's life. I think this because I latched on to the teachings of Lao-tse very early in my own life and value them even more today than I did 25 years ago.
One does not need to know very much about Lao-tse or the Tao Te Ching to know that he believed a perfect harmony between heaven and earth existed naturally and could be found by anyone. The idea he put forth is that the more a person interferes with the natural order of things the more that person will struggle against, and retreat from, harmony. I am convinced that this concept is important to the technical work we do and the way in which we lead our technical teams. There are examples of similar or identical thoughts all over the software world about "signal to noise ratio" or "context switching" and slightly more etherial things like "flow state".
So bringing the point back to the decisions that impact development teams, I stand firm on the opinion that genuine annoyances are to be removed. Knowing the human beings that choose to team with you is the job of a leader. Working towards harmony through techniques and tools and improved (or removed) process is a leader's responsibility. Above all else, the people who you ask to follow you deserve an opportunity to be happy and do the best work they are capable of doing. In doing so they may experience their true nature without the arbitrary and false interferences business would otherwise impose.
These are lofty goals. It is likely that, as a leader, I will fall short of these goals on many occasions. The desire and effort to achieve these things will give me an opportunity to expose my true nature, however. And for that reason, I have no choice in the matter.
Completing our round trip then, what should be done with the stand up meetings? Give the remote team what they want so they can go be productive without being annoyed. The need to coordinate between sites is an artificial constraint that the leadership has imposed on the project. It is the job of those same leaders to find ways to satisfy the tangential needs of the project and not impede the harmony that naturally exists between a developer, a keyboard, and problem in need of solving.
That's the way Lao-tse saw it then and that's the way I see it now.
The other camp insists that the good that comes from the cross site participation far outweighs any headache it causes. The home location values maintaining a strong relationship with the remote team and accepts the soft costs of doing so. As is usually the case, both camps are correct and are now entangled in a very fine grained philosophical disagreement.
But none of that is as important as the fact that it caused me to gut check my own reasoning and make sure that I was staying true to the principles that guide me as a leader. You see, I believe that a human being's best work is the result of a harmony amongst the many forces acting on that person's life. I think this because I latched on to the teachings of Lao-tse very early in my own life and value them even more today than I did 25 years ago.
One does not need to know very much about Lao-tse or the Tao Te Ching to know that he believed a perfect harmony between heaven and earth existed naturally and could be found by anyone. The idea he put forth is that the more a person interferes with the natural order of things the more that person will struggle against, and retreat from, harmony. I am convinced that this concept is important to the technical work we do and the way in which we lead our technical teams. There are examples of similar or identical thoughts all over the software world about "signal to noise ratio" or "context switching" and slightly more etherial things like "flow state".
So bringing the point back to the decisions that impact development teams, I stand firm on the opinion that genuine annoyances are to be removed. Knowing the human beings that choose to team with you is the job of a leader. Working towards harmony through techniques and tools and improved (or removed) process is a leader's responsibility. Above all else, the people who you ask to follow you deserve an opportunity to be happy and do the best work they are capable of doing. In doing so they may experience their true nature without the arbitrary and false interferences business would otherwise impose.
These are lofty goals. It is likely that, as a leader, I will fall short of these goals on many occasions. The desire and effort to achieve these things will give me an opportunity to expose my true nature, however. And for that reason, I have no choice in the matter.
Completing our round trip then, what should be done with the stand up meetings? Give the remote team what they want so they can go be productive without being annoyed. The need to coordinate between sites is an artificial constraint that the leadership has imposed on the project. It is the job of those same leaders to find ways to satisfy the tangential needs of the project and not impede the harmony that naturally exists between a developer, a keyboard, and problem in need of solving.
That's the way Lao-tse saw it then and that's the way I see it now.
Subscribe to:
Posts (Atom)