@olafbaeyens8955
On of the things that baffles me every time, is when a project fails, has a lot of bugs, takes ling time to get it right in production then management think you did a great job because you managed to get such a hard project functional in production and fixed so many bugs. However if you create a project, that almost have no bugs, works on the fly almost instantly in production somehow you are regarded as not good because you took so long.
@Don_XII
Grug was my teacher. He is a very bright intelligent person. The best CS teacher anyone can have. Everything he taught us was based on reality. When he goes into unrealistic academic topics he gives his opinion but also listen to what the students say.
@KonradGM
Grug is smart. We should give Grug meat for his fire
@macaroni_italic
I think the allure of premature abstraction is that it gives you the (often completely false) impression that you're making solid, rational progress on solving a problem. When you abstract, you are by definition just spending more time dealing with a problem you've already solved, instead of moving on to stuff that's harder, and therefore less likely to result in an immediate dopamine rush. By prematurely abstracting, you trick yourself into thinking that you're being productive by slicing up shit you've already done and dropping it into The Right Places(TM).
@MuhammadSaied
I've noticed that some new devs tend to find the most complex solutions to the simplest problems. They just can't believe that writing code is easy. For me, after 8 years of work, the only thing I've learnt is that if my solution is complex then I'm most likely doing it the wrong.
@rafaelbordoni516
As Terry Davis once said, only fools admire complexity, wise men admire simplicity. You show something complex to someone and they go like "wow, this is so hard, this guy must be a genius!" that's because they don't understand what you're showing them.
@Gornius
I used to work with a Senior developer that demanded to abstract almost everything we do, as so we did. Yeah - the code was clean, but unless you knew the codebase it was not very readable, and there were like 3 or 4 times, where a feature we were implemented required either: - F**k the architecture we've just made and do it the grug way - Refactor half of the codebase so we it would be possible to implement the feature. And the abstractions we used came in handy like 3-4% of the times, and even then it didn't save much time or made the code more readable. The lesson I took from that project: unless you're making a framework DO NOT make abstractions unless you see yourself repeating like 3 or more times.
@mfpears
The right time to create an abstraction is when you have a perfect name for it. If you can replace some logic with a name that perfectly represents that logic, code quality increases.
@nefrace
The best way to avoid complexity is not to hire Tom. But he's a genius so you need him.
@TanigaDanae
Currently I am reading "A Philosophy of Software Design" by John Ousterhout. It tries to explain (probably to the DIN EN school educated OOP programmer) that reducing or hiding complexity is one key role as a programmer. And it highlights that many small classes are not a sign of good abstraction.
@AScribblingTurtle
Kind of relatable. Complexity for complexity's sake is bad. The Tom of our company liked Laravel so much but was not allowed to move the project to it, ( because of its size and age). So what did he do? He ended up introducing a lot of half-backed classes and functions, that try to mimic Laravel's ways of doing things (badly I might add). Even 4 years later we still have to clean up his mess and accidentally break things in the system just by changing stuff in a completely different part of it.
@astrosloth2
refactoring code fun, refactoring database devil. grug not touch 100TB table, grug accept bad table & grug curse smol brain programmer who made table (mostly grug himself)
@danielvaughn4551
I like to think of code like a 1-800 number. You call your insurance company or whatever, go through like 5 different option prompts, then finally get to talk to a person. Then they say "oh for that you need to talk to [x], let me transfer you". Then the next person transfers you, and the next person. Everyone can remember a time when something like this happened, and it's hilariously frustrating. Each time you abstract your code, it's like adding an option prompt or a redirect to a 1-800 call center. You gotta jump through more and more hoops to "get to the thing you want". In other words, the cost of abstraction is that it's a layer of indirection, and the more you add, the more complex your code becomes. DRY is overrated.
@dolaudz3285
As with any posted video, I read through the comments, as I always do. If there's one thing I feel changed us forever as a community of this channel, is how much Tom is revered and regarded since he came into our lives. I have no doubt that in 5 years we will still praise him as our lord and savior. What a legend.
@wolfgangsanyer3544
I've noticed for some folks, it seems like they enjoy complexity because it helps them feel more legit. Maybe it's a imposter syndrome thing. At the end of the day though, your software will naturally get more complex on its own if it needs to. So the advice here is just super spot on. The more you focus on keeping things simple, the more you'll find yourself doing complex fun things and actually enjoying it.
@fille.imgnry
After 20 years of fiddling little keys with my fingers, I feel the same. I started off trying to abstract all the things, and not I am pretty much the opposite as much as possible. I even rather keep copies of code as it is so common any way that I will come back and need to change one of the parts. 👍🏻
@wcrb15
OMG how you described the college experience is basically my project at work right now. So many freaking sequence diagrams.
@raenastra
I got so much better about this doing CTFs for cybersec courses in my master's. In a CTF, you usually write enough code as needed to experiment, change things quickly, and solve the problem. Often hardcoding values is the best way to do this - the more abstractions you add, the slower your feedback loop is. The focus is on solving a very specific problem, rather than clean code, because you never look at the script once you have the flag anyways
@piotrjaga6929
About 6 months ago i did 'clean code' approach and i tried to abstract almost everything, every swich or if else statement had to be abstracted with polymorphism, every function that has more than 20 lines had to be shortened even if that didnt make sense and of course before diving deeper in this topic i thought this is brilliant. I learned the lesson and now i am better programmer.
@filiformis