6 ms·

I thought this part was rather interesting: > Evrone: You spread the idea that developers should read each other's code regularly… > Douglas: In filmmaking, t

by binkHN 4y ago

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.

mikehall314 4y ago
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.
- deleted 4y ago
  [deleted]
- the_other 4y ago
  Sounds like a problem with the team more with the process. If they don't care, they wont care.
  - tmp_anon_22 4y ago
    > 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.
    - mathgladiator 4y ago
      The good question is how to hire people that will care, and whether or not it can be incorporated into a culture.
      - ipaddr 4y ago
        Let's hire people good at programming and let's leave the fluff behind.
        mathgladiator 4y ago
        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.
- rvense 4y ago
  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.
  - pavlov 4y ago
    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.
    - corrral 4y ago
      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.
  - TheBigSalad 4y ago
    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.
    - crooked-v 4y ago
- WorldMaker 4y ago
  > 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.)
  - mikehall314 4y ago
    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.
- tomcam 4y ago
  > Folks aren't listening, they're just waiting for their turn to speak. That statement works in so many contexts
ineptech 4y ago
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.
- CSMastermind 4y ago
  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.
bitwize 4y ago
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.
- jacobsenscott 4y ago
  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.
retrocryptid 4y ago
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.)
mirekrusin 4y ago
If you hear advice that’s not prefixed with “we started using it X ago and works great…” - be sceptical as default.
strix_varius 4y ago
Is the only difference between this and a standard code-review process that the whole team participates in each change?

by binkHN 4y ago

mikehall314 4y ago

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.

deleted 4y ago
[deleted]
the_other 4y ago
Sounds like a problem with the team more with the process. If they don't care, they wont care.
- tmp_anon_22 4y ago
  > 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.
  - mathgladiator 4y ago
    The good question is how to hire people that will care, and whether or not it can be incorporated into a culture.
    - ipaddr 4y ago
      Let's hire people good at programming and let's leave the fluff behind.
      - mathgladiator 4y ago
        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.
rvense 4y ago
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.
- pavlov 4y ago
  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.
  - corrral 4y ago
    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.
- TheBigSalad 4y ago
  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.
  - crooked-v 4y ago
WorldMaker 4y ago
> 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.)
- mikehall314 4y ago
  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.
tomcam 4y ago
> Folks aren't listening, they're just waiting for their turn to speak. That statement works in so many contexts

ineptech 4y ago

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.

CSMastermind 4y ago
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.

bitwize 4y ago

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.

jacobsenscott 4y ago
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.

retrocryptid 4y ago

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

mirekrusin 4y ago

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

strix_varius 4y ago

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