I am a team leader of a small team of programmers, we are specialists inside a large central team of specialists.
One of the things I struggle with the most in the adjustment to being a lead programmer is dealing with the guilt of not programming when doing lead tasks like planning, design documents and meetings. I think this guilt has been brought about from years of working as a programmer where you are assessed primarily on the quality of your programming output. One day you find yourself groomed for a lead position and then finally working day to day as a team leader where your programming output, while still highly valued, is now just a part of your overall responsibilities and worth.
I find myself setting out to do some planning, designing or performance reviews and then, when I log into my workstation that morning, I suddenly find my code editor open and the compiler/linker chugging away happily. In fact I even find myself on those (mercifully rare) days of endless meetings snatching a quick programming fix during my lunch break: prototyping some idea or tweaking something. Programming because I can.
Perhaps it is my loathing of Microsoft Word: the program that will not leave my text where I want it, that thinks that it knows best about layout, and with it’s undo button that never actually seems to completely undo whatever auto formatting abomination just took place. Or maybe the overly complex document templates that seem to have many duplicate or redundant sections are the deterrent? The lack of examples of good documents is also worrisome as it is hard to know what exactly is wanted: the specification is never as detailed as a program feature. Or perhaps all of the above?
I exaggerate slightly, mostly to amuse myself.
I am still mainly a programmer, yet doing those not-programming tasks does seem hard, part of me resists this non-programming even if it is only something I have to do some of the time. I think I will have to start planning them out as tasks as I would a programming task in sprints, perhaps even to go as far as breaking these non programming tasks down further into sub-tasks. Hunting down good examples of plans and design documents to give me an idea of what good looks like will also help.
How did you overcome your guilt/resistance to non-programming tasks?
One Comment
As I tell all my programmers, planning, designing, and communicating (which includes performance reviews) are all considered productive work. Realizing this, I think, comes with experience. As you get more and more successful projects that you have adequately planned, under your belt, you realize and value how important the design and planning work is. (Conversely, the same can be achieved when you have a number of projects fail due to lack of design and planning.) Having good tools and templates to do this work helps, but rarely are these one-size-fits-all.
Post a Comment