Hacker News Reader

Comment by Culonavirus | Hacker News Reader

Where do you people get this "daily standup" idiocy from? Maybe I'm too old for this crap, but you can't get anything meaningful done in just 8 hours, and if you can, what you did is definitely not worth wasting time talking about.

I feel like you have to be a literal code monkey that needs to be guided on almost a method-level to get any productive plus out of daily "standup".

This hyper-corpo "agile" garbage should have been dead and buried a long time ago. As someone who has worked professionally as a coder for over a decade, one, at most two meetings a week is what's reasonable. Anything above that is a giant red flag, most likely means you don't trust your people, and reeks of shady business practices like rotating (hiring & firing) junior devs so you don't have to pay for seniors.

View on HN

We had a daily standup at my first job in apartment maintenance, too.

Just five minutes of the whole team there at the start of the day to sync up; but it turned up lots of practical problems, like who would be in the shop to receive a planned delivery when most people would be in jobs they couldn’t pause during the day.

We have them in software for the same reasons — and it’s a giant red flag to me when senior people treat it as some kind of horrible imposition we spend five minutes a day on teamwork.

It's not five minutes a day though. Work has to stop before, and work takes a while to start after. The manager's work may take 1 minute to start and 0 minutes to stop, but an engineer working on something tough that isn't well documented may need at least 3 hours.

That means if standup starts at 10 AM, people are going to start work at 5 AM (if working from home) or end up starting work after lunch so that lunch isn't another interruption.

So move stand-up to the afternoon, or to earlier in the morning.

And if you know you have an interrupt in an hour, perhaps put off that 3-hour-long task until the afternoon.

That's the point. The "5 minute" disruption ends up with the team losing half a day of 'real' work.

Tech leads seem to have it worst as they're expected to communicate but also write code. A common pattern is to be available 8 hours/day for disruptions like this, and then work 2-8 hours at night.

> The "5 minute" disruption ends up with the team losing half a day of 'real' work.

This has never been my experience across a decade of being an SDE — and this sort of hyperbole undermines your case.

> Tech leads seem to have it worst as they're expected to communicate but also write code.

Your numbers don’t align with (eg) Amazon’s definition of SDE, where SDE1s are expected to spend 4 hours a day coding (50% of time) and SDE3 (tech lead) only 2 hours a day (25% of time).

They literally adjust their expectations to account for the increase in meetings.

You call it hyperbole then literally in the next paragraph say that SDEs are expected to spend 2-4 hours coding.

It's madness, most tech lead positions suck donkey balls.

I have learned it is better to have a team that has gelled, than to be organized around a superstar or hero developer.

That depends on the work and how it has been chunked down. Even longer projects that may take a couple weeks can have some milestones.

When I worked on a team of only senior, experienced engineers, we never had a problem keeping each other updated during daily standups. The exception I have seen might be very complex refactors, or trying to solve problems with no clear approaches.

With a team of junior engineers, it's great engaging with people and help with mentoring.

Lastly, I have found that true uninterrupted deep work lasts no more than a max of 3 hours a day, maybe 4. I've done full 8 hours daily like that, and I burned out. In hindsight, I realized that most people can't really do a full 8 hours like that.

That's understood to an extent, however the things that require that level of focus also generate other tasks like documentation, tests, possibly updating group notes or tickets regarding to the task or subtasks involved. When you add in incidentals like refilling your water, stretching, interfacing with calendars and emails, it's understandable that 3-4 hours of deep work per day is totally adequate.

I don't consider documentation and tests to be incidental, and have approached them with the same level of care and intensity as I do coding. In those days, I typically use pomodoro in order to leave room for things like refilling water, stretching, etc.

Good for you

It's nice to chat to real people for 15 minutes sometimes? Such a short meeting shouldn't feel very disruptive.

I prefer async chat; less disruptive and less annoying. I discuss more and it is easier to discuss tech stuff that way. In person/speech is a time waster we find; it is just because people are to lazy to think first and write something comprehensive down, so instead they just rattle off their train of thought. After a while most prefer it (been doing this for 30 years); the only ones who don't are sales/marketing (I schedule meetings with them a few times per month) and busy-workers who made it through the interview; we fire them. They won't perform anyway.

That's why workplaces have coffee machines and work policies include small breaks

If you wanna chat, it's fine with me, but you don't need to force everyone in the team to do it

I usually don't want to chat at work, write me an email if you need something and I'll reply as soon as possible

Then have a coffee break. You may discover that it is even nicer than saying "yesterday I did ... today I will do ... I am not blocked" to other human beings :-).

Especially remote otherwise async teams.

