Hacker News Reader

Comment by binkHN | Hacker News Reader

I thought this part was rather interesting:

> Evrone: You spread the idea that developers should read each other's code regularly…

> Douglas: In filmmaking, there is a time in the morning called "dailies", when the previous day's footage is examined. It looks like everyone is just sitting around watching movies and wasting time, but it is critically important in finding problems early and assuring the quality of the product. I believe that we should do the same thing in programming. We have a time every morning when the team gets together and reviews all of the code and designs that were developed the previous day.

View on HN

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.

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.

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)

> 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.

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

That statement works in so many contexts

Yeah, I'm curious how common this is. If anyone has done it/is doing it successfully, could you share more about the approach? It sounds valuable in theory but it also sounds like a ton of time during which people can half-listen and say "Sure sure, looks good", especially on a larger team.

I tried it with my team about 4-5 years ago and found it, while useful, to be too much overhead for the benefit it provides, especially when compared to normal ad-hoc code review.

I will do something similar as part of big product releases though: I'll get the team together and we'll do a once over walk through over everything end to end. Normally this produces about an additional sprint (two weeks) of work ahead of the launch as you uncover problems and people see things with fresh eyes. So make sure to build that time into your schedule.

If you hear advice that’s not prefixed with “we started using it X ago and works great…” - be sceptical as default.

A couple teams ago we did frequent pair programming and routine code reviews. We discovered both practices were very useful in some contexts, but a waste of time in others. For instance, do you really need to review each others semi-robotically-generated accessors or other simple code? Probably not (though checking such code is in line with previously established architectural guidelines is a good idea.) But there are some parts of the codebase where it is extremely useful. Figuring out which is which is sometimes more of an art than a science.

(As an aside, I think I understand a bit more about Lisp macros after contemplating this... Properly applied macros and DRYness allow you to elimiate much of your "simple" boilerplate, so you're left with beefier chunks of functionality. Like everything else, though, YMMV.)

Plus there's the fact that film casts and crews have a work day that's quite a bit longer than a programmer's typical work day. We have already enough problems with crunch; do we want to make 10-12 hour workdays the norm? Because that's what will happen if you want to maintain current development velocity.

Finding problems earlier increases velocity, so I would expect the opposite. If people are spending all 8 hours coding it is unlikely they are producing good code.

Is the only difference between this and a standard code-review process that the whole team participates in each change?

Reply on news.ycombinator.com