Hacker News Reader

Hey, I have a counterpoint to one of your comments wrt attitude concerning meetings: if I sit in a Teams call with 50 other people, mic muted, camera off, listening to some person I haven't seen before talk about some business development I haven't heard of before, it's not going to matter what attitude I have. No-one will notice "what energy I bring" into that meeting. None of it matters. It's just one more day of boring corporate dystopia where nothing matters.

I hear you, company wide status meetings can seem pointless.

I've worked at places where there were large "company update meetings" for the whole company. They were only once a month but still frustrating to lose an afternoon to listen to every detail about who the sales team pitched to this month. Seemingly we had to have every detail of their job explained but the entire software development team had 5 minutes at most to say what they'd done.

It was a source of friction between the development team and the management team especially during crunch times when we really couldn't afford to be losing an afternoon for the whole team.

We managed to persuade our boss to let us remote in to the meetings from our desks instead, so we could listen along while getting on with work.

With covid normalising remote work, large meetings can be both easier to deal with due to not having to have physical presence but also more of a strain as it's harder to get meaningful output from them.

Can you skip that meeting?

If attendance is mandatory and recorded can you make objections to being made to attend?

If not, and if the meeting is genuinely a waste of your time, can you just mute the meeting / take off your headphones and get on with your work?

If you have retrospectives, then be sure to call out that 50 person meeting as a waste of developer time and don't be scared to keep hammering the point that it's taking away a large amount of resource. Be sure if (when) there is pushback from higher ups that you listen to why they think it's important that you attend.

If it's genuinely taking up a whole day on a regular basis then there may be a culture issue. In general culture problems are worth an attempt at fighting, but be aware that most of the time the culture won't change and you might find you're no longer considered a good culture fit and nudged out if you fight too hard.

All companies are different, and it's worth spending a while job hopping to better understand the company landscape and where you best fit. Don't listen to people who say that job hopping looks bad on a CV, especially early on in a career. That's a myth peddled by people who grew up in a different time and who are largely in charge and don't want people to job hop because it costs them money to recruit.

> company wide status meetings can seem pointless.

Not just seem, they are. But if you can turn off your mic and video, you can play videogames or bake a cake in the background. Everyone wins: Some feckless manager feels important and you do something you actually enjoy.

yah - our weekly 'all hands' seems to basically be: The Marketing Team marketing the marketing team to the rest of the company.

It's frustrating; and worse, we've had our CEO several times send group messages to scold people for having their camera off, or worse (my sin), camera on, but obviously doing work and not paying attention. It's pretty gross.

If the meetings are useful, that's fine, but I have a hard time taking pride in a long series of meetings to decide the contents of a 15-page document describing the design for feature that could be like 200LOC but now must be 2000LOC and involve integration between multiple teams' services because the promo criteria says "collaboration."

That sounds like a Big Company problem.

There are hundreds of thousands of software development jobs in companies where the whole software development department are fewer than 10 people.

If you absolutely abhor integrating software between teams then they can be a breath of fresh air.

That said, you will very likely find other frustrations, from their (lack of) tooling, greater impact of colleagues, more idiosyncratic approaches to development, lack of onboarding / documentation.

But if you're keen then they can be great places to work. You can make a real stamp on how they work and feel like more of your time is delivery.

But you will have to juggle different concerns. You might turn up and find they don't have a bug tracker or source control. Or worse, they do have source control but their entire knowledge of git is "git commit -m 'Checking in end of day'" (and "delete; git clone" for when Things Go Wrong).

Then tell people. Make it better. You can improve process in the same way that you can identify broken components of a codebase, take ownership of them, and improve them in measurable ways.

In my opinion, it takes a damn good meeting to beat no meeting at all, and most meetings don’t even approach darn good.

Most meetings I attend are held out of habit more than need.

> If you start taking pride in the state updates, the endless meetings and approach that part of your work with the same pride you would approach coding then you may find some of the stress disappears as instead of always fighting the system you flourish within it.

Taking pride in useless make-work turns you into another useless make-worker, making life suck more for anyone who is still actually trying to get anything done.

It’s good advice if you want to suck the soul out of everything you do and become a cog that works 20% of the time, producing less than 20% of what you’re capable of, but getting along really well with management drones holding endless meetings.

Responsibility for actually shipping something will shift to the next guy who hasn’t yet embraced the futility of trying to get anything done.

He’ll be the one blamed for not shipping and for not being a source of joy in the endless meetings.

I have to say, any tech organization that has its engineers only coding 20% of the time is doing it wrong. Yes there's much more to software development than pure coding, but 20% would suggest serious organizational structure and process issues.

No, he's right and you're probably wrong. Depending on what you count as coding.

Stuff you need to do:

1. Write docs.

2. Update docs.

3. Run test suites.

4. Check test suite reports.

5. Fix tests or code if they fail.

6. Design work for code.

7. Requirements gathering/refinement.

8. Estimating work.

9. Investigating production issues.

10. Fixing production issues.

11. Deploying to various environments.

12. Investigating deployment failures.

13. Teaching and mentoring less experienced team mates.

14. Reading up on both tech you use and tech that you plan to use.

15. Syncing with other teams about new features or products you're working on.

16. Design work for test suites.

...

Most of those things are not "coding".

In my 2+ decades at Apple, I think I enjoyed working on frameworks more than I enjoyed working on applications for many of the reasons you mention.

Your "customer" for a framework is a fellow dev. That can make all the difference in the world. Design and marketing generally take a back seat.

I've spent a good part of my career doing tooling for developers and customer service. The amount of "customers" is a lot smaller and they tend to be technically proficient and know what they want and need.

Eh. It can become a bad job too. When a tooling team has fulfilled its basic mission and things are good enough it can turn into a really bad job because it turns into a scrum death-march for features of questionable value and never ending bug fixes to fill time.

Your argument is quite usual in this sort of discussion and it mostly comes from dev managers or TLs who are almost gone to the 'other side'.

I (everyone?) agree that software development is not only programming/writing code. It also system design, documentation, finding solutions, troubleshooting, load testing and so on. And yes, it is also gathering and understanding requirements and collaborating with other teams. But if your average developer only has 20% of time for coding and everything else goes to meetings, you are doing something terribly wrong. Simply because the time of the developers is used inefficiently, unless you are doing something very simple (from technical point of view) and cut costs on other roles, so devs are doing everything. Usually it means that there is no proper Product/Project management and technical leadership. You can build a lot better and faster if your developers have time to focus on development itself without going to constant meetings to understand this sentence in requirements. Even during my 'worst' (from dev time perspective) years as a TL I spent ~40-50% of my time to management/communication work. It allowed team of 5 devs to be almost distraction free (less than 3 meetings per week per dev), because I worked as proxy for them.

In my experience adding good technical PM between devs and other managers can greatly increase devs efficiency and more importantly - their happiness

Yes there is a huge difference.

I'm not sure what OP had in mind when asking the question, but at least for me it can be rephrased as:

"I LOVE Software Development/Engineering but HATE the industry. Can anyone relate?"

I really like the challenge of everything regarding SWE...users, specifications, documentation, planning, working with teams, testing, et.c.

But in most projects I have worked in something else has crept in:

  - No access to customers/product owners to discuss solutions
  - Everything being treated as manufacturing line
  - Fixed long term plans even though conditions have changes
  - Developers taking blame for changed conditions/wrong features