It’s a technique and may or may not be effective for a particular team. When I was an EM, we’d fairly regularly take stock of any processes to assess whether they were worth keeping, needed tweaks, etc. Funnily enough, on the daily standup one, I was the one who didn’t think it would remain, but the team really liked it.

its always somebody dropping these gems in interviews followed by “is this age discrimination”

the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders. in which case your own velocity isnt important as opposed to knowing if other team members are blocked on something you may be familiar with or even responsible for

a daily meeting that shouldnt exceed 10 minutes, or done asynchronously daily, is a decent way of accomplishing that

I agree with everything you say here, except for the asynchronous part. It's much better for a team to see each other face to face for a few minutes a day, especially for remote teams. It's wildly higher throughput than bullet points most people don't bother reading, it gets exposure for junior engineers, and it builds a stronger sense of being a team.

Someone who acts like being asked to spend 10 minutes a day with their team is some major imposition is worth losing over it.

We chat about everything in our team, asynchronous. Works fine for 30 years. I find people who have issues writing down their thoughts and bullet points first (which means they will be answered or addressed by someone before they can even hit a meet invite button). Each their own of course; everywhere I go (and we see a lot of companies close up because the nature of our work), we have to push away the meetings as they never work at all. What helps is asking very high hourlies; then suddenly meetings are not so wanted anymore (which proves the point).

I see the same.

There are places where the lone developer working completely async can work. Hopefully, they don't come out with over-engineered stuff that no one else can use.

> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders

That’s mostly theatre though.

Building useful software is not measured by team velocity or throughput.

In 2024 counting this stuff is crazy.

Measuring outcomes and customer value is infinitely better than measuring velocity.

Output is not hard, deciding and testing that you are building the right thing to create the right outcomes and customer behaviours to give them value is far more important.

In 2024 velocity and story points etc. and other theatrics are huge red flags to signal the organisation is not building meaningful products with care and craftsmanship.

I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.

Not the person you're replying to, but I'm not convinced there's a difference. Discussions about velocity boil down to "how much can we fit into the next sprint/month/quarter". This typically feeds into some kind of burndown or roadmap update. However it retains the pitfalls of estimating something that is often unknowable in advance.

I may be misunderstanding your comment in which case I'd greatly appreciate clarification as I really struggle with workflow planning.

I'm convinced people understand the difference.

Everyone struggles with workflow planning and that's why people use the old mid 2010s scrum terms differently now.

I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for?

In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".

> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders

Are you suggesting that the daily standup is to provide progress updates to the wider company (and possibly clients)? In my experience doing it like this makes it less of a safe space. It's purely a discussion between Devs and QAs about what's currently being worked on.

Alternatively why even have a meeting?

Just have a channel in slack/mattermost/teams for your team to post what they did and what they are stuck on at the end of the day and what they plan on doing at the start of the day.

You get the same result but without forcing people to spend the 15-30 minute wasted time before the meeting and the hour or so of degraded performance while they try to get back into the zone after the meeting.

Standups only benefit management and they really are the pinnacle of "this could have been an email/message".

The only time they may be acceptable is if everyone on the team dedicates their entire schedule (at least for the week) on that one project and if they work the exact same hours, the exact same days, in a no-remote environment. Then you can have a quick 10 minute meeting around the coffee machine while people grab their coffee in the morning.

Otherwise just make it an email/slack message.

Unless people sync up socially, it is unlikely the team will gel.

Some places let a lone developer do everything. More power to them. I think there's a better chance for the team to problem solve together and be able to have continuity as people join and leave the team.

This does not require standups.

You can have planning meetings but those are relatively short (<1hr) bi-weekly or monthly meetings.

And you can have an open coworking VC. I've not seen this formally in a corporate environment personally but I've sat in calls with friends at work for hours doing mostly the same thing (just informally). And in a formal capacity it's fairly common in open source project spaces. Their discords will have an open VC channel for "co-working" or working while on VC so they can occasionally chat, ask questions, or otherwise interact socially in a way you could while in an office setting.

The best part of coworking spaces is that they are optional. You join when you want and you deafen yourself or leave/DND when you don't want to be there and need to be undisturbed.

If you want to build a social fabric and get the team integrated, the way you do that is culture. Enforcing socialization isn't a good thing.

Don't make "Mandatory Fun". The only thing it breeds is a toxic work environment where people don't want to be there.

You can go for tgif for socially gelling. We go to lunch together, often dinner en also drinks. No need for standups for any social contact. Especially when talking about work things.

That sounds like there is something to unpack there. I think it is beneficial but others do not. Why is it?

Maybe it is because I've largely worked on remote-first teams, even before COVID. There are no TGIF, unless people make an effort to zoom together while drinking or something.

