Silicon Valley S01E05 scrum scene
Boris van woerkom0 HN recommenders · 2017–2025
3.4M views · comedy · evergreen · Uploaded 2014-05-08
A short scene from Silicon Valley season 1 episode 5 satirizing scrum and agile meetings. The characters mock how process rituals turn simple things into a job.
HN uses it as a joke reference in threads about agile, scrum and process overhead.
1:03:55🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
32:56Bret Victor The Future of Programming
Joey Reid
51:22USENIX Security '18-Q: Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible?
USENIX
1:18:21"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
2:58The Loving Trap
Ben Woodhams
58:39Tim Ewald - Clojure: Programming with Hand Tools
ClojureTV
28:17Using Python to Code by Voice
Next Day Video
48:51Transforming Code into Beautiful, Idiomatic Python
Next Day Video
3 comments from Hacker News
I haven't experienced that at all. Okay, yes. When you ask your boss what he measures you about, he'll give you performance data. Tasks closed, commits sent, LOCs produced, etc. But what he really measures are top features you produced. And that happens rarely. I think for a really talented guy it's 0.5-1 top success per year. And these don't need to be measured, they are team memory. Ask your team who is most talented in their eyes. They'll agree on a small number of names. And if you ask them why they believe it, it's something like "because he wrote our test automation" or "he's the guy you ask about that really nasty part of ancient code". Everything else is only for self-fulfillment of the developers. E.g. [VIDEO]
Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1] [VIDEO] S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
>That feels like it really came out of nowhere, and after seeing so much code to implement what other languages have as a first-class feature (albeit with trade-offs that Rust clearly wanted to avoid), it comes across almost as a coping mechanism. It's really not fair to compare these when most of the errors of one language are caught at compile time by the other. It reminds me of that scene from silicon valley "Anything related to errors sounds like your area [VIDEO] Can we not just agree that interpreted languages (save the Ackshually) like python and node need a more elaborate error handling system because they have more errors than compiled languages? It's not a holy war thing, I'm not on either side, in fact I use interpreted languages more than compiled languages, but it's just one of the very well-known trade-offs. In the alternative, you would at least admit that error handling in an interpreted language is completely different than error handling in a compiled language.