Hacker News Reader

Comment by mikehall314 | Hacker News Reader

We tried this in a team a few years ago, and the problem we faced was developers literally falling asleep during readings. We found that the Team wasn't really engaging with the process and instead just tuned out until it was their turn.

That doesn't mean I think Crockford's "Dailies" model is a poor one, it's just one issue to be aware of. Though I often find the same in Scrum teams. Folks aren't listening, they're just waiting for their turn to speak.

View on HN

> literally falling asleep during readings

Dailies in film is watching not quite the final product, but still an output of the process. Maybe the issue was reading code as a team (that's code review/PR) rather than reviewing the output of the code? I think Dailies as a metaphor to me sounds like a call for more regular QA/UAT style review sessions as team. (This metaphor is new to me, but regular "use the product as a team" sessions might be quite useful, just maybe not every day.)

Though he doesn't mention it in this video, I have seen Crockford promoting the 'Dailies' idea in talks before - and he does promote it as a replacement for code review and stand up.

One hour, every morning, where the entire Team reads the code written the previous day and offers feedback. Juniors learn from seeing real-world code presented and explained, Seniors get peer review, more eyes means fewer bugs, etc.

It didn't work for my Team, but I would be interested in trying it again in future.

This has been common in the scrum ceremonies I've participated in in most of my career. The standup is primarily for keeping your manager up to date on how things are going with your estimates and maybe for asking for help from a coworker with a blocking issue.

I think what Crockford outlines here would be fantastic if it worked. Multiparty code review.

The reason it works for movie production teams is that they don’t watch dailies most working days of their career.

The film shoot is a special high-intensity time. You may spend months and months in pre-production, but the actual shoot might only be 20-30 days (on a lower-end production). Every day needs to count. If you can learn from the previous day and improve, it makes a real difference near the end of the shoot when you’ll have much more freedom to experiment.

In contrast, software engineering is more of a uniform slog. Back when software shipped in physical boxes, there used to be a marked difference between the planning, development and testing phases, but that’s gone. At many companies it’s just a grind of tiny features and endless tickets. Hard to get excited about the “dailies” for that.

Plus, if you miss a mistake in a shoot it will be expensive to fix after shooting wraps, if not impossible. Bugs might get more expensive to fix over time, but most don't, really. Not like that—not with such a very-near-future cliff after which they get far more expensive. And I'm not sure how many more you'd catch doing daily team reviews versus less-frequent targeted code reviews, anyway. The practice sure sounds brain-meltingly dull, to me, and with little benefit.

If it feels that way I think your scrum master or entire team is doing a poor job. It shouldn't feel that way if you want it to work.

That's how it's felt at literally every software job I've had that has done the "standup" thing.

Same here. I've never experienced a place where standups added value (at least from my perspective.). Quite the opposite actually.

Same. I don't hate them (they last at most 10 min.), but as someone who has been working for more than 12 years in the industry I think managers/teams do daily stand-ups because of cargo cult.

Same here. I went looking for a non-standup job last month.. I didn't come across any.

My current company has one once a week which is tolerable. We're hiring, especially for FE developers if you're interested.

It's a really boring 10 minutes though and it happens everyday. And it translates to more than 10 minutes of wasted time because of the context switch (and the added drudgery that can affect morale)

Sounds like a problem with the team more with the process. If they don't care, they wont care.

> If they don't care, they wont care.

We need to accommodate human nature, not change human nature to accommodate corporate requirements. Its irrational to expect a group to rally passionately around every available task. Robotic.

The good question is how to hire people that will care, and whether or not it can be incorporated into a culture.

Let's hire people good at programming and let's leave the fluff behind.

After many years, defining "good at programming" is hard. I would say, reading your code is part of that. I used to read all the code that got checked-in for one of my large projects.

The other part is that you can also grow people into being good. This is one of the more important roles of big-tech where college grads come in as n00bs and become engineers.

> Folks aren't listening, they're just waiting for their turn to speak.

That statement works in so many contexts

Reply on news.ycombinator.com