Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Douglas Crockford

evrone.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Interview with Douglas Crockford

#71

Post by pavlov »

rvense wrote: post #69
mikehall314 wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Interview with Douglas Crockford

#72

Post by TheBigSalad »

rvense wrote: post #69
mikehall314 wrote: post #12

Earlier quoted context omitted.

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…

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.

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.

Re: Interview with Douglas Crockford

#73

Post by crooked-v »

TheBigSalad wrote: post #72
rvense wrote: post #69

Earlier quoted context omitted.

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.

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.

Re: Interview with Douglas Crockford

#74

Post by WorldMaker »

mikehall314 wrote: post #12
binkHN wrote: post #10

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…

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…

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

Re: Interview with Douglas Crockford

#75

Post by WorldMaker »

eyelidlessness wrote: post #35
tejohnso wrote: post #11

Interesting. I had no idea he had transitioned from promoting Javascript's good parts to calling for its retirement. I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there.

I vastly prefer functional programming to OOP. But I find my use of `class` in JS increasing for two reasons orthogonal to the paradigm distinction: 1. Particularly in pure JS projects which either haven’t yet or won’t migrate to TypeScript, classes are an excellent way to define data types . They needn’t be stateful, they can be used just like POJOs in otherwise pure functional code. But their shape is clear (or can…

I also tend to prefer functional programming to OOP in JS, but there's a massive legacy of OOP in JS. The `class` syntax really is just syntactic sugar for classic IIFE-wrapped `.prototype.` JS OOP. You can pass modern classes to ancient JS OOP libraries like for instance Dojo and there's sometimes few things quite as satisfying when upgrading legacy code as replacing the classic legacy spaghetti Dojo class definition IIFE with a much simpler `class SomeLegacyWidget extends DojoWidget {}`. Almost no one even needs to know what an IIFE even is or stands for today. It's great.

That `class` syntax works in all the modern browsers today, no Typescript transpile or Babel plugin or "polyfill" needed.

(Dojo comes to mind because of doing code on current ArcGIS-related projects that are still stuck in the mines of ancient Dojo versions, IIFE "classes", and AMD wrappers. Still great to have Typescript generate the AMD wrappers for you from modern ES2015 module syntax, but `class` and even `await/async` you can get for "free" in modern browsers and are huge clarifying changes to legacy Dojo work.)

Re: Interview with Douglas Crockford

#76

Post by Scarbutt »

eyelidlessness wrote: post #35
tejohnso wrote: post #11

Interesting. I had no idea he had transitioned from promoting Javascript's good parts to calling for its retirement. I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there.

I vastly prefer functional programming to OOP. But I find my use of `class` in JS increasing for two reasons orthogonal to the paradigm distinction: 1. Particularly in pure JS projects which either haven’t yet or won’t migrate to TypeScript, classes are an excellent way to define data types . They needn’t be stateful, they can be used just like POJOs in otherwise pure functional code. But their shape is clear (or can…

Immutability in JS is painful and tedious, how can you enjoy write functional code in JS?

Re: Interview with Douglas Crockford

#77

Post by WorldMaker »

the_other wrote: post #31
koromak wrote: post #18

Earlier quoted context omitted.

ES6 is what makes JS bearable to write modern day. Totally don't understand his point here. Who wants endless nested promise chains?

> Who wants endless nested promise chains? One of the things Promises solves is nesting. If you're nesting them, you're doing it wrong. (I don't mean "never nest them"... but if you find you're nesting them, see if you can refactor to "all()" them or similar)

You "should" never nest them, if you create a new Promise inside a .then() callback, immediately return it and move to a new .then() callback in the chain. Promises were built to flatten.

The hard part, of course, is threading complex flows of variables through your .then() callbacks where later Promise calls need a previous variable or three, and that's when a lot of people give up and just resort to deeper nesting. That's what async/await does the best at solving: capturing variables automatically in a simple state machine written like classic imperative code versus manually trying to thread state through callback closures and complex return types.

Re: Interview with Douglas Crockford

#78

Post by corrral »

pavlov wrote: post #71
rvense wrote: post #69

Earlier quoted context omitted.

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…

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.

Re: Interview with Douglas Crockford

#79

Post by dspillett »

capableweb wrote: post #28
dspillett wrote: post #7

Earlier quoted context omitted.

If misused it is. And it is very very easy to misuse.

On the other hand, what is not "evil" when misused?

Anything can be used for evil if you try, some things you have to make an effort to fight or they'll invite (or actively cause) evil by default, there is quite a difference there.

Re: Interview with Douglas Crockford

#80

Post by strix_varius »

binkHN wrote: post #10

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…

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