Hacker News Reader

Comment by twblalock | Hacker News Reader

Being in meetings means you get to be in the room when decisions are made. Even if you aren't an active participant, you get to at least listen in.

Almost all problems are really people problems, and people problems can only be solved by communicating with other people.

Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed. To succeed you need to make sure what you are building is actually what you should be building. I've never seen a way to figure that out without having meetings with other people.

Think of it this way -- a software engineer is not just a programmer, just as a fireman is not just a "hose operator." You are ultimately someone who gets things done and solves problems for other people, and that requires regular communication with those other people.

View on HN

>Even if you aren't an active participant, you get to at least listen in.

This is why "it could've been an email" exists. If you're not making me an active/reactive, valuable contributor, then you're wasting my time and the boss' money.

>That is not the way to succeed.

I mean, seems a lot of people managed to succeed just fine going radio silent for a long time and simply observing their target audience until the last moment. Which does allow for long stretches of work, and rails against the "communication and work need to be heavily intertwined for success!" spiel. Nor does it say meetings are the best way to do this intertwining, even situationally.

>To succeed you need to make sure what you are building is actually what you should be building.

Which does not necessarily conclude that meetings do this.

The whole comment also misses obvious points such as analysis paralysis, death by committee and more.

> This is why "it could've been an email" exists. If you're not making me an active/reactive, valuable contributor, then you're wasting my time and the boss' money.

In my experience, the people who work like this are the sort of people with 5000 unread emails who ignore slack DMs too because they're "too busy".

> I mean, seems a lot of people managed to succeed just fine going radio silent for a long time and simply observing their target audience until the last moment.

This is a local optimization, and only works if the entire team is on board with "keep BlargMcLarg unblocked" at the expense of themselves. As the parent put it, this is a people problem, not a tech problem, and by only dealing with _your_ needs you're ignoring the needs of your team.

> Which does allow for long stretches of work,

