Very well said. A friend of mine worked at a winery and he was very enthusiastic about his work -- he loved making the best wine he possibly could.

He recently bought his own winery and, to his (and my) surprise, maybe 5% of his job involves interacting with the winemaking process. The vast majority of his job concerns compliance with regulation, bookkeeping, and communicating with vendors/suppliers.

I think it's good to have a holistic view of an industry before you dive into it. There are a ton of "housekeeping" things to be done in every industry, but in a sufficiently large company, you're often shielded from the things that aren't your direct concern.

I'm surprised that both of you were surprised that most of his job comprises of logistics. That's kind of how things tend to work.

from outside, when not dealing with the logistics, you do not have an understanding of just how many logistics there are. This is why developers think managers don't do anything.

> This is why developers think managers don't do anything.

A programming dev manager told me years ago that his mornings were spent dropping by each member of the team. He'd ask how they were doing, and what they were working on.

He'd then gently nudge them back onto what they were supposed to be working on.

Because they were always working on the wrong thing, or because he had just interrupted them with chitchat?

Usually this sort of thing occurs when management perceive fixing technical debt as a distraction instead of an investment.

That's the cynical take - not that it doesn't happen, but there's a lot of reasons why a manager might have better context for what is important to work on at any given moment that are genuinely useful. For example: business priorities (not just "tech debt" vs "tick feature boxes", but "which of these 8 aspects of this feature should we build first", etc.), more experience in what aspects of a problem are worth spending time on, being more connected to what others are doing around the business in different departments, having more time talking to customers to know what their real pain points are, etc. etc.

In fact, as a manager in my current team I probably spend more time nudging people to fix technical debt they've forgotten about because they're excited to work on the next feature than vice versa. In other teams I've spent more time cautioning away from writing functionality that isn't needed right now to avoid overengineering the solution.

How you communicate that guidance and extra context has to depend on the team, what works for one won't necessarily work for another. What you found to be terrible another developer might love - as a developer who now has some management responsibilities I had to learn that some people actually want a lot more management than I would have ever wanted - my "micromanagement" is their "I am supported and know what's going on".

