@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"
@owenpalmr
Oh my gosh I'm such a fan of both these guys! So great to see them chat :)
@Spaceizcool
What an awesome conversation. I couldn't agree more. This is why it's called a programming language. The "languages" we know constitute the extent of our brain's capacity for thought (I would consider math a language as well in this context). When we use the English language to write, we are actually using it to think; putting our words in the right order and sentences in the right structure is literally our process of formulating a response to a problem (we are almost always writing about a problem). So, no writer can write a book in their heads, and software engineers can't just think up the perfect code. The act of using the programming language is the same act as solving the problem.
@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
@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
@chrispy_baecon
Phew. This is what I needed to hear today haha! Thank you for this!
@SlightRemorse
A crossover I never knew I needed to see, but now I can't wait for the full version.
@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!
@ghostandgoblins
I loved listening to this. I am at the very beginning of learning programming and this is exactly what I do. I just write a simple attempt at what it is I am trying to implement. See what it does. What's being returned. Where, if any, there is something going wrong. I get to a happy working state and try to understand where I can maybe make it better or learn from my code about how I was thinking at that point in time that got me into trouble.
@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).
@Whateverworksism
Casey is seriously great. I enjoy a lot listening to him.
@chadzulu4328
I needed to hear so much of this. Thanks!
@Astric24
I've definitely programmed 10's of times less than either one of you, but every time I coded with a plan vs. without a plan, coding with a plan helps me way more. Usually for me even just writing all my desired steps explicitly helps me immensely to understand what the program should look like. And UML diagrams get a lot of hate, but I think when you're trying to share with someone else what your mental model looks like, they do a pretty good job. Like y'all mentioned, sequence diagrams or whatever will not get every intricacy, but if I start by seeing the diagram then the code afterwards, I can navigate it with way less friction than "where am I? why am I here anyway?"
@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.
@Optimus6128
Love the host enthousiasm, also like what Casey has to say, can't wait for the full interview
@st-jn2gk
Can't freaking wait, this is going to be awesome.
@vitiok78