This is a time management (and people) problem. Not going to any meetings is likely to result in producers appearing at your desk because they don't know what's going on (because _they_ have 5k emails and you've not spoken to them in a week). It also doesn't solve the long stretches of work problem; time management does.

>In my experience

In my experience, there is absolutely zero correlation between preference for meetings and willingness to communicate asynchronously. To me, this is simply advocating for meetings to force people to communicate and be empathic. This has its own set of problems, as evident by anecdotes in this thread and the many discussions prior.

>This is a local optimization

On the flipside, you assume that the local optimization does not lead into a global optimization, while referring back to the parent's "meetings good" as a global solution. Obviously, giving an anecdote of the other extreme of the curve is just there to show how absurd the notion of "meetings are best" is. There is success on both sides of the curve. I would really like to see empirical evidence of "meetings best", as the trend continues towards "more meetings" (or really just more bureaucracy) without any strong evidence as to why this is beneficial for the entire company.

>As the parent put it, this is a people problem

I agree. More communication != better communication. Synchronous communication != better communication. Just like some books read better with fewer words, so can less communication lead to better communication. Unlike what a lot of pro-meeting people like to believe, the anti-meeting crowd isn't arguing for "no communication" as a whole.

Have yet to meet a company where a developer's opinion is taken into account in software architecture and solution design. And, usually, like some other guy here said, they aren't invited to these types of meetings, at all.

The best line I heard, from a team lead that wouldn't back a "don't implement a task queue using postgresql", was "because I don't understand it/am not familiar with it [the alternative solution, RabbitMQ/whateverelse Q], we're not doing it". Other times it's just silence and, then, in an email or through somebody else "we don't want to do the incorrect solution". Without offering alternatives or what's "incorrect" about them.

These are common scenarios in mega corps. The above couple of anectodes were from one of the largest payment processing company and one of the largest b2b security company.

Oh, and you'll forgive my endless rant, the best one was out of some multi-billion nasdaq blabla company: CTO was absolutely ADAMANT how to implement encryption at rest. Using some tool from his college days. But, that tool wasn't maintained for years and didn't make use of Intel's AES-NI. Even though we explained him about latter, showed him the numbers using simple Linux tools, he kept scheduling meetings "to show us". Needless to say, using Intel's AES-NI was a good approach, compared to software-level encryption. Absolute waste of a couple of weeks.

Why do you care ? If top monkey want to spend money on stupid shit, I'll happily indulge it. It is not my money that is badly spent anyway.

I envy you if you can go through your whole career like that.

But perhaps there is a middle way. Many of us care too much, and each subsequent difficult - or bad - decision drives us deeper into burnout. It's not healthy. In which case GP's attitude is the right one.

To extend further perhaps it is only useful to care as far as your influence, motivation, and energy reach. And perhaps the happiest of us at all levels of the ladder are the ones who understand their capabilities and match their care accordingly.

I have yet to work at a company where the developer’s wasn’t the primary opinion that mattered.

Pro tip: avoid working working at companies that follow HIPPO (highest paid person’s opinion).

>Being in meetings means you get to be in the room when decisions are made. Even if you aren't an active participant, you get to at least listen in.

Why do I care if I have no say in it? Why am I wasting an hour or two of my day listening in on this when they could have emailed me the meeting minutes and decisions so I can spend 5 minutes reading through them?

If I'm not actively participating i na meeting, if my views are not taken into account and respected, then it's a pointless meeting for me.

>Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed.

The reason we want to do this is precisely because we're *not* just copying sacred texts. But rather we're sitting there working with some mental models and concepts, figuring out the chain of API calls and how it all clicks together so that we can better work on the actual problems. Getting up to that point always takes some time. Even getting to the same headspace where I was the previous day when I left work, takes some time.

So if you come to my desk and interrupt me I'm going to have to start from zero again and this will take time. So if I have a meeting coming up in 30 minutes, there's a good chance I won't start anything big. And after the meeting I'm again going to just be going through stuff for 30-60 minutes before I get to the point where I was.

I hate being interrupted because my work is in large parts, inside my own head as opposed to just typing in code. And thinking is often easier when someone is not talking to you.

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

Decisions made in meetings? 9 out of 10 decisions are made far away from meetings. Meetings are there to tell people about a decision.

Or to make people believe they had actual input and ensure a stronger commitment that way. Because a team that committed to something is more likely to see it through. Even if it means unpaid overtime and all the other crap management uses to extract the highest possible return out of us working drones.

And why wouldn't they? If I can ensure that a machine runs at 120% by giving it the illusion of participation in decisions I would absolutely do this.

Focused work is essential to quality results in programming. I guarantee you that whatever piece of software you hold most dear as an example of how software should be made, the key parts of it were written in long uninterrupted stretches of work. Thinking up good solutions similarly is a focused work activity, and meetings are almost entirely unsuited to thinking of great solutions that cover all the edge cases (although they can be ok for thinking of good enough solutions).

Now, to understand the problem to be solved, to agree on a solution being proposed (out of the results of focused work), and to synchronize the progress when multiple people are working on said solution, this does require communication, and meetings are often a good way to do this. They are therefore essential to enabling the long uninterrupted stretches of work to produce great outcomes, but they must not come at the expense of that focused work.

I think the idea of deep work has a place too. I haven't read the book but I think it touch's Linus locking himself away at a critical point in Linux's development. Bill gates did something similar (not sure what he was working on at that time).

I think he did that when he created git?

Yeah maybe it was that not sure!

> Almost all problems are really people problems, and people problems can only be solved by communicating with other people.

I must dissent.

You are right that many problems look like people problems. But in all honesty, we have no clue how to solve people problems.

Talking can sometimes work, but it's not a panacea. Otherwise parliaments would have solved all problems by now.

A shockingly large amount of time, you can solve people problems by turning them into technical problems, and thus amenable to technical solutions.

To give a silly example: if people keep walking in on you when you are on the loo, a flippable keep-out sign or a simple lock on the door is a much better solution than talking to the intruders.

Less silly: if people keep breaking your build, you might be tempted to say that the solution is to clearly communicate with them to let them know that breaking the build is not OK.

The technical solution is to set up a pre-merge check that makes sure everything compiles and your automated tests succeed.

Guess which of the two approaches works better in practice? Especially when people are under stress to deliver?

(Know, if your co-workers find ways to deliberately bypass the pre-merge checks, _and_ also keep breaking the build; then this should probably be treated as a people probably. Your company should give them a warning once, and then probably fire them on the next offense.)

> Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed. To succeed you need to make sure what you are building is actually what you should be building. I've never seen a way to figure that out without having meetings with other people.

If all you're doing is sitting around in meetings all day, you won't get any actual work done.

But how many meetings are enough? Each week, I have eight meetings only with my team (that is, aside from other company meetings). And us mere developers are not invited to the design meetings. No, work is handed out piecemeal to each developer by our team leader, and we're only expected to work on our pieces, bug reports be damned! (they have to go through him first)

You wouldn't interrupt a fireman that is on active duty in a mission, though. "Stop extinguishing that fire, put down the hose and have a random meeting with me who is not directly involved in the actual process".

You might if the fireman is pointing the hose at the wrong house, or a larger fire has broken out and you need to figure out whether he should change what he’s doing.

>Being in meetings means you get to be in the room when decisions are made.

That was never my experience, especially if those meetings were standup meetings as the parent poster was referring. The standup meetings were a lot of feel good so the business could cajole the developers. Any actual coordination that needed to happen was outside those meetings among developers, with the business making their own decisions and dictating from on high.

True… but I can’t have 5h of meetings a day and be expected to produce much…

Yes you can, if you take into account the impact of what it is you produce.

Reply on news.ycombinator.com