Hacker News Reader

Comment by rmason | Hacker News Reader

I shudder to think how much more I could have accomplished if I'd worked for a CEO who had my back like that! I've had jobs where half my time was coding and the other half was in meetings. When all I wanted to do was code. Guess that might be why I was attracted to startups in the first place!

View on HN

I'm very much in favour of cutting down on pointless meetings and processes for processes' sake. However, I think that "just wanting to code" can be an organizational anti-pattern as well.

Code doesn't exist in a vacuum. It's only by context that code is provided with value and meaning. If you're the only person working on the code and you know exactly what you want to achieve then just wanting to code might work. In almost any other case you have to communicate about what the code is actually supposed to do because otherwise you're likely to create wasteful instead of useful code.

Sounds like a minefield honestly.

Being lower in the hierarchy but making decisions whether a meeting is worth your time pushes a ton of risk onto you if there is a mishap.

How do you respond to "You would have known if you stayed at the meeting"? Would the CEO have your back? How many times before you start getting a "problem employee" reputation.

I think you'd quickly realize to just stay at meetings but now you have no grounds to bring up criticism since it is assumed you could just walk out.

>You would have known if you stayed at the meeting

If a meeting is structured such that an attendee has enough time to realize it's pointless and leave before the meeting gets around to the important part, then it's a bad meeting. That meeting sounds like it should have been an email, or a message in an IM channel, or even more than one smaller meetings.

A manager who structures meetings so that people have to sit through pointless drivel in order to receive one or two important nuggets of information, is a bad manager who's scheduling exactly the kind of bad meetings that Musk is talking about.

He didn't say walk out of meetings if you like to code instead; he said walk out of unproductive meetings, if they're wasting people's time. There's a fine line there...

In my experience genuinely productive meetings are rare...

The point the parent comment is trying to make is that meetings are a waste of people's time. Most software engineers will agree that the majority of meetings are unproductive.

Most software engineers often fail to see value in things that aren't of immediate interest to them. That doesn't mean meetings are a waste of people's time.

I'm actually worried this is going to backfire massively precisely because people interpret it so liberally. I hope he realizes what judgment calls he's asking everyone to make.

It will be a test of whether he's hired good people.

> The point the parent comment is trying to make is that meetings are a waste of people's time.

Any guesses what the corresponding point I was trying to make was?

Sorry if I didn't make it clear but I would have only walked out of worthless meetings, not all meetings. I've had meetings in my career where I didn't know why I was even there and those where nothing was ever decided.

I guess doing only coding would work great, with only nuance - if you are the only who is coding at company .

While meetings can be unproductive in the form of code, your mind shouldn't be unproductive. Often boring meetings are a good time to reflect and daydream and improve designs.

Productivity is the greatest source of waste. Coding the wrong thing is worse than being in a long meeting which might have led you to code the right thing. And by write/wrong I mean for the user.

Coding is the easy part of software creation. You can teach anyone any technical skill in a fairly short amount of time. Teaching someone systems thinking, and UI design, and just plain good taste is much harder.

You're assuming that the meeting will result in the correct thing being done. In my experience, that's not at all guaranteed.

The most efficient path to doing the right thing for the user is just to do something, get feedback, and iterate quickly.

I don't disagree, but often that "thing to just do" isn't code...

Yes, sometimes the most efficient way to feedback is to not write code at all. Maybe it is a design document, maybe it's a prototype or mockups.

Sometimes it's creating software that the user can actually control and understand and solve their own problems vs waiting for a developer to create that one feature they need.

But that would require a little bit of thinking outside of code... Those boring meetings are a chance for your mind to wander and play around. The outcome of the actual meeting is less important.

Ponderous meetings don't design good software. Every meeting heavy piece of software I worked on was hot garbage. You're much more likely to get good software if you have the engineers do the job themselves, then tell them to start automating. Once that's done, have the engineers train people to use what they've created full time, and watch them automate that (by simplifying and writing help docs) as well.

No, good designers design good software. You aren't going to get good software with or without meetings if people making the software don't have the skills to do it. Garbage in, garbage out. Diving deep in code is an expensive way to find that out. I've also never met a good designer that just jumped in code without knowing the domain. Sometimes that requires them, gasp, meeting with people first to learn about the domain.

But yes, most meetings are terrible, but you can't always know that ahead of time. Elon Musk is a perfect example of someone jumping head first without knowing to fill the pool first. Some of their production problems have been solved by other manufacturers a hundred years ago.

Reply on news.ycombinator.com