Hacker News new | ask | show | jobs
by vorpalhex 1595 days ago
> The basic thesis is one of dedicated roles, with the manager archetype focusing their time towards enablement, communication, and expectation.

No, it's because programming requires a mental model of the software and most managers don't have that. Add in constant interruptions and the inability to focus and you have a recipe for disaster.

Would you sometimes take a break from programming to go help accounting do the accounting work? No, no you wouldn't - accounting would smack the tar out of you. Just because you think you can contribute because you used to be able to is the notion that you need to break, and this applies to other fields too.

> This starts young with telling kids they can't be good at multiple things. "You need to focus."

A lack of focus on a problem space is usually the problem, yes. This isn't because we want people to stay in their lane and want to keep kids from being creative. It's because difficult problems are hard to solve.

If you are going to spend hours pulling down code and building it, ask yourself this question:

"Is this the best use of my time? Is pulling down source code and waiting for a compiler the best thing I as a manager can be doing?"

3 comments

> No, it's because programming requires a mental model of the software and most managers don't have that. Add in constant interruptions and the inability to focus and you have a recipe for disaster.

This is so strikingly true. I try to explain to people who want me to pause a job and do something else that in my head I have this large, abstract structure of what I am trying to build, that is in an abstraction that itself is ephemeral -- it doesn't map nicely onto black boxes or pipes or anything. It is whatever works at that moment, and it requires me to tour it in my head all the time for it to exist at all.

But to me it isn't a question of focus, strictly speaking, because focus doesn't explain my interaction with that model. It's more a question of relaxed, constant presence; it's about having blur over other stuff. If I can inhabit that model in my brain without having to worry too much, it starts to work itself through while I am doing menial tasks like washing up or laundry or cleaning.

As soon as the business side of my freelance life takes over as it sometimes must, I am suddenly on the outside of that abstraction looking in. And no amount of detailed notes or documentation or diagramming will help me back in quickly.

> I try to explain to people who want me to pause a job and do something else that in my head I have this large, abstract structure of what I am trying to build, that is in an abstraction that itself is ephemeral -- it doesn't map nicely onto black boxes or pipes or anything. It is whatever works at that moment, and it requires me to tour it in my head all the time for it to exist at all.

you can send them this comic directly: https://i.imgur.com/3uyRWGJ.jpg

You can. You can also demonstrate the issue in several other ways.

However, it never works. It may last a week, a day, a few hours, but sooner or later, they're going to believe that you're just staring off into space and that it's fine to interrupt you. That you can pick up and put down your task as easily as you would a pen.

Aha! I had seen this before, and lost it. Thanks :-)
> Would you sometimes take a break from programming to go help accounting do the accounting work? No, no you wouldn't - accounting would smack the tar out of you. Just because you think you can contribute because you used to be able to is the notion that you need to break, and this applies to other fields too.

As a counter-argument to this: With my software side business, I've had to dabble in accounting, and I find it a refreshing break. It's like going outside and pulling some weeds. For me it contributes to my productivity and mental health to have a diverse work experience.

> It's because difficult problems are hard to solve.

Most software development does not involve difficult problems however - other than how to comprehend the stitching together or "complected-libraries-du-jour" via maximal indirection.

I know this is a meme (I guess about frontend web dev sometimes?), but I don't think I've ever seen it play out in real life.

Almost every program source code that I've read or worked on mostly consists of "data processing" and "control flow", with various kinds of abstractions that depend on the problem, programming language, etc.

Even for applications that seem straightforward, writing software well requires quite a bit of mental energy and focus/attention. Especially once you consider future maintainability and interfaces that other devs will use, testing and testability, documentation, readability, et al.

Denigrating programmers for using frameworks and libraries (the horror!) is just pointless and arrogant. Sure, most programmers aren't implementing novel algorithms from scratch with manual memory management. But that doesn't mean other problems can't be hard, it just means that the level of abstraction is higher and the programmer is free to use their mental resources to work and reason differently.

In a land free of constraints all problems are simple.