Anyway I'm not saying there aren't bad managers out there (or that I'm a good one), but it's a lot more nuanced than you imply, and what you might hate in a manager others might actively seek out.

It’s bad management to drop by people’s desk every day to check in with them, then “nudge” them. I’d say that’s a failure of product vision, strategy, communication and leadership.

> my "micromanagement" is their "I am supported and know what's going on".

What you’re really seeing here is people grasping at any life preserver they can grab in an incredibly poorly run organization. In a well run organization management is extremely hands off, because the machine runs smoothly and scales.

If you've worked on both sides of engineering and management, you'll discover it's a lot more nuanced than that. Many engineers don't need managing. Many more do. Many need micromanaging.

I’ve worked both and micromanaging is never good. For one, it doesn’t scale. It’s also indicative of poor process, communication and documentation.

> It’s also indicative of poor process, communication and documentation.

I recall one engineer in a team of 20 or so that, whenever he ran into a problem, he'd stop, fold his hands, and sit back in his chair. And wait until the manager noticed this, would come by, ask what the problem was, fix it for him, and he'd then proceed.

You could say this was all the manager's fault, but the rest of the team did not behave this way.

Another time, I recall one who needed micromanaging. Eventually it turned out he was on drugs.

> whenever he ran into a problem, he'd stop, fold his hands, and sit back in his chair. And wait until the manager noticed this, would come by, ask what the problem was, fix it for him, and he'd then proceed.

Certainly there are better ways to communicate than looking to see if someone is sitting back in their chair. Either they are delivering or they are not. If not, a good manager will ask what the problem is, then fix it. Not delivering should be a temporary state, if it’s not, that employee may not be a good fit for the org.

I mean I would totally agree with this but sometimes you end up in a situation with someone like the described engineer; obviously you should get rid of them - but getting rid of people quickly and efficiently is not possible in every organization and country therefore managers sometimes need to manage someone that should be gotten rid of because it is not the propitious time to get rid of them.

Yeah, because it's NEVER the programmer's fault, they're always perfect :-)

Of course not, but micromanagement is never the answer. I will say there are a lot more decent programmers out there than there are managers. Many programmers are motivated by curiosity, 90% of managers are motivated by ego. Wfh is going to decimate the latter as egoless orgs become the norm.

perhaps the devs on his team were the kind apt to go down interesting rabbit holes.

Because they were always drifting off onto something more fun.

That's because a huge chunk of them really don't do anything -- but let's not hijack the thread back to programming.

Logistics are an important part of many areas indeed. Programming though? Depends. I've been in companies where DevOps / sysadmins were 5x more than the programmers and they still were struggling, and I've been in companies where 1-2 guys standardized a deployment process over the course of a week and then didn't touch it for years.

> This is why developers think managers don't do anything.

I've started doing more managerial things at work, and it's given me a lot more appreciation for what managers do. Not sure I want management to be the majority of my job long term, but doing a "tour of duty" has been quite eye opening.

> from outside, when not dealing with the logistics, you do not have an understanding of just how many logistics there are

For any particular situation, sure. But I think it's a very safe assumption that most your effort will be put into logistics or other admin-like tasks rather than the thing you think you'll be doing.

This seems to be a very common occurrence, so I was surprised the GP and their friend did not realize what they were in for.

Developers are inside. We see managers. Some of them in some companies are useful. Others in other companies don't.

As a developer I don't think I get to see most of what a manager does, other than they are in meetings all day long that I don't attend. So I am not inside the logistics of what they do. But I guess you attend all the meetings your managers do and you know everything they do?

That seems to be a surprisingly inefficient company structure.

I think the most common mistake is the assumption that the coordination by the manager is essential to supply direction and avoid errors and mistakes. This is consistently assumed without actually measuring the amount and severity of mistakes without management direction.

I know I can trust my people to coordinate themselves with very low error rates as long as I provide them with the information and incentives they need to make the correct decisions by themselves.

The total cost of extra full time managers is significantly larger than the measured error cost.

Some of the common management tasks will be loaded onto leaf node staff. This costs less, mostly since they aggressively minimise those tasks to the bare minimum friction while a full time manager tend not to.

It is not 1950. We can trust our people to function much better given the right environment and tools. I've run several large complex international projects with very low management overhead.

>I think the most common mistake is the assumption that the coordination by the manager is essential to supply direction and avoid errors and mistakes.

I mean there are different levels of managers, there is your direct manager who probably just needs to delegate some tasks and trust you to manage yourself, and then manage their local budget, but there are managers also of a division with multiple groups in there and they have to manage stuff about budgets that takes into account legal requirements that people lower than them really aren't aware of.

anecdote time about this managerial level (I've told this anecdote before here) - one time I was consulting at a place and they had these Friday breakfasts for about 7-9 teams together (so about 100+ people in a big warehouse eating danish breakfast) and the division managers would sometimes say some things about what was going to happen in the next few months. So, one time the main guys for all the teams gave this speech about why they were doing something in a particular way and it went very deep detail about accounting rules and a particular financing law that applied so that was why they were structuring the next 9 months work in the way they were because it allowed them use a half a million dollars etc. etc.

Everyone was nodding sagely along as if they understood what they were hearing, but I knew a lot of them didn't understand anything, I didn't understand it all either - I just knew I was hearing the managerial equivalent of nerd speak - like the way I would talk about engineering tradeoffs.

A lot of the developers there spent their time going around talking about how these two guys did nothing and were useless, because from the 'outside' of their work it would look like they just sat around talking.

Maybe they are not as useful as other workers, but I do know that I am not able to adequately judge it from what little details I observe about their daily routines.

It's mostly miss-aligned incentive structures and internal politics. Managers are trying to climb up the ladder, increase influence, get more reports and at the same time keep competing interests from doing the above.

I think it feels slightly different when you're doing it, because internal politics is mostly stuff like "team C has created a new service to do something you'll be doing" and you're trying to work out whether it exists yet, whether it solves your problems, whether it's super buggy, what the roadmap looks like, etc.

If you pick wrong you could end up integrating with something that is vapourware or causes issues, yet if you refuse to pick what is offered it can be treated by the other manager/team as a huge insult and then a narrative can be crafted and verbalised to upper management that it was a non-strategic play on your behalf and wasteful of company resources, etc.

Working within this context with other managers and teams, means constantly needing to understand what they're trying to achieve and offering a helping hand, while protecting yourself from bad decisions that would negatively affect your own team. Even if you aren't trying to climb the ladder yourself, you have to avoid actions that harm your team.

This might be inefficient, but once others are playing this game, you have to be really aware about what is going on, and ensure that you're always playing the right hand.

perfect illustration https://ncase.me/trust/ of the dynamics

Where did you find this? That’s amazing

You don't need to be on every single meeting to get general idea about which manager is adding value and which is not.

I don't need to be expert in management to see that corporate management where managers almost outnumbered team members, changed every few months and attempted to manage without ever learning what product does was bad.

It's probably the ratio that's most surprising. Sure, most people probably know there'll be bookkeeping and other tasks, just not the degree. I wouldn't be surprised if most people imagine something like 50/50 at worst.

Some might also be surprised by how distinct the logistics/admin work is. For instance, they may think that since it's bookkeeping for a winery it's still work related to something they love, thus enjoyable. Then, they realize bookkeeping is bookkeeping, which further emphasizes how much time they're spending on not the thing they love (logistics/admin).

Joel Spolsky article about exactly this, but for programming: https://www.joelonsoftware.com/2006/04/11/the-development-ab...

I have turned two of my hobbies into businesses that are now full-time work for myself and part time work for two others (my wife and an employee we hired a couple of months back).

For me, the fact that you have to sell/market something isn't what makes it a stressful; I enjoy that aspect of it too.

Instead, I find most of the stress coming from the high stakes (if I make mistakes or work slowly, my business will fail and my children will grow up without a present father) and need to hyper-optimise (every single action is about maximising the amount of dollars earned per hour spent working).

I've found immense peace in the last few months in cleaning, of all things. It's not a traditional hobby, but the fact that I can make mistakes (or just not do it at all if I'm tired) with minimal consequences makes it so much less stressful than my businesses which do revolve around "traditional" hobbies.

My grandma used to say that happy people don't clean. People clean, and then they are happy.

I think it is a form of craftmanship like any other.

This was the breakthrough my wife had when we were discussing this: there was no way she could do that for a living. She likes experimenting, and that's not part of a chef, except for some very high rated people.

I am one of the lucky people that love its profession (software development) and it is also my hobby. I'm not sure how to identify the non-coding parts, I enjoy those in the profession too, but more because I like to do very well and being good at those other parts is an integral part of it. To be fair, making a team more effective goes also to my benefit, where I can do more interesting work.

I spent six years working as a lawyer and absolutely despised it. Early on during this hell I rediscovered a curiosity in programming I had as a child. I became obsessed with it and within about six months knew I had to try to do it as a career.

It took me four years but I did it. What I will say is this -- I have definitely lost a hobby, in the sense that a hobby should be something that allows you to be creative while not feeling or reminding you of work. While I was still a lawyer, software dev (and learning it) was my hobby. I would be at work dreaming of coming home so I could tweak whatever project I was working on.

Now that I'm getting paid for it, I am completely in love with my job. Partly it's that I work for a great company now -- e.g., we get 25 days PTO (and yes, it's an American company, and no, I'm not a senior level). But partly it's that I spent time on the other side -- doing something purely because it provided me with money. Is programming work now? Yes, definitely -- but it's work I love doing.

However, I realized quickly after I started that I no longer felt like programming very much when I came home. I know that's kind of a no-no to admit to in this field, but it's true. I still do go through phases where I'll go really deep on some project for a while. But mostly I'm content to let my programming happen on the job. When I do program at home, it's still fun but it's colored by all the new relationships the activity has to work.

There’s still a world of difference between hobby and professional software development. In hobby software you fix the bugs that you fix; in professional software you fix the bugs that your paying customers hit. I think it’s why free software has had limited success in end-user applications.

A different take: in professional software, you fix the things your boss tells (or allows) you to fix, while in free software, you fix the things that need to be fixed. I think that's why I find most commercial software to be a trash fire compared to free software.

In application software? Which ones, specifically?

I can see that, what I'm trying to say though is that I don't know in which category I fit: hobby and professional are bot very engaging, sometimes I want to work at the stuff fot my job, other times for my pet projects. How would you define this given the premise of the op?

Loving what you do is the key to having a happy work life, not doing what you love. Your approach seem to embody that concept.

That could be a thing, but I achieved this unconsciously, so it's all luck.

By contrast, I was miserable through the entirety of high school and a good chunk of university: I _really wanted to code_ and nothing else at the time. For the surrounding parts of being a developer, I think I appreciate those more or less by maturing taste. Same way as the first beer you have is terrible, then you discover the interesting parts.

Also yes, I'm very happy at work, I was happy even in bad situations for some weird reason. But I'm also very happy in life in general, so it's probably a combination of both.

One of my hobby is board gaming. I can’t tell you how many people I’ve seen decide that they love board games so much that they open their own FLGS (friendly local game store). I’ve learned that the quickest way to come to hate board games is opening your own board game store. If you want to start hating your hobby, make it into a business.

> If you want to start hating your hobby, make it into a business.

Or as I've heard it phrased: "If you turn your vacation into your vocation, you'll never have a vacation again".

What you say is somewhat true but I also know plenty of people who love what they do. I suspect famous examples are say Brad Bird or Steven Spielberg. I have a feeling they loved directing.

I know Sid Meier, when he was still at Microprose, he made a deal with his partner, Bill Stealey, to give up he direct business interest in the company so he could focus on game dev. They'd pay him $$$$$$$$ for each game and he no longer had to deal with the business decisions.

The point is you can find a way to delegate the parts you don't like.

I have plenty of friends that run their own game dev companies. They love it. One has 150 employees, one has 10, another 20, one has 3, another has 10. They're are still doing dev, not just managing, even the one with 150 people and they love it.

> The point is you can find a way to delegate the parts you don't like.

So it is possible to do what you like (without considering the compensation), but probably not for everyone. Likely only for a lucky few.

Is that what your saying? Because that what I think is whats going on in the current economic model we live in.

I'm not sure your point. If your point was the delegating the parts you don't like means someone else has to do no fun parts, another solution is to find someone that likes those other parts. For example, Sid Meier's partner, Bill Stealey, loved doing the business side of things.

So much this. I tried starting a business doing something I love and I found out I don’t love doing accounts and supply chain management for it. I canned it and a £20k investment within a year.

Now I do something I dislike that I’m good at. This is the best balance I have found as the contrast from work is vast when I do the things I love and that is important. Also it forces your motivations to be efficient and decisions to be in favour of things you love which inevitably ends up with more time to do them.

I saw an artist friend comment on a "how to freelance" article that "that sounds like running a business, not being an artist." And therein lies the rub - the actual value-creation part of running a consulting business is a tiny part of the work required.

I'm slowly starting to find that the business stuff is becoming a hobby as well, which is good because I'm resenting it far less than I used to.

Yep. I would never have guessed how little time I would spend coding some weeks.

I’ve worked at the same company for 20 years. For the first 17 years another developer and myself were embedded in a business unit. I’d say we spent 90% of our time coding. Then they decided we should be integrated into IT. We since been made to adopt agile practices and all the meetings that go along with it. I’d say I spend about 5% of my work week coding now. The rest of the time is in meetings. I’m absolutely astonished at how many meetings the IT organization manages to create. I still don’t see the purpose. All these agile practices haven’t made our code any better. We are just writing far far far less of it. I’m kind of astonished anyone ever manages to get anything done.

So how's the job hunt going?

Eh, I'm not looking. The benefits are way too good and I live only 2 miles from campus (I can bike there in 15 minutes, though, I haven't been there since March 2020). If they want to waste my time with meetings, that's on them. They pay me way too much for me to complain.

Planning to retire soon?

No, I still have kids in school. No point in retiring until all the kids are done with college (to make sure I can help pay for their college).

I guess that is the downside of being 20 years at the same company.

I just started my first SWE job and I'm having a similar realization. So much decision making needs to happen before anything is even considered worth working on. As a junior, I sit silently in a ton of meetings about things that I don't even know about, haha. When my direct superior assigns me something, I get it done, ask her questions if necessary, and move on to the next task.

This is why I like remote. I have no input on these meetings, so I can work instead of being a mushroom.

I like remote because I can work on my mushrooms during work hours

In the same vein, I followed a few hobbyist beer brewers on a local home brewing forum go pro and the came to the same conclusion - making it your job takes all the fun out brewing.

You’re no longer experimenting or putting taste first, you want to convert grains into bottled beer as fast and cheap as possible so you can make a profit.

The moment you start accepting paymeny your hobby is no longer. You are now engaged in a business transaction. You now have deadlines and expectation aka responsibility. The beauty of a hobby is there is none.

Well said. There are substantial business related activities related to the product/hobby that you may not love to do.

I used to worked part-time in a ballet school. My boss and her business partner are highly trained ballet dancers. On top of teaching the classes, they do marketing, bookkeeping, dealing with difficult students/parents, hiring and cleaning in the very early days of the school. After the business took off, my boss hired administrative help so that she could take on more students.

I think one trick to get around this is by delegating and if possible automating the parts you don't like.

Unfortunately its much easier said than done because it takes meticulous planning and long time to set it up. But it can be done and after that you can spend a good amount of time doing what you love and get a lot of help with the parts you don't enjoy.

As a matter of fact if you are able to successfully delegate the parts you don't enjoy the overall result is much much better.

Yes, when I hire new people in Machine Learning they are uniformly surprised by how little time they spend modelling and how much time is spent gathering business requirements, refining what needs to be optimized, cleaning the incoming data, thinking about edge cases and so on.

This blows my mind. How does one get the skills to do ML without spending an infinitude of time cleaning data? Like the other stuff makes sense (general business process), but the lack of understanding around cleaning data from many juniors just stuns me.

Totally agree. I found out myself when I started a software business. It was doing well, I employed a number of people, we were making nice profits, but I decided to shut it down. Because it was destroying my joy of developing software.