5 ms·
I disagree here as someone who writes code for a living. In my experience, managers who write code often do so at the expense of something that's a more importa
by tdeck 5y ago
I disagree here as someone who writes code for a living. In my experience, managers who write code often do so at the expense of something that's a more important part of their job that they don't want to be doing.
Many managers are promoted engineers who feel more comfortable with code than people management. So when they don't want to hold 1:1s, don't want to deal with an interpersonal problem on the team, don't feel comfortable escalating an issue to management, etc... they instead pick up tickets and start writing code as a way to kind of procrastinate. This is bad because the organizational structure is such that the manager is often much better equipped to deal with such issues than the dev team, so they can go unaddressed.
- lifeisstillgood 5y agoI agree that a "manager" doing the work of one of their "employees" is clearly wrong. What I am trying (badly) to convey is that we should build software-driven organisations - where the processes and policies, the back-office if you like, is software driven and so if you "the executive" want to chnage the company you do it through explicitly changing the code.
- pjbeam 5y agoThat's a cool idea but I think something important is lost without that human "fudge factor" so to speak. I do a lot of things for my team that maybe aren't explicated in policy or would be very difficult to legislate through code related to morale and fending off burnout. Humans need wiggle room, for lack of a better word. Robots don't make all things better.
- lifeisstillgood 5y agoWe have the same idea in human society - we have very explicit criminal laws abs the jury system to handle the fudge factor. The difference here is openness. What your argument means to me is a need for democracy and openness in companies.
- nine_zeros 5y agoI agree. Managers (especially higher they go) should get out of production code. That said, they should be technically very skilled to be able to make tough calls, people and technical. Companies should have two ladders. IC ladder and management ladder. Where companies fail is that they make the IC ladder less about actual work and more about documents, RFCs and 1-pagers and other nonsense. They start measuring productivity by these docs instead of actually building something, thus setting perverse incentives for a promotion. Docs, RFCs, designs are all means to an end, not an end unto itself.
- heisenbit 5y agoImagine a bad manager spending 30% of the time coding. Now imagine the same manager giving up coding, investing the 30% in making more bad decisions. And don't expect things going better but expect them getting worse due to total lack of grounding in facts and loosing his technical network to back him up.
- tdeck 5y agoThere are many ways to be a bad manager, certainly. One way is to make terrible calls that misdirect the team. Another way is to neglect your responsibilities. If the options are "constantly interfering and screwing things up" or "checking out and writing code" I agree that the latter is preferable, but those aren't the only options. If someone is trying to improve their performance as a manager it needs to start with real assessment of the core functions of the job, and those don't include coding. Too often people tell themselves they need to make time to "stay sharp" with coding when what they really mean is "I don't know how to tell Karl to stop micromanaging Hayden, and I don't know how to get the Widget Access team to stop ignoring our bugs, but I do know how to write a rate-limiter". Then it becomes "oops, this rate limiter is pretty involved, so I didn't have time to talk to the WA team. I guess I'll get to that later".
- lifeisstillgood 5y agoIf the company needs a rate limiter and you don't have the budget to hire someone to create it, then maybe creating it is the sort of go-getting action we want. And if we think the manager should go fight and persuade the organisation it needs a rate limiter then, yes. But they will need to write code to show the slowdown in latency, calculate the cost in servers if we don't have this etc etc. And frankly that sounds more valuable to the bottom line than whether Mary is being micromanaged. There are always always trade offs. "people management" is rarely about inter-personal issues arising to the level of HR like action. It is for more often enforcing standards on the job. Oh like linting. Less and less human stuff cannot be improved with coding and almost always the solution built in is insufficient, and customising it at enterprise level slow and costly. I agree don't do the job you left behind, but that's is not the same as stop coding. The software literate company will need most software not less.
- Graffur 5y agoIt seems like you're assuming a lot of what those managers want or don't want. Or is there some data behind this?
- tdeck 5y agoI don't need "data" to show that when someone does X which isn't part of their job in preference to fixing longstanding problem Y which they're directly responsible for, they must prefer working on X to Y. We all have blind spots and areas where we prefer to focus that might not align with what's most important. This is something you can see at every level and my comment is based on experiences in my own career.
- lifeisstillgood 5y agoSo, there are roughly four executive functions - model - monitor - mentor - resource allocation Using Software to "run" the company will encourage openness, reusability, and robust discussion. This may not be what executives want. And yes Linus Torvalds will inevitably come up here. And I think he is an excellent model (excluding the stuff he resigned / apologised for). He does / did not write code that goes in the kernel, but will write things that solve his executive needs (everything from mailing him when his local build has finished to, you know, git). These things will mostly be open, and beneficial to the "organisation". No his job is not to write kernel code. But that's not to say he writes no code, nor is that code not useful in building the whole organisation around the "factory floor" job. Anyway, the model / Monitor / Mentor thing - yes of course software will help building such things. And yes of course there is proprietary code out there (SAP etc) to kinda sorta do that but mostly it all devolves to executives downloading everything to excel and writing their adhoc queries in excel to answer the problems they face today. There is zero point hoping SAP will write a custom what if filter for Company X's problems with holding US Sales in Dollars or Yen. And there is a big upside in thinking if they were coders, and did write that query and made it open inside the company it would be reviewed, challenged and improved. And maybe even open up debate in the company but that's politics ...