@deloftie3619
1. Get it working 2. Get it working well 3. Refactor 4. Repeat
@marble_wraith
The thing Prime describes (at the 0:52 second mark) where you code something up that hides behind an abstraction and accounts for all these possible "future uses" is a code smell, and it has a fancy name: "Speculative Generality"
@SlightRemorse
A crossover I never knew I needed to see, but now I can't wait for the full version.
@caseyclayton01
I absolutely hate abstraction for the sake of abstraction. There is no reason I should have to look at 20 different classes to understand a <1000 line file. Yes it's happened and no that's not an exaggeration, maybe even a down play.
@sk-sm9sh
So the way I'm thinking is that - generally speaking abstractions are usually almost always good and generally aren't even bad for performance if its bad for performance its rarely fault of abstraction instead its fault of bad design. The bigger problem is that most things that we think are "abstractions" in fact are not instead it's just layers of code that don't really abstracts much. Good abstractions is not so much about making code future proof either - future proofing something again is a design goal and certain abstractions can either help it or worsen it. For example you could say Einstein's relativity theory is more future proof that Neuton's laws of nature - as Neuton's laws are fully captured within Relativity framework with more accurately capturing extreme cases - yet we still use Neuton's laws instead of general relativity for a lot of things because it's easier and because it gets job done. What abstractions should achieve is they should help us reason about the solution in simpler terms. In essence they should allow you to think about problem from higher point of view. It's really not easy to create a abstraction most often we just add layers of functions not abstractions. Good abstraction decoupled low level thinking and high level thinking. Writing code in "single level of abstraction" IMHO is one of greatest software design advice ever created. It can be useful to set stricter smaller limits when creating new abstraction - it's much easier to come up with a useful abstraction that is more limited in it's scope than one that is more universal - often abstractions that are more universal are also ones that are either more complicated to use or they make significant performance sacrifice.
@Blacky372
I feel this so much! Thank you for making this video!
@meostyles
This is ok advice if you’re working on a feature, to “just write it” and see what happens. But for designing systems wrong design decision can cause years of developer headaches
@filipbook5605
absolutely loved this, love you both for all of your content and keeping our heads cool and on the ground <3 cheers from Sweden
@CygnusExOne
Please don't hold the interview hostage.
@OMGicantwayyyyyyyyyy
Young programmers perpetually rediscovering Brooks basic concepts from Mythical Man Month. These ideas are 50+ years old.
@owenpalmr
Oh my gosh I'm such a fan of both these guys! So great to see them chat :)
@yates_
I hardly ever comment, but lord, please, this full interview needs to be released!
@philprager1445
I think it's important to note that the "9 ways to hell" is a micro scale thing. You cannot plan things on a micro scale, but you should plan things on a macro scale. I think the best programs come from equal parts thinking/planning(macro) and implementing/iterating(micro).
@RationalDissonances
loved this talk! waiting for longer version
@chrispy_baecon
Phew. This is what I needed to hear today haha! Thank you for this!
@deloftie3619
Bit confused about how this is in conflict with "Clean Code" though, I don't think clean code ever argued for future proof abstractions or anything like that. Clean Code is more make your code easy to understand and refactor because in 95% of cases it isn't you who will have to change it in the future it someone else so make it easy for them. There is a big difference between trying to future proof your code (guessing now how it will change) and making your code easy to change in the future. You don't have to know how the code will change in order to follow some pretty easy steps to make it easier for that change to happen.
@JohnGirvan
This feels like my conversations with Product and junior devs. I was once told by a senior dev many moons ago, that if someone asks for a gold sphere, build a cardboard box first. They might never need anything more.
@Utsuhoagie
Oh man, even as a noob dev with barely any work exp, I can already feel this so much with my current project, and it's just the front end. Thinking of my app as several, pretty separated modules, I decided to have my React app structured into features. But then I thought, "well maybe I'll need some kind of data mapper/formatter for all the data in each module". So I went and made a still fairly simple mapper (maps data from raw values to labels or messages, like "available: false" to "This item is unavailable"), and a formatter (formats things like currency, dates, times). But then I thought, "oh maybe some of these mappers could be shared, like a StartDate field could use the same formatter as the EndDate" so I went and made a "display mode mapper" that **maps each field to a corresponding mapper/formatter**. And now around a month after I started with that idea, I'm now left with some 7-8 different mapping/formatting objects, functions **for each module**, and I'm too scared to even touch them anymore.
@2mbst1
100% agree!! While it's fun and a nice mental challenge to abstract into the future, it's SO MUCH more satisfying, when you already built the thing and know exactly where the issues and bottlenecks are. Too often, I had to fight with things that existed ONLY because of abstractions. People have a tendency to need to show off their programming skills; but the path to true mastery, as with most things, is simplicity. Also the first time I listened to this was with audio only, but my reaction was quite similar to prime's. Came back to write this and watched the video again and laughed seeing him react similarly. :D
@vitiok78