When I read comments from programmers on the internet, one thing that stands out is how much management matters. Good management makes the difference between people staying and people leaving, people being productive or people being smothered. Essentially, it can be the difference between a department that works and one that drags on the company’s bottom line.
Unfortunately, a large portion of managers just don’t get it. They don’t understand the process of programming and have to rely on the information their own programmers feed to them. If you are a programmer, you probably have been there: it’s the 9th hour on a project, and the boss comes in and asks for just one more teensie weensie feature. It sounds so simple! So, you try to explain technical debt, or babies being born in 9 months, or the architecture revisions required, or that you’ll need to test it. And the manager nods, smiles, says it will be “just this one time,” and in a few weeks does the same thing again.
In my life, I’ve had the fortune of having excellent managers. But even so, not everyone I’ve worked for and with always empathized with the programmer. “You estimated 20 hours and it is taking you 40. Explain yourself!” How many times have we all heard that? Programming estimation has become a fine art or perhaps a horrible science to some. Multiply by pi, use planning poker, weekly sprints, or just give in to the religious tribe that is Agile and never talk to those Waterfall heathens again. Some of these approaches work better than others, but there is always the moment when a project feels like it should be going faster and management is wringing their hands.
Having stepped out from my role of a pure programmer to the founder of Upward Pixel, I’ve had to juggle many roles. It’s a one-man shop, but perhaps I’m too proud to call myself a freelancer. In any case, I’m more ambitious. But, the reality is that I’m currently performing all the roles in a business: bookkeeping, marketing, selling, building. I’m my own janitor, and believe me, my employee is messy.
The funny thing is, some of the frustrations I’ve had as a developer with a W2 are the same frustrations I deal with as a manager of myself. I would love to know at the beginning of the project how long it will take, I would love to shove features in left and right, I would love for deadlines to be always met. But, the programmer side of me knows that development is inherently a tough cookie to crack. Fortunately, these two needs – to make the client happy and to take the time needed to write what’s needed – are easily resolved in my own mind and more easily communicated clearly to the client.
But for those out there who have a manager, now that I can see the other side, please cut them some slack. Just as you wish you could truly educate them on why “just use a library” isn’t always the answer, they would love to sit down with you and explain the sales funnel and why we need to stop you in the middle of working to give them some info on a future project. The best management-developer relationships have this mutual understanding, but it’s rare to develop naturally. This understanding and empathizing on both sides of the table usually has to be molded from the hellfire of projects going wrong and the shared attitude to learn from missteps.
As one programmer to another, this is the message I’m trying to share: your manager is not your nemesis. They are not out to get you (unless they are, in which case please find another position). They are trying very hard to balance the needs of the client or other stakeholders with your needs, and sometimes they might not understand why unit testing can save time in the long run. Give them some slack, because you may not have client retention rates in the forefront of your mind all the time, either.
