Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Large teams are (mostly) very productive, it's just that since it's very hard to have a clear defined goal that a large number of very diverse people can work towards, they're just producing large amounts of scaffolding for all the potential stuff that could have been made towards some, as yet to be defined, goal.
How would one summarize the difference between the "what-if" at 27:04 and the chain of "what-if's" at 33:05? Both seem to be bets on an outcome. The first could save you some pain if the business changes like you thought, the second might result in a better way of writing code. What makes it seem that the first one is dangerous and the second one not? The monadic style could still turn out to be a bad idea until you haven't tried for a while, and the business change might be very likely instead. Is it a risk-adjusted return? I feel like there's some subjectivity in this, with experience and perceived probability counting a lot. But I can't see the clear separation between the two types of what-if's.
As a developer I'm always finding that we can never change anything. "We have API consumers, so nothing must change", problem is then that either you must version often, or complexity will increase exponentially, because you need new capabilities but the old needs to be compatible with it
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
My god I had no idea the two of you shared a stage. This is brilliant!
I started opening a function with `result = ...` from, I think, reading Martin Fowler's Refactoring book
These guys know each other? Oh man I’m so happy to find this out.
Large teams are (mostly) very productive, it's just that since it's very hard to have a clear defined goal that a large number of very diverse people can work towards, they're just producing large amounts of scaffolding for all the potential stuff that could have been made towards some, as yet to be defined, goal.
How would one summarize the difference between the "what-if" at 27:04 and the chain of "what-if's" at 33:05? Both seem to be bets on an outcome. The first could save you some pain if the business changes like you thought, the second might result in a better way of writing code.
What makes it seem that the first one is dangerous and the second one not? The monadic style could still turn out to be a bad idea until you haven't tried for a while, and the business change might be very likely instead. Is it a risk-adjusted return?
I feel like there's some subjectivity in this, with experience and perceived probability counting a lot. But I can't see the clear separation between the two types of what-if's.
As a developer I'm always finding that we can never change anything. "We have API consumers, so nothing must change", problem is then that either you must version often, or complexity will increase exponentially, because you need new capabilities but the old needs to be compatible with it
I can tell you in 5 sec why developers are drawn to complexity: cuz it's waaay easier to create a complex mess than a beautiful coherent simple thing.
Really? Again? 🙄