My biggest takeaway as a junior developer who is getting into real stuff. You dont have to solve every problem by creating a new abstraction, because not every problem is worth solving. - ThePrimeagen I love this. Thanks
Also for all level of engineers. If you are not clear about the domain of a specific functions. Copy & Paste that function for your own usage with modification and clear out all the unrelated stuff is totally fine, it doesn't violate the DRY principle. Don't try to reuse everything, please. I have a hard hard hard time to watch people are arguing about DRY and Copy&Paste
It's easier to write 5 lines of code 3 times than to write 50 lines of code to abstract those 5 lines and then share those 50 as a dependency in 3 projects that has to be maintained and documented for 20 years
An experienced co-worker used to say: "you write it, you own it" and "Who's going to own it?". He would say this whenever someone would suggest a new tool or wrapper.
Yes! Someone built a cheat sheet thing for... mostly another team. I haven't used it. I'm not sure who has used it and I'm not sure who has kept the info in there updated, if they ever did. He's no longer with the company, so now it's with another team who is just maintaining it.
@@aoeu256 At different points they may have been, but I know some of their advantages have since been integrated into git. I don't know how they compare today.
That's why the best programmers are lazy by default. We spend the extra effort to make a routine atomic, so we can make it into a module. That way we can just pull it in instead of having to write the whole darn thing again.
I have learned that WET = Write Everything Twice; The heuristic being that you need at least three instances in order for an abstraction to be merited. It's not a perfect heuristic, but it's worth to keep in mind.
The even more funny thing: The guy who committed the change is a software engineer at Google and later admitted he actually did not understand what the function does or why it is important in detail.
Thats not some random engineer at Google, he is one of the oldest kernel developers, a very known guy (speaks at conferences, part of Linux advisories boards, etc), and did most of the work for ftrace framework (IIRC). Which makes this thing kind of funny and awkward.
Steven is not some random Google engineer. By Steven's own words; "tl;dr; Google had very little to do with the email thread. I didn't copy a function that I didn't understand but it was overkill for my use case which is why Linus said I didn't understand it. Linus was having a bad week when a bug report came in on my code." There's a longer comment on TheRegister explaining everything from his start as a kernel developer, building file systems, to the issue at hand and a more in-depth explanation of what happened.
I like how polite and thoughtful Linus is there when he writes "*' in place of the "u". Anyway, I'd start using copilot if they upload a Linus agent, I need that.
I agree, so much. Fighting this every day. I especially love it when teams create wrappers around APIs from other teams (not external, just another department), because, you know, maybe we want to change it at some point in the future. The more extreme version is the wrapper service, whose only purpose to map objects from a naming convention someone else invented to hour own naming convention. Add the microservices paradigms into the mix and you end up with a codebase that is 50% just wrapping and mapping.
As math grad, I think we have something similar to SWE’s obsession with abstraction, which is obsession with rigor, as described by Terry Tao’s article “There’s more to mathematics than rigour and proofs”.
The Swedes knew what they were talking about when they coined the term "Management by Perkele" to describe Finnish managers 😄 I suppose Linus managed to find just about the only niche where that style KINDA works. Anywhere else it's only harmful to everyone involved 😅
@@topiuusi-seppa5277 thats completely untrue. this works everywhere, you people are just soft and trained to speak 90% lies and obfuscation. linus is pure honesty. and honesty is the only thing that works long term.
This is something that happens all of the time at work for me too, where I continuously question "why did we make this so complicated" and the XY problem constantly comes up and haunts us! Definitely going to check your other videos on that. Ugh, with all rules in webdev - the rules like "DRY" are always "as needed" because you will inevitably end up over abstracting (or abstracting too early). Thanks for talking about the damage and impact this has had overall on a higher level!
Random fact: I bought a car at an estate sale from Linus’s neighbor once. The only reason I knew it was his house is because he used to drive this obnoxious yellow Mercedes with ‘LINUX’ on the license plate, and I saw it nearby. Also, we were friends in Google+, and I feel like that should count for something.
A LOT of things in civilization only work because of the people who built them, or at least people who continued to have the same or similar standards of behavior, competence etc as those that did. Once that all goes away, everything falls apart. Tbh, as critical as Linux is, it looks like just the tip of the iceberg, or but one example case, atm.
I am newish to software development but I have been in Tech for just shy of a decade. The issue I see a lot when people copy something they don't understand or they repeat certain patterns that are not optimal is time. A lot of people are afraid to take that extra step to learn the "Why's" of something because they may not "Feel" like they have the time to do so on a project, in a corporate setting. You should never have this issue on your own projects at home, take the time to learn! I am certainly guilty of this and I trying to get better with each new problem/project because I have found this to only hurt me in the long run.
I literally went from trying to program games in java for a month or two to programming in C++ and trying to program game engines to then finding a game about making a turing complete computer and doing so to programming in Rust some other higher level things than that to finally what I am working on more actively right now which is learning about how operating systems work and trying to make one written completely in Rust without having to use assembly, I already know how annoying assembly is to program with because of the game previously mentioned and for the life of me I can't remember the conventions people have come up with for their version of assembly at best I know the most basic types of assembly work being just a find and replace with binary data that directly controls the hardware. What I mean to say with this is I found some very interesting things out by just trying to understand what code I was writing and how things worked.
Great things, every dev should read the XY problem every day until engrave this in mind! Linus say it a lot of true things that many times people don't want to hear these days!
I think DRY is good if you apply KISS before. So primarily make things simple and as a way to do that, try and don't repeat yourself. In my current job, I made a task to abstract a "age of data checking" to a specific new class. It is so people don''t repeat themselfs, but much more about making it so if this fails, there is only one single point of failure. In the same project, we also have many linked lists (imposed by third party tool) and even if I could very well do something to make it less repetitive to handle, I didn't because it has no big added value, devs can just write a for loop for themselfs.
Part of keeping it simple, for me, is repeating myself until I know more definitively if it was actually repetitive. All too often you assume something is the same as something else, and then you get further into the problem and you were either wrong or the circumstances have changed. It's often easy to combine things that turn out to overlap in the future if they truly do, but it's a pain starting and continuing to retrofit DRY early on regardless of the situation.
Also, something I've seen happen too much is making something a function because it's used two or three times. This is fine as long as the same intent is behind the code. Sometimes the same code is used for different things and as such will change for different reasons. That is the biggest caveat I apply to DRY
@SanderDecleer of course different code will use slightly different functions. That’s why function arguments accept VARIABLES. Lol. They VARY. Doesn’t mean there needs to be a separate goddamn function for every single variation.
@@SanderDecleer as long as you write same code twice, its really bad, cose as soon as he need to be updated (and he will needs in general), you have to check every f**** spot where that code was duplicated to update those part too ... but feel free to copy paste same code if you want, as long as i dont work on it i dont really care x')
@@grimpowsify In most cases I agree. But there are cases where two different concepts use the exact same code. When these concepts use the same method you might accidentally change more than you want while reworking that bit of code. That is why, for me in specific cases, I don't care two methods have the same nody. Copy pasting entire chunks of logic to do the exact same thing over and over again is an entirely different thing.
That was anything but mature from Linus lol. He ranted in his face for several paragraphs. He could have shut him down in 10 sentences tops and still done it via direct confrontation. Basically Linus went beyond shutting him down and bullied/intimidated him, as you can see from the other person's meek reply that Prime skipped over. Classic Linus, still toxic.
@@Blaisem Read the whole thread, not what prime is just reacting to, understand the genesis of that conversation and you'll see why I came to that conclusion. Open source projects are hectic and repeated pull requests can be annoying, especially if they have the same issues re-occurring .
1:00 - The biggest problem with complexity is that it creates problems at an exponential rate. I see this all the time at work, and it frankly drives me insane some days and completely deflates my will to contribute, because I know that I'm putting my stone in a cathedral of edge cases, gotchas, and 24-hr support SLA's that mean I'm going to have to twiddle my thumbs for two whole days before I get unblocked.
8:00 Frankly, I don't get the obsession with DRY. If the code is readable and performant, then who cares if there's a bit of repetition? For smaller projects especially I think it can be taken too far to the point where future humans will be unable to quickly understand what past humans had built due to all the abstraction layers...
@@halcyonramirez6469 Yabut they can take it too far though. JS hyper-abstractions are a great example. Personally sometimes I find what you gain in elegance you often lose in future humans being unable to understand what the code is trying to do...
@@HansBezemer I'm in operations. My world is not the same as yours. I'm not developing the Linux kernel where everything needs to be cleaned with chlorine pentafluoride before the PR gets approved.
@@lashlarue7924 Read my lips. Develop good programming practices. Because you can fall back on them when you need them. If you develop bad practices, you won't be able to shrug them off when you don't need them.
You cannot make a problem simpler than it actually is. I feel like that people often try to abstract to make the problem simpler, but actually it almost always makes the problem more complicated. And even if that's just because now there is more code/tools/etc. to understand. Also: People should just stop inventing problems they don't actually have.
Hii prime, just wanna say after i started watching you, i started to learn my environment. No im proud to say, im a neovim user, with all config i wrote from scratch after learning your video. Thanks so much man, you are like one of my idols ik programming world. Kinda crazy, but also crazy genius and passionate about programming. Btw, im from malaysia, small country in south east asia. Soo, ❤ from malaysia primeagen !!
If I don’t solve tomorrow’s problems today, in a sense I’m the root cause of all problems that might not have needed to be problems if I’d problem-solved ahead of time…
The way you deal with that is documenting the known limitations and possible future problems ahead of time so fixing them can make it onto the roadmap before they become problems. It doesn't work for everything (e.g. software running off your premises or when software and hardware are tightly coupled), but often it does.
The problem is, you don't know, actually know, what tomorrow's problems are going to be. And there's rarely a shortage of "today's problems" to deal with first.
@@VojtěchJavoraso what you're saying is we should get CPU prediction architects to use their powers as a team leader instead of a CPU architect... Interesting.
Being abusive to coworkers isn't cool no matter what's on your scoreboard. Making life difficult for other people for your amusement or because you're an adult who can't control their behaviour is a failure of you. People in general should try to route this behaviour out because I bet it's a big net negative for overall productivity and happiness. Real "10x" developer vibes from Linus on this one. We have too much technology and too many problems to be artificially be adding problems to other people's lives. Hiding bullying behind criticism is a weak excuse. You can criticize accurately and effectively without abuse. Being laid out so publicly and rudely is 100% a crushing experience for whoever this is aimed at.
I would really appreciate it if Prime actually dove into the problem, not just sided with Linus, but formed his own opinion based on the problem space.
I wrote that docker tool, but in my defense we use a container registry that is not friendly with plain ole docker. We also have multiple environments and each environment has its own registry. I also had devs building containers from development git branches without realizing it. So the tool ensures you're building from the main branch, it tags everything for you, uploads to all of the different registries asynchronously to reduce wait times, it runs all tests prior to build and fails when tests fail, and it cleans up the registries now and then. Running the tool is a single command. I get what you're saying Prime but sometimes a wrapper is okay.
8:20 - JavaScript does not have operator overloading... imagine JavaScript getting a global operator overload feature where any library you use can change the meaning of the +-operator at any time. :D:D:D:D
Except for the fact that Linus himself solved non existing problem back in early 90' when he sat down and created linux. Not solving nonexistent problems is a good rule in mature projects that many people relay on. But It also kills innovation.
I suffered the consequences of striving to keep my code too DRY, to the point where it no longer made sense. The result was a need to refactor the code and learn that some repetition isn't inherently as bad as I initially thought.
I once was trying to debug a web site that used an AJAX call that returned a JSON object, which contained several strings of JavaScript, HTML, and XML, which sometimes had further layers to debug within those strings,including calling a similarly packed AJAX function once unpacked and executed. All of these strings came from a database BTW. I was fired from that job because I wasn't productive enough.
I genuinely fucking hate the "XY problem" because, no, sometimes you just need to do that thing, and now every single post anywhere online about doing that niche thing is just "do this entirely different thing that doesn't actually do what you asked" "Thanks, that solved it" and no-one who actually needs to do that niche thing can find out how. I'd rather the guy who can't be bothered to research a good solution deal with a suboptimal one then everyone who *_does_* know what they're doing be unable to actually do it because we tried to protect that one stupid person from themselves. If push comes to shove, just say "well, I think you're trying to do this, in which case go link>>> here
MBA's are obsessed with the fantasy of JS-only companies, thinking that it will solve their recruiting problems while ignoring the complexity that writing JS exclusively brings. A company I worked for was acquired by a PE firm and they pushed us really hard to rewrite our 10yr old app in Node so that it would be easier to hire devs.
This is so retarded. Just because the language is the same doesn't mean the libraries and API' are, let alone the design patterns. I thought we learned this lesson with Classic ASP and VBScript / JScript
I needed this video. I have a couple of projects now, where a customer wanted to 1) upload an Excel file 2) see the list the program makes of it and 3) runs whatever needs to be run. I basically copied my class from the first of such projects for all of them, making minor improvements. For this project of that sort, I wanted to abstract it somehow. This would undoubtably have taken a lot of time I don't have (because other big project going live soon). It would be a fake problem I guess, because copying a class takes almost no time and I can start working on what needs to be done for that particular use case. The level of abstraction needed would have been a nightmare, and the worst part is: I was seriously contemplating it for a while now. So ... thanks.
Real talk, I've been denying pull requests lately because devs were writing crazy complicated code for doing the simplest things. Often the abstractions required a lot more code (sometimes 3 times the amount) as compared with writing the code straight up. No... You do not need to make an array of objects and loop over them for everything, especially to save repeating 2 lines of almost identical code right next to each other. No... You don't need to create 3 layers of abstractions spread all over the file and code base to write that test, just write the dang test assertion in 1 line! Seriously I've deleted thousands of lines of code like this recently because of the craziness. I'd rather update a handful of lines of code by hand than learn whatever crazy abstraction you wanna invent on the fly.
7:58 the thing I always didnt understand about DRY is how are people pulling that off. like are they like endlessly just refactoring code and not finishing anything.
There is "premature optimization" but there really should be "premature abstraction" too. Just because it is possible to wrap it in N layers of abstractions and indirections doesn't mean we should do that and think it is "maintainable" or "clean" or "DRY" or what ever unmeasured metric a large portion of devs are saying in a kneejerk defensive tone like they are kids caught red-handed with their hands in the cookie-jar. It reminds me of a blog series by Casey Muratori called "Semantic Compression", it is maybe a bit much text to review on stream but none the less pure gold.
And Docker is just a wrapper around containerd and containerd is just a wrapper around linux namespaces and linux namespaces... yknow what, let's just write the OS from scratch
I will solve problems which do not exist. I will use code I do not understand. I will over-complicate things. I will fail upwards while everyone else fails downwards. I will become a -10x engineer.
Totally agree with this. In fact replace the word “tool” with “abstraction”. There are way too many abstractions that try to hide complexity but just add to the pile of stuff to learn.
Linus may not be the nicest person in the world, but he certainly is one of the most important people in the world. He not only is a great developer, he also has basically the whole internet in his hands. Many network equipment parts (from fiber-to-wire-converters to the very servers that run the internet) run Linux or something based on Linux. Almost 100% of the web runs on Linux. And even 3.x% of desktop computers run Linux.
Meh. It's not as important as you think it is. If it wasn't him it would have been someone else. It's just an offensive job that few--if any--sane people would actually want to do, so they let this little goblin do it.
@@youtubesuresuckscock But because _he_ took that role _he_ is basically the most important person in the world. It's not because it's him, it's because he created and maintains Linux.
@@Lampe2020 That's not my definition of most important. If he had never been born, things would have more or less played out the same way. The most important people had a significant impact. At the end of the day, no operating system really matters much.
As someone uninitiated, I don't understand how a _get_next_ino()_ call (sounds like a application-specific UID generator) can help achieve something that could otherwise be achieved with a _atomic 64_add return()_ call (sound like a very general arithmetic operation). What did the perpetrator hope, how could that function solve his/her problem? Apart from being ugly/unprofessional/etc., was there any chance that those were interchangable in the first place? O_o
The "you copied the function without knowing why t works" is almost never true for me, although I still have to wrap my head around how _exactly_ the async function delay(ms) on my website (copied from SO) waits for the specified amount of milliseconds. Okay, I now (more than two years after adding it) finally understand how it works, it creates a promise that waits for a timeout to run out. Pretty clever!
At the bank where I did two freelance projects the last 5 years me and another freelance colleague always yelled: "STOP! What problem are we solving?" We are running BAU, so we know what the problems are that plague us, those we solve... Others that don't create business value, we flush! And the irony is that those devs who found the edge of the edge of the edge case, didn't even bother to check if a file open actually returned a valid FD. When the create an object that it actually isn't null when they ingest data from a source didn't bother to run the conformation and consistency checks -- two classes that actually bring value for data consitency.
This is my first time seeing anything from Linus firsthand. I'm no expert by any means but I'm not going to lie; Sure he could have said that in a nicer way, but I agree with him on principle. I've often gotten flak for taking time to analyze the code that I'm supposed to just blindly import only to later fix a "crisis" with ease because I knew a bit about how the damn thing worked.
Yeah, I don’t know if Prime has read old mailing list stuff but it has changed. He used to have more personal attacks on the dev rather than the code is garbage. He infamously said that someone should be retroactively aborted and were probably too stupid to find a teet to suck on.
I'm not really in the computer coding community. When I build my own code, if i include a function, i do learn/understand it's structure. I guess that's why I'm slow/not good at it.
OMG! This speaks to me so viscerally! I mean, sometimes you want a "wrapper" (usually scripts) to help people not make mistakes. Especially if it saves time from a daily set of tasks. But I agree 200%... sometimes companies build in-house things to do things in the way THEY do things and then they don't train the newbies or even have good up-to-date documentation. Preach, brother!
Linus keeps a tight ship and he's not shy about flaming out the code noob tourist trying to submit scrapcode just to brag he/she did kernel development.
The abstraction away from the actual tech (while the underlying tech stays the same) is something that cloud providers are notorious for. For example "hey you should come use our custom web gui routing system (nginx)" or "hey you should use our container apps with 90% of the features stripped and basic scale to 0 serverless orchestration (kube)"
People are saying Linus is back to his self. No, younger Linus was much much worse. Young Linus would have said "Your code is garbage, and so are you " vs older Linus says "Your code is garbage, get better or I'm going to ignore you".
Call me a snowflake, but if I'd get such a code review I'd quit. A simple "Hey, this abstraction might be unnecessary. Please remove it or explain why it's needed" would have sufficed.
Developers need to have meetings like AA, where they have to stand up and introduce themselves, and admit their code is crap. Honestly, things would advance, if people were open to criticism, and improve their code, rather then thinking they are so far above everyone else, and refuse to budge.
There's a one-two combo I really hate when asking for help online: The X-Y Problem and tl;dr. If I'm going to ask a question, I've often already had to look at alternatives and know about them. Now if I make my question very concise, I get asked why I'm doing X instead of Y. If I show my receipts to explain the entire situation, then it's too long and gets ignored. There's some middle ground in there that's pretty hard to hit, and it's kind of a moving target too.
For all of those asking "Why is hair blue?"
I LOST A BET AND I AM A MAN OF MY WORD NO MATTER HOW STUPID I FEEL
way worse if it were green
thats a man of integrity
But what would you have gotten if you won?
It works, keep it :D
Respect
biblically accurate rust dev
underrated comment bhahaha
🤣
What would Linus do? WWLD?
hahaha, gottem good
Programmers are also humans, has a video on Sr. rust dev.
the dev also has blue hair.🤣🤣
ruclips.net/video/TGfQu0bQTKc/видео.html
Nice senior rust dev hair
🤣🤣🤣
can't be one. He's not in a fur suit
It's part of the new Netflix uniform requirements
@@_Lumiere_Either that or he has to personally go to Skid Row and greenlight a series pitched by a homeless drug addict.
😂😂😂😂😂
That hair, telltale sign of entering the next phase of his furry arc
Arc
Trying so hard to pretend that he is not DrDisrespect
@@CallMeMSL Arc
I find it really jarring for some reason. I can't look at it too long, or I find it disturbing.
@@yeetdeetsit is, maybe its just the autism speaking xD
My biggest takeaway as a junior developer who is getting into real stuff.
You dont have to solve every problem by creating a new abstraction, because not every problem is worth solving. - ThePrimeagen
I love this. Thanks
Also for all level of engineers. If you are not clear about the domain of a specific functions. Copy & Paste that function for your own usage with modification and clear out all the unrelated stuff is totally fine, it doesn't violate the DRY principle. Don't try to reuse everything, please.
I have a hard hard hard time to watch people are arguing about DRY and Copy&Paste
Yeah, i have stopped myself a many times.... but a reminder is always helpful
YAGNI! You ain't gonna need it :-)
Software developers like to be clever. Once your cleverness gets you in trouble a few times you'll learn to prioritize simplicity and maintainability.
It's easier to write 5 lines of code 3 times than to write 50 lines of code to abstract those 5 lines and then share those 50 as a dependency in 3 projects that has to be maintained and documented for 20 years
An experienced co-worker used to say: "you write it, you own it" and "Who's going to own it?". He would say this whenever someone would suggest a new tool or wrapper.
Yes! Someone built a cheat sheet thing for... mostly another team. I haven't used it. I'm not sure who has used it and I'm not sure who has kept the info in there updated, if they ever did.
He's no longer with the company, so now it's with another team who is just maintaining it.
Then the communist co-worker says "i don't believe in private property" 😂
And then the person who wrote/owns it leaves the company
@@SXZ-dev "WE own it, damnit!!"
therapist: Blue hair primeagen doesn't exist
blue hair primeagen:
Rust may make iron red but it makes programmers blue.
He was like "hold my beer"
primeagen isn't being treated by a therapist.
the therapist is being treated by primaeagean
@@private_account407 thats not how this meme works but ok
Linus' two areas of proficiency are kernel development, and delivery of what TVTropes defines as the "The Reason You Suck speech."
The two requirements for a BDFL.
God bless Linus.
Also made git
@@Blaisem Git is hmm... kinda... messed up though, we use git because everyone else does. Where mercurial and whatever really worse?
@@aoeu256 At different points they may have been, but I know some of their advantages have since been integrated into git. I don't know how they compare today.
I can assure you my 20+ files of extensive boilerplate designed to track div toggle events are not garbage.
i just wouldn't understand engineering (real engineering)
The opposite of DRY (don't repeat yourself) is WET (we enjoy typing) :D
This is why it's bad to have too nice a keyboard
That's why the best programmers are lazy by default. We spend the extra effort to make a routine atomic, so we can make it into a module. That way we can just pull it in instead of having to write the whole darn thing again.
I have learned that WET = Write Everything Twice; The heuristic being that you need at least three instances in order for an abstraction to be merited. It's not a perfect heuristic, but it's worth to keep in mind.
Well said.
prime is about to start wearing thigh highs, and run arch
on his way to buy programming socks, software development is an equipment sport
The even more funny thing:
The guy who committed the change is a software engineer at Google and later admitted he actually did not understand what the function does or why it is important in detail.
All in all, he f**ked up in the best way possible
Thats not some random engineer at Google, he is one of the oldest kernel developers, a very known guy (speaks at conferences, part of Linux advisories boards, etc), and did most of the work for ftrace framework (IIRC). Which makes this thing kind of funny and awkward.
Steven is not some random Google engineer.
By Steven's own words; "tl;dr; Google had very little to do with the email thread. I didn't copy a function that I didn't understand but it was overkill for my use case which is why Linus said I didn't understand it. Linus was having a bad week when a bug report came in on my code."
There's a longer comment on TheRegister explaining everything from his start as a kernel developer, building file systems, to the issue at hand and a more in-depth explanation of what happened.
Why lie?
@@deallocWeird to take Steven's words at face value while not taking Linus's
"I have a video where I read an article about it"....peak reactor
A prime reactor, even
@@joestevenson5568prime reactor can not be even unless it's a 2
@@papsanlysenko5232A prime reactor, odd
@@joestevenson5568 nuclear reactor
speaking of wrappers huh
I like how polite and thoughtful Linus is there when he writes "*' in place of the "u". Anyway, I'd start using copilot if they upload a Linus agent, I need that.
Don't let your memes be dreams. Train your own language model on aggro Linus emails.
@@3lH4ck3rC0mf0r7 fuck. we need to do this.. lets make this a project.
>wrap an already well known tool with their own tool because it helps shorcut some basic common usages
i do that all the time, it's called a Makefile
Cmake 🤣
@@freasses ffs no. literally the definition of overcomplicating things
@@samuelwaller4924 it depends what kind of tool.
I agree, so much. Fighting this every day. I especially love it when teams create wrappers around APIs from other teams (not external, just another department), because, you know, maybe we want to change it at some point in the future.
The more extreme version is the wrapper service, whose only purpose to map objects from a naming convention someone else invented to hour own naming convention.
Add the microservices paradigms into the mix and you end up with a codebase that is 50% just wrapping and mapping.
A significant portion of all computing is just generating and parsing json
@@oblivion_2852 That is trully horrifying. Probably in the same order of magnitude of power usage compared to crypto mining
As math grad, I think we have something similar to SWE’s obsession with abstraction, which is obsession with rigor, as described by Terry Tao’s article “There’s more to mathematics than rigour and proofs”.
Why is his mustache dyed brown?
Most calm Finnish person…
*Perkele*
Finland mentioned, torilla tavataan!
The Swedes knew what they were talking about when they coined the term "Management by Perkele" to describe Finnish managers 😄 I suppose Linus managed to find just about the only niche where that style KINDA works. Anywhere else it's only harmful to everyone involved 😅
@@topiuusi-seppa5277 thats completely untrue.
this works everywhere, you people are just soft and trained to speak 90% lies and obfuscation.
linus is pure honesty. and honesty is the only thing that works long term.
This is something that happens all of the time at work for me too, where I continuously question "why did we make this so complicated" and the XY problem constantly comes up and haunts us! Definitely going to check your other videos on that.
Ugh, with all rules in webdev - the rules like "DRY" are always "as needed" because you will inevitably end up over abstracting (or abstracting too early). Thanks for talking about the damage and impact this has had overall on a higher level!
I'm worried what's gonna happen to the Kernel once Linus (fully)retires...
I hope he finds someone just like him
greg is there lol
Looking at the Linux community today, once Linus retires, the whole thing is doomed ...
Random fact: I bought a car at an estate sale from Linus’s neighbor once. The only reason I knew it was his house is because he used to drive this obnoxious yellow Mercedes with ‘LINUX’ on the license plate, and I saw it nearby.
Also, we were friends in Google+, and I feel like that should count for something.
A LOT of things in civilization only work because of the people who built them, or at least people who continued to have the same or similar standards of behavior, competence etc as those that did. Once that all goes away, everything falls apart.
Tbh, as critical as Linux is, it looks like just the tip of the iceberg, or but one example case, atm.
I am newish to software development but I have been in Tech for just shy of a decade. The issue I see a lot when people copy something they don't understand or they repeat certain patterns that are not optimal is time. A lot of people are afraid to take that extra step to learn the "Why's" of something because they may not "Feel" like they have the time to do so on a project, in a corporate setting. You should never have this issue on your own projects at home, take the time to learn!
I am certainly guilty of this and I trying to get better with each new problem/project because I have found this to only hurt me in the long run.
I literally went from trying to program games in java for a month or two to programming in C++ and trying to program game engines to then finding a game about making a turing complete computer and doing so to programming in Rust some other higher level things than that to finally what I am working on more actively right now which is learning about how operating systems work and trying to make one written completely in Rust without having to use assembly, I already know how annoying assembly is to program with because of the game previously mentioned and for the life of me I can't remember the conventions people have come up with for their version of assembly at best I know the most basic types of assembly work being just a find and replace with binary data that directly controls the hardware. What I mean to say with this is I found some very interesting things out by just trying to understand what code I was writing and how things worked.
he's delving deeper into rust...
Great things, every dev should read the XY problem every day until engrave this in mind! Linus say it a lot of true things that many times people don't want to hear these days!
I think DRY is good if you apply KISS before. So primarily make things simple and as a way to do that, try and don't repeat yourself.
In my current job, I made a task to abstract a "age of data checking" to a specific new class. It is so people don''t repeat themselfs, but much more about making it so if this fails, there is only one single point of failure. In the same project, we also have many linked lists (imposed by third party tool) and even if I could very well do something to make it less repetitive to handle, I didn't because it has no big added value, devs can just write a for loop for themselfs.
Part of keeping it simple, for me, is repeating myself until I know more definitively if it was actually repetitive. All too often you assume something is the same as something else, and then you get further into the problem and you were either wrong or the circumstances have changed. It's often easy to combine things that turn out to overlap in the future if they truly do, but it's a pain starting and continuing to retrofit DRY early on regardless of the situation.
Also, something I've seen happen too much is making something a function because it's used two or three times. This is fine as long as the same intent is behind the code. Sometimes the same code is used for different things and as such will change for different reasons.
That is the biggest caveat I apply to DRY
@SanderDecleer of course different code will use slightly different functions. That’s why function arguments accept VARIABLES. Lol. They VARY. Doesn’t mean there needs to be a separate goddamn function for every single variation.
@@SanderDecleer as long as you write same code twice, its really bad, cose as soon as he need to be updated (and he will needs in general), you have to check every f**** spot where that code was duplicated to update those part too ...
but feel free to copy paste same code if you want, as long as i dont work on it i dont really care x')
@@grimpowsify In most cases I agree. But there are cases where two different concepts use the exact same code. When these concepts use the same method you might accidentally change more than you want while reworking that bit of code.
That is why, for me in specific cases, I don't care two methods have the same nody.
Copy pasting entire chunks of logic to do the exact same thing over and over again is an entirely different thing.
It was an interesting thread to read, I appreciate the direct confrontation. There's a lot of maturity in this project.
That was anything but mature from Linus lol. He ranted in his face for several paragraphs. He could have shut him down in 10 sentences tops and still done it via direct confrontation. Basically Linus went beyond shutting him down and bullied/intimidated him, as you can see from the other person's meek reply that Prime skipped over. Classic Linus, still toxic.
@@Blaisem Read the whole thread, not what prime is just reacting to, understand the genesis of that conversation and you'll see why I came to that conclusion. Open source projects are hectic and repeated pull requests can be annoying, especially if they have the same issues re-occurring .
1:00 - The biggest problem with complexity is that it creates problems at an exponential rate. I see this all the time at work, and it frankly drives me insane some days and completely deflates my will to contribute, because I know that I'm putting my stone in a cathedral of edge cases, gotchas, and 24-hr support SLA's that mean I'm going to have to twiddle my thumbs for two whole days before I get unblocked.
8:00 Frankly, I don't get the obsession with DRY. If the code is readable and performant, then who cares if there's a bit of repetition? For smaller projects especially I think it can be taken too far to the point where future humans will be unable to quickly understand what past humans had built due to all the abstraction layers...
Because it's a fundamental principle.
11 times out of 10.
breaking dry is just being g lazy.
Why write twice when you can do it once?
@@halcyonramirez6469 Yabut they can take it too far though. JS hyper-abstractions are a great example. Personally sometimes I find what you gain in elegance you often lose in future humans being unable to understand what the code is trying to do...
If you don't get it, I'd consider a different career path.
@@HansBezemer I'm in operations. My world is not the same as yours. I'm not developing the Linux kernel where everything needs to be cleaned with chlorine pentafluoride before the PR gets approved.
@@lashlarue7924 Read my lips. Develop good programming practices. Because you can fall back on them when you need them.
If you develop bad practices, you won't be able to shrug them off when you don't need them.
PREACH!! I had a boss who literally told me that he would never approve duplicated code in reviews because DRY was the only way to write code
The x-y problem is basically what librarian training is based on, learning how to unpack what the person is actually asking.
You cannot make a problem simpler than it actually is. I feel like that people often try to abstract to make the problem simpler, but actually it almost always makes the problem more complicated. And even if that's just because now there is more code/tools/etc. to understand.
Also: People should just stop inventing problems they don't actually have.
Hii prime, just wanna say after i started watching you, i started to learn my environment. No im proud to say, im a neovim user, with all config i wrote from scratch after learning your video. Thanks so much man, you are like one of my idols ik programming world.
Kinda crazy, but also crazy genius and passionate about programming. Btw, im from malaysia, small country in south east asia. Soo, ❤ from malaysia primeagen !!
If I don’t solve tomorrow’s problems today, in a sense I’m the root cause of all problems that might not have needed to be problems if I’d problem-solved ahead of time…
Sure, but in a way it's like branch prediction. If you are bad at guessing what tomorrow's problems are, you are just making it worse.
The way you deal with that is documenting the known limitations and possible future problems ahead of time so fixing them can make it onto the roadmap before they become problems. It doesn't work for everything (e.g. software running off your premises or when software and hardware are tightly coupled), but often it does.
The problem is, you don't know, actually know, what tomorrow's problems are going to be. And there's rarely a shortage of "today's problems" to deal with first.
@@VojtěchJavoraso what you're saying is we should get CPU prediction architects to use their powers as a team leader instead of a CPU architect... Interesting.
How come problems exist tomorrow?
Being abusive to coworkers isn't cool no matter what's on your scoreboard.
Making life difficult for other people for your amusement or because you're an adult who can't control their behaviour is a failure of you.
People in general should try to route this behaviour out because I bet it's a big net negative for overall productivity and happiness. Real "10x" developer vibes from Linus on this one.
We have too much technology and too many problems to be artificially be adding problems to other people's lives. Hiding bullying behind criticism is a weak excuse. You can criticize accurately and effectively without abuse.
Being laid out so publicly and rudely is 100% a crushing experience for whoever this is aimed at.
I would really appreciate it if Prime actually dove into the problem, not just sided with Linus, but formed his own opinion based on the problem space.
Such good continued exposure for the X/Y Problem. Well done!
I want to hear more on this "don't take DRY too far" rant. The perfect abstraction can be amazing when it works, but so elusive sometimes.
I wrote that docker tool, but in my defense we use a container registry that is not friendly with plain ole docker. We also have multiple environments and each environment has its own registry. I also had devs building containers from development git branches without realizing it. So the tool ensures you're building from the main branch, it tags everything for you, uploads to all of the different registries asynchronously to reduce wait times, it runs all tests prior to build and fails when tests fail, and it cleans up the registries now and then. Running the tool is a single command. I get what you're saying Prime but sometimes a wrapper is okay.
8:20 - JavaScript does not have operator overloading... imagine JavaScript getting a global operator overload feature where any library you use can change the meaning of the +-operator at any time. :D:D:D:D
Now we want this, someone should do it
Except for the fact that Linus himself solved non existing problem back in early 90' when he sat down and created linux.
Not solving nonexistent problems is a good rule in mature projects that many people relay on. But It also kills innovation.
I suffered the consequences of striving to keep my code too DRY, to the point where it no longer made sense. The result was a need to refactor the code and learn that some repetition isn't inherently as bad as I initially thought.
I once was trying to debug a web site that used an AJAX call that returned a JSON object, which contained several strings of JavaScript, HTML, and XML, which sometimes had further layers to debug within those strings,including calling a similarly packed AJAX function once unpacked and executed. All of these strings came from a database BTW. I was fired from that job because I wasn't productive enough.
Linus has magical ability to look across the problem towards the real issue and foresight to avoid technical debt as much as possible.
I genuinely fucking hate the "XY problem" because, no, sometimes you just need to do that thing, and now every single post anywhere online about doing that niche thing is just "do this entirely different thing that doesn't actually do what you asked" "Thanks, that solved it" and no-one who actually needs to do that niche thing can find out how. I'd rather the guy who can't be bothered to research a good solution deal with a suboptimal one then everyone who *_does_* know what they're doing be unable to actually do it because we tried to protect that one stupid person from themselves. If push comes to shove, just say "well, I think you're trying to do this, in which case go link>>> here
That video was way more to the point than I thought it would be. Very nice.
Bad engineers love complexity. Good engineers love simplicity.
Just as terry davis pointed out
Does anybody have a link to Prime's video about the XY problem?
I'd like to watch it, but I couldn't find it on either channel.
MBA's are obsessed with the fantasy of JS-only companies, thinking that it will solve their recruiting problems while ignoring the complexity that writing JS exclusively brings. A company I worked for was acquired by a PE firm and they pushed us really hard to rewrite our 10yr old app in Node so that it would be easier to hire devs.
This is so retarded. Just because the language is the same doesn't mean the libraries and API' are, let alone the design patterns. I thought we learned this lesson with Classic ASP and VBScript / JScript
At 5:28 he says he has a video on the XY problem, but I can't find it. Anyone knows what it's called?
I'm afraid of what Linux will become in the aftermath of the inevitable day when we lose Linus. :(
I needed this video. I have a couple of projects now, where a customer wanted to 1) upload an Excel file 2) see the list the program makes of it and 3) runs whatever needs to be run. I basically copied my class from the first of such projects for all of them, making minor improvements.
For this project of that sort, I wanted to abstract it somehow. This would undoubtably have taken a lot of time I don't have (because other big project going live soon). It would be a fake problem I guess, because copying a class takes almost no time and I can start working on what needs to be done for that particular use case. The level of abstraction needed would have been a nightmare, and the worst part is: I was seriously contemplating it for a while now.
So ... thanks.
lmao i just saw this yesterday and spent a good ten minutes reading the email chain between linus and steven
Just so I understand the video, a bad PR on the Linux kernel that's written in C is the result of junior javascript developers?
The lore friendly next step for him are the stripey programmer socks
Real talk, I've been denying pull requests lately because devs were writing crazy complicated code for doing the simplest things. Often the abstractions required a lot more code (sometimes 3 times the amount) as compared with writing the code straight up.
No... You do not need to make an array of objects and loop over them for everything, especially to save repeating 2 lines of almost identical code right next to each other.
No... You don't need to create 3 layers of abstractions spread all over the file and code base to write that test, just write the dang test assertion in 1 line! Seriously I've deleted thousands of lines of code like this recently because of the craziness.
I'd rather update a handful of lines of code by hand than learn whatever crazy abstraction you wanna invent on the fly.
I totally agree. Instead of fixing problem find and fix the root-cause.
7:58 the thing I always didnt understand about DRY is how are people pulling that off. like are they like endlessly just refactoring code and not finishing anything.
There is "premature optimization" but there really should be "premature abstraction" too. Just because it is possible to wrap it in N layers of abstractions and indirections doesn't mean we should do that and think it is "maintainable" or "clean" or "DRY" or what ever unmeasured metric a large portion of devs are saying in a kneejerk defensive tone like they are kids caught red-handed with their hands in the cookie-jar. It reminds me of a blog series by Casey Muratori called "Semantic Compression", it is maybe a bit much text to review on stream but none the less pure gold.
And Docker is just a wrapper around containerd and containerd is just a wrapper around linux namespaces and linux namespaces... yknow what, let's just write the OS from scratch
yea its exactly what i tought ... ofc wrapper are fine if they respond to a need, and dont do (exactly) same boring thing X times is a need for me :)
Can you drop a link to this message you reading from, the one in the description is not the same as in this video.Thanks
I will solve problems which do not exist. I will use code I do not understand. I will over-complicate things. I will fail upwards while everyone else fails downwards. I will become a -10x engineer.
Totally agree with this. In fact replace the word “tool” with “abstraction”. There are way too many abstractions that try to hide complexity but just add to the pile of stuff to learn.
Linus may not be the nicest person in the world, but he certainly is one of the most important people in the world. He not only is a great developer, he also has basically the whole internet in his hands. Many network equipment parts (from fiber-to-wire-converters to the very servers that run the internet) run Linux or something based on Linux. Almost 100% of the web runs on Linux. And even 3.x% of desktop computers run Linux.
Meh. It's not as important as you think it is. If it wasn't him it would have been someone else. It's just an offensive job that few--if any--sane people would actually want to do, so they let this little goblin do it.
@@youtubesuresuckscock
But because _he_ took that role _he_ is basically the most important person in the world. It's not because it's him, it's because he created and maintains Linux.
@@Lampe2020 That's not my definition of most important. If he had never been born, things would have more or less played out the same way. The most important people had a significant impact. At the end of the day, no operating system really matters much.
Had he not done what he did, other people would've come up with comparable solutions a few years later.
@@deleted01
Expand the answer section of this comment to see my answer to another user who said basically the same thing.
As someone uninitiated, I don't understand how a _get_next_ino()_ call (sounds like a application-specific UID generator) can help achieve something that could otherwise be achieved with a _atomic 64_add return()_ call (sound like a very general arithmetic operation). What did the perpetrator hope, how could that function solve his/her problem?
Apart from being ugly/unprofessional/etc., was there any chance that those were interchangable in the first place? O_o
maybe is doing a simple addition to get the next unique inode number...
Blue hair. Next step is the thigh high rainbow socks.
Then he will cut off his penis. 🤣
Does anyone know which video is the original XY Problem?
Gordon Ramsey of coding
1:30 "kinda just making up a thing, but..." *describes kubernetes*
but kubernetes is documented
@vilian9185 lol honestly not hating on k8s, but it kinda responded to exactly the perceived problem he was talking about.
I like the way LT writes. Sharp, concise, clear. No superfluous words.
"No superfluous words."
What? He's verbose af. Like 20% of his words are dedicated to denigrating colleagues.
Oh yeah, because you are not the subject.
The "you copied the function without knowing why t works" is almost never true for me, although I still have to wrap my head around how _exactly_ the async function delay(ms) on my website (copied from SO) waits for the specified amount of milliseconds.
Okay, I now (more than two years after adding it) finally understand how it works, it creates a promise that waits for a timeout to run out. Pretty clever!
Heyy... Nice blue hair 😄
It's green
wait did he get his hair done or is this some video effect
@@RiwenX
@@RiwenX more like a teal
@@VieiraBBX that’s one of those made up colors only girls recognize, like beige.
@@ea_naseer He got his hair done
"making things more complicated than they need to be is a an apparent pass time of web development now"
PREACH BROTHER
At the bank where I did two freelance projects the last 5 years me and another freelance colleague always yelled: "STOP! What problem are we solving?"
We are running BAU, so we know what the problems are that plague us, those we solve... Others that don't create business value, we flush!
And the irony is that those devs who found the edge of the edge of the edge case, didn't even bother to check if a file open actually returned a valid FD. When the create an object that it actually isn't null when they ingest data from a source didn't bother to run the conformation and consistency checks -- two classes that actually bring value for data consitency.
Can someone link the video of him talking about the XY problem?
3:19 will probably be the most played segment of this video
They end up making duplicate solutions meant to avoid repeating themselves. Genius !!
I think he meant "do not solve problems that doesn't exists" other than "do not solve small problems"
Docker is a wrapper around cgroups. Its wrappers all the way down.
True, haha
This is my first time seeing anything from Linus firsthand. I'm no expert by any means but I'm not going to lie; Sure he could have said that in a nicer way, but I agree with him on principle. I've often gotten flak for taking time to analyze the code that I'm supposed to just blindly import only to later fix a "crisis" with ease because I knew a bit about how the damn thing worked.
Nothing wrong with inspecting code, as long as you aren't flaming people! As brilliant as LT is as a programmer, his social IQ is pretty low.
Yeah, I don’t know if Prime has read old mailing list stuff but it has changed. He used to have more personal attacks on the dev rather than the code is garbage. He infamously said that someone should be retroactively aborted and were probably too stupid to find a teet to suck on.
I'm not really in the computer coding community. When I build my own code, if i include a function, i do learn/understand it's structure. I guess that's why I'm slow/not good at it.
bro dyed the hair blue, looking like Ninja(fortnite)
OMG! This speaks to me so viscerally! I mean, sometimes you want a "wrapper" (usually scripts) to help people not make mistakes. Especially if it saves time from a daily set of tasks. But I agree 200%... sometimes companies build in-house things to do things in the way THEY do things and then they don't train the newbies or even have good up-to-date documentation. Preach, brother!
He seemed to be a reasonable-sounding guy knowing his way, but then...... hi dyed his hair in a strange liberal color))
He said he lost a bet haha
He lost a bet
I believe that strange "liberal color" is called "blue" these days.
Linus keeps a tight ship and he's not shy about flaming out the code noob tourist trying to submit scrapcode just to brag he/she did kernel development.
What does Prime means when JS can abstract anything at any point guys?
The abstraction away from the actual tech (while the underlying tech stays the same) is something that cloud providers are notorious for. For example "hey you should come use our custom web gui routing system (nginx)" or "hey you should use our container apps with 90% of the features stripped and basic scale to 0 serverless orchestration (kube)"
it has been a LONG TIME since I've heard something so useful on my lunchbreak quick videos. I'll share with my team the XY problem.
What dye did you use for your hair?
my team made a wrapper that brings up docker containers from a yaml file. It works just like, but not quite exactly like, docker compose
People are saying Linus is back to his self. No, younger Linus was much much worse. Young Linus would have said "Your code is garbage, and so are you " vs older Linus says "Your code is garbage, get better or I'm going to ignore you".
Call me a snowflake, but if I'd get such a code review I'd quit. A simple "Hey, this abstraction might be unnecessary. Please remove it or explain why it's needed" would have sufficed.
Developers need to have meetings like AA, where they have to stand up and introduce themselves, and admit their code is crap. Honestly, things would advance, if people were open to criticism, and improve their code, rather then thinking they are so far above everyone else, and refuse to budge.
Anyone have the link to the XY Problem vid?
I missed old Linus. Knowing he's there protecting the Kernel from well meaning dummies makes me feel a bit better.
Yay 5 minutes after post! Can't wait to actually get into it!
I don't even code and I love your content dude, keep up posting. Also respect for opening about your struggles in previous videos, big respect.
thanks, Linus/x for having a look deeply at core changes, I really appreciate that you are the last bastion
There's a one-two combo I really hate when asking for help online: The X-Y Problem and tl;dr. If I'm going to ask a question, I've often already had to look at alternatives and know about them. Now if I make my question very concise, I get asked why I'm doing X instead of Y. If I show my receipts to explain the entire situation, then it's too long and gets ignored. There's some middle ground in there that's pretty hard to hit, and it's kind of a moving target too.
deciding how much abstraction is enough and how much is too much is one of the hard parts of being a dev.
Anyone got a link to the-xy-problem reacting video?