Sure, I work mostly with remote teams for the past 30 years. My point stands in that yes, Zoom is nice for socialising; I see no point in daily standups and voice meetings. We do have drinks/gaming for social; just no one wants to 'socialise' while working on something; it's simply not effective.

This. Virtual coworking spaces are a great solution for people who work well that way and you can host virtual game nights or movie nights outside of working hours for people who want to participate but you can't make people socialize by wasting their time with pointless mandatory meetings.

Socialization isn’t about doing things like pizza night or having games. It’s more about establishing connection and rapport, the basis of trust and communication. Most people are not going to be doing that asynchronously.

Most humans we hire / work with / meet online or irl do. It doesn't really matter what 'the rest' are up to for me.

> just no one wants to 'socialise' while working on something; it's simply not effective.

That sounds like you disregard the entire notion of paired programming, which I'm sure you didn't mean to do.

yes that’s what asynchronously refers to, it’s in my post you might have been typing while I added that

ahhhh yeah. I'm guessing I probably caught it right in that sweet spot between post and edit.

You have to be a manager in order to throw a word salad like this. "stakeholders", "forecast team velocity", "aggregate potential throughput"...

As an engineer, my feeling is that this bullshit never works and loses a lot of my time for the sake of a manager justifying their work instead of actually creating value.

"stakeholders"

Can I ask what do you think this the term "stakeholders" describes and what alternative terms you should use?

Stakeholder is corporate jargon.

User, customer or client are the normal, non-corporate jargon, terms.

A cynic might think 'stakeholder' gets used when a company forgets about the end-users.

I was more interested in the original authors definition as he called it part of a word salad.

I don't see a problem with some terms as being corporate jargon. That's just shorthand for an idea the same way any slang for a group is shorthand.

Here is why I did not answer: I don't think you are genuinely interested, I think you just disagree and were trying to argue that it was not a "word salad". Which is valid, it's okay to disagree with my subjective opinion.

For the sake of the argument: I say "apple, pear, avocado... that's a salad!" and you answer "Why would you say that an apple is necessarily part of a salad? How should I call an apple if I don't want it to sound like it is part of a salad?"

What makes a salad is the aggregation of multiple ingredients. Of course "stakeholders" is not a word salad.

You typed more about your definition of "word salad" than you did about stakeholders.

I think business shorthand is great. The word stakeholders has meaning and isn't part of a word salad to me.

> You typed more about your definition of "word salad" than you did about stakeholders.

Because it seems to me that you focus on my definition of "stakeholders" but you actually have not understood what I was trying to say, which requires understanding what I mean by "word salad".

> The word stakeholders has meaning and isn't part of a word salad to me.

And this confirms that my point hasn't been understood.

Yes, I do not understand your point.

> creating value

No true engineer I know would be caught dead using that phrase. Must be a manager! Gettim!

Hahaha, Touché! Here is an upvote :-).

I think it's very funny because I first wrote "instead of actually doing stuff" (which was wrong because this is "doing stuff", just bullshit stuff IMO). So I rephrased as "instead of actually being productive", which I thought was maybe a bit aggressive.

So I went for "actually creating value", because it felt like the way a manager would describe it. "I appreciate that you are doing work, and it is good, but it is not creating value... therefore I believe we need to change something" is how I imagined trying to constructively say "this is all bullshit, but I respect you as a person and I believe that you could do proper stuff instead".

Did you pick up any management experience on your way to becoming "too old for this crap"? I just passed the decade mark in my software career, and I've gone from individual contributor to tech lead twice now. I've mentored multiple developers through their junior years and into mid-level positions.

I'm not an expert on agile or waterfall or whatever methodologies people write books about. I genuinely don't know or care what the big tech companies are recommending. I just know that standups are an effective tool for managing a junior team.

I'm not saying you're wrong, but I get a whole lot done in 8 hours.

Me too, but it's usually not hard stuff and it's not worth talking about it

I'm just better at coding than at sitting idle while a group of people every morning talks about minutia like it's something really important

If I've said "it takes X days" and I've consistently delivered on time, I probably do not need to check in everyday to say "we are one day closer to delivery"

Well, if people can't get anything meaningful done in 8 hours, there're some issues with planning and delegating tasks. There're a lot small tasks that can be done to push thing forward and they shouldn't take a lot time to do if planning went well.

The problem is that the team doesn’t trust you (not you in particular). So everything needs to be discussed within at least some of the team members and your PM/EM. Meetings are for that (because it gets messy via chat only).

I don’t like it either.

Cargo cult from some bullshit agile methodologies.

And then shifting baselines: young engineers start in a world where "agile is good" and "waterfall is bad", but they don't know what waterfall is or where agile comes from. They are just given the agile bible and made to believe.

Reply on news.ycombinator.com