@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.
@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.
@KonradGM
Grug is smart. We should give Grug meat for his fire
@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.
@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).
@wcrb15
OMG how you described the college experience is basically my project at work right now. So many freaking sequence diagrams.
@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.
@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.
@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.
@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.
@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.
@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.
@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.
@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.
@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)
@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
@harleyspeedthrust4013
agree about the 1D programming thing that Prime is talking about and about academia. One of the first languages I picked up was Java, and Java is notorious for overcomplicating things. I thought I was writing "good code" because I was coming up with class/interface hierarchies where everything was private and generics were everywhere. I spent so much time writing code that didn't actually get me any closer to solving the problem because "I would need it later." I used to get burned out very quickly - it took me a while to learn that the best principle is KISS, not DRY or SOLID or even YAGNI. My code these days is pretty boring but it's boring for a reason, and if it isn't boring then it isn't boring for a reason. You can get a lot done when you write code that actually gets you closer to a working solution - who knew
@filiformis