Hacker News Reader

Comment by sheri | Hacker News Reader

> We don't even "work with" each other. If you don't learn anything else from this, get this: we work alone.

I don't get this. I like working in a team, and like working with people. I can't imagine working alone all the time. I am more productive when I am with the team, and interacting with the team than when I am alone in a room.

I know everyone works differently, but almost no one seemingly is willing to discuss an alternate version of this. I'm tired of the old 'meetings suck, PM's suck' cliches. When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.

View on HN

> I can't imagine working alone all the time

I can. I like working that way because it lets me focus and write really good code.

being around people, is more social, but I'm not writing code while I'm doing it. Which doesn't mean that it doesn't have its place, because it does (meetings are necessary to get a shared clear plan of how to work together on something, getting help on a problem or helping out with a problem builds trust/camraderie among team members)

> I'm tired of the old 'meetings suck, PM's suck' cliches

Just as I'm sure tons of programmers are irritated hearing you seem to suggest that working on their own is somehow bad or wrong.

> When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.

How did you get work done in meetings? By definition, meetings are stopping work to communicate; the most work-efficient approach is to optimize away the need for meetings as much as possible.

What is work? Is it the typing of the code, the architecture of the software, or the decisions about what the software should do for the user? The latter 2 can be at least improved in meetings, where the clash of different opinions can produce a better outcome than just one person implementing their whims.

> By definition, meetings are stopping work to communicate

You have implicitly and uselessly defined "work" as "everything you do that's not communicating".

I can write code and solve problems all day long by myself. So can my coworkers and housemates. When we have meetings at work, we figure out which problems to solve and why. Why is it that the coding part is considered "work" and the meetings is considered "not-work"? I would just be a lone programmer working on subsets of the wrong problem without the meetings. Lately, I feel like the "work" gets done in the meetings, and I just tidy up afterwards (for a few days) by myself. That's because the answers are easy, but the right questions are hard.

Let's try this: meetings are stopping implementing to communicate. Or, from another perspective, coding is postponing meetings until new issues/questions have been solved.

> Why is it that the coding part is considered "work" and the meetings is considered "not-work"?

In kernel terms, meetings and PMs are the scheduler, and you are the threads/processes being scheduled.

Is the scheduler doing work? Yes. Is that work simply overhead required to keep the pipeline full and fair scheduling of work occuring? Yes.

> Let's try this: meetings are stopping implementing to communicate or from another perspective coding is postponing meetings until new issues/questions have been solved

Or to put this another way, meetings are a page fault interrupt that is taken because the necessary backing store (the solution to issues/questions) is not available.

They're almost pure cost. Spending any more time there than you absolutely need to is a waste.

> Spending any more time there than you absolutely need to is a waste.

This is a tautology. Spending any more time anywhere on anything is a waste. The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.

> The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.

The fact that some meetings add value doesn't mean all or even most meetings add value.

My analogy holds; page fault handlers add value. They also incur a heavy cost and you want to avoid faulting if it at all possible.

I agree. You asked "How do you get work done in meetings" and implied it was impossible. I argue that just because there is no work accomplished in your meetings or most meetings doesn't mean that no work can be done in meetings. No one anywhere is suggesting that valuable work is accomplished in all meetings. But when you suggest that no work is accomplished in any meeting, you're wrong.

I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist. My workplace is different. Since my most valuable work is accomplished in meetings, I wish I could be in meetings all of the time. The only reason I can't is because we frequently need long breaks to implement the work we did in the meetings. In fact, coding is a much heavier cost than meetings; unnecessary coding is much worse than unnecessary meetings and you want to avoid unnecessary coding at all costs (even though it's usually still quite fun). Just because you develop software doesn't mean you should spend as much time as possible writing code. Just because you produce code at work doesn't mean you're only working when you're coding.

> But when you suggest that no work is accomplished in any meeting, you're wrong.

This is where we disagree. Talking about work isn't tangible work. Talking unblocks work, to a point.

> I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist.

Given that my experience spans roughly 15 years, major corporations, small and large startups, in both management (director, VP, and C-level roles) and engineering (software, systems) I'm inclined to trust my experience that meetings are generally a work-substitution mechanism and a means of furthering political/social career advancement, and bad PMs (which is, sadly, most of them) are the worst offenders of them all.

Man, no offense, but you seem extremely short-sighted here. So when you and a couple coworkers are architecting a system, deciding what the pipeline of information flow is going to be, where the security holes may be, stopping any latency or unnecessary operations, and making sure the user knows how to use the damn thing on top of that - and you aren't writing code, but instead communicating with your coworkers - you don't think that's work? How could it not be?

Reply on news.ycombinator.com