Hacker News Reader

Comment by puppetmaster3 | Hacker News Reader

As a coder or a CTO, I say you can't do both.

Code 30% of time? You know nothing of coding. Can't be done.

It can and it should. I've worked with CTOs that do this.

You can average it out at 30% of the time, but in a given week, you can't commit to it, because a greater responsibility of your job is being available to manage the unexpected. That makes it difficult to integrate someone in that role into a team in terms of dependency management.

There is also a risk in being in a position of power and being seen to assign yourself the most interesting work. I have seen this happen in one team, our manager was a good guy, but somehow he always used to get the sexy work like playing with new kit, and the team got the gruntwork. It led to resentment and undermined his authority (tho' because he was a good guy, as soon as he became aware he was doing this, he stopped).

> You can average it out at 30% of the time, but in a given week, you can't commit to it, because a greater responsibility of your job is being available to manage the unexpected

I'd argue that your job is to teach others how they can best manage the unexpected. Then you should only be involved in the really exceptional circumstances, allowing you more time to tend to your (metaphorical) garden at work. If writing code is part of that, so be it. But the bulk of time, I'd argue, ought to be in mentoring others.

The best managers I've worked with don't run around like chickens with their heads cut off, constantly responding to fires.

Depends what you mean by "fires". If a customer comes along with a new requirement, how do you predict that? Then your job is figuring out if it can be done, the best way to do it, if you have people free to do it and test it, if doing this for customer A will have any impact on customers B-Z, if there are any currently in-progress features you could or should cut to work on this, whether to push back on the customer and say, not in this release and how to do that without disappointing them too much, etc etc etc.

Basically a manager's role includes being the interface between his team and the outside world, and the outside world is by its very nature chaotic.

Of course. That's why they don't take on critical work that has a hard deadline.

I don't think the average professional programmer gets to code in much more than 30% of working time. Too much time gets spilled looking at documentation, sitting in requirements meetings, etc.

The problem is more that, to get something done while working 30% of the time, the CTO has to cherry-pick the fun projects where things can be accomplished quickly without the time-consuming slogs. That can cause morale problems if the rest of the team is spending a lot of time on slogs. One might argue that that's a sign of a deeper problem, but few companies have figured out how not to generate drudge work when at significant scale.

Looking at documentation, doing specification is coding.

Reply on news.ycombinator.com