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
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.
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.
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.
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.
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 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.
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.
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!
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.
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 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.
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 !!
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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
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.
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.
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!
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.
I feel like your docker argument is kinda jacked. By that metric everyone should learn machine code becauee any programming language is just wrapped up machine code! CARL!
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
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.
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.
Dude I work in IT and it's the same thing with best practices this and hypothetical scenario that, drives me fkn nuts when we could be doing things that actually help the users instead of being so myopic on fixing shit that isn't broken while neglecting shit that IS broken.
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
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.
At one of my jobs in the past, we had so many people doing exactly this. They would refactor code just for the sake of refactoring, not solving any real problems. Absolutely wrecking productivity of everyone else on the team having to learn their bullshit.
I sometimes do that (refactoring for the sake of exercising my skills and trying new approaches), but only on my own time; I wouldn't charge an employer for that. People who do that should be hauled into their supervisor's office and told to cease.
When I started writing commercial IT systems, the main thing was to spend as much time as possible on the business logic and as little as possible on the tooling. But I think a lot of technical people like dealing with technical stuff, so now there is a proliferation of tools.
I think a big lesson here is "don't follow random coding principles and best practices you don't understand". A drill is a much better tool for making holes than a rock, but it can also do much more damage if you have zero comprehension of what you're holding in your hand.
I appreciate what JS's abstraction capability has done for our awareness. With it we've begun seeing the upper limit of what is a useful abstraction. And it's not something like lisp where some 0.01% of coders ever actually make anything real with it. You can't learn without making mistakes. JS has allowed many to make mistakes and begin learning from them. You cannot apply discipline to yourself if you do not have freedom. It is painful, but it allows us to learn what good programming is.
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)"
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.
The thread continues, and is quite interesting. Clearly Linus is a man of little patience but a good deal of wisdom. When you see a problem, sometimes the solution is to simplify it away rather than solve it.
Exactly what I keep repeating over and over. Just because you CAN abstract does not mean you SHOULD. The level of abstraction has to be carefully considered. General rule I tend to use is: DO NOT ABSTRACT unless you have to and/or it really helps you (or the code - readability, maintainability etc.).
1000% agree with this. At my company, I sometimes get shit for rewriting, and rewriting the same AWS function (such as fetching file from S3 or another service) over and over again when my company has a wrapper for aws sdk. My fiew is DRY only matters when the underlying resource/code you are using has a high enough probability to change. Fun fact, all lambda function that used the company's wrapper for aws sdk failed after someone messed with the library
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.
This hits home hard. I've felt this for quite some time too and I also feel like it has creeped into documentation, where the actual quality of the written content has decreased, even though the quantity is vast and there's a million essential dependencies linked which you are supposed to use to make a simple program work which in return you have to read their awful docs and learn their syntax anew. Sometimes even the english language is an issue it seems. In the end you have a web frontend for some cli tool that has existed for decades. This is an upsetting trend which only makes things harder for everyone involved. As for the typical Linus rage: It's funny for us, but it's actually rough to get rectified like this, even when everything said is accurate. You just gotta take it and move on, seems the guy was a good sport about it, which is nice.
Yeah, mutually exclusive solutions. That's one of my favorites. How does it get additions and concatenations correct in any reliable fashion without strong typing or different operators? It doesn't! Or all implicit conversions ever: It's not a matter of if, only when. That's why I like helping people with c++. They either listen or their screams are very delightful. Same with very "smart" assembler code. Always entertaining when it's not your responsibility.
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.🤣🤣
ua-cam.com/video/TGfQu0bQTKc/v-deo.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
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.
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
>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.
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.
prime is about to start wearing thigh highs, and run arch
on his way to buy programming socks, software development is an equipment sport
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
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.
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 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
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.
Bad engineers love complexity. Good engineers love simplicity.
Just as terry davis pointed out
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'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.
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!
Why is his mustache dyed brown?
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
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.
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 !!
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.
he's delving deeper into rust...
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.
I totally agree. Instead of fixing problem find and fix the root-cause.
The x-y problem is basically what librarian training is based on, learning how to unpack what the person is actually asking.
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.
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.
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.
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.
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 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.
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?
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
They end up making duplicate solutions meant to avoid repeating themselves. Genius !!
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.
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.
The lore friendly next step for him are the stripey programmer socks
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.
lmao i just saw this yesterday and spent a good ten minutes reading the email chain between linus and steven
Linus has magical ability to look across the problem towards the real issue and foresight to avoid technical debt as much as possible.
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.
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.
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 :)
That video was way more to the point than I thought it would be. Very nice.
I'm afraid of what Linux will become in the aftermath of the inevitable day when we lose Linus. :(
Such good continued exposure for the X/Y Problem. Well done!
Blue hair. Next step is the thigh high rainbow socks.
Then he will cut off his penis. 🤣
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.
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.
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!
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.
I feel like your docker argument is kinda jacked. By that metric everyone should learn machine code becauee any programming language is just wrapped up machine code! CARL!
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
yes.... Linus is an AMAZINGLY dedicated dev. The quality of his code is something else.
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.
thanks, Linus/x for having a look deeply at core changes, I really appreciate that you are the last bastion
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.
Dude I work in IT and it's the same thing with best practices this and hypothetical scenario that, drives me fkn nuts when we could be doing things that actually help the users instead of being so myopic on fixing shit that isn't broken while neglecting shit that IS broken.
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
Docker is a wrapper around cgroups. Its wrappers all the way down.
True, haha
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.
At one of my jobs in the past, we had so many people doing exactly this. They would refactor code just for the sake of refactoring, not solving any real problems. Absolutely wrecking productivity of everyone else on the team having to learn their bullshit.
I sometimes do that (refactoring for the sake of exercising my skills and trying new approaches), but only on my own time; I wouldn't charge an employer for that. People who do that should be hauled into their supervisor's office and told to cease.
I think he meant "do not solve problems that doesn't exists" other than "do not solve small problems"
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.
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
I appreciate the hair color change. It really makes it obvious roughly when the video was made
Gordon Ramsey of coding
When I started writing commercial IT systems, the main thing was to spend as much time as possible on the business logic and as little as possible on the tooling. But I think a lot of technical people like dealing with technical stuff, so now there is a proliferation of tools.
3:19 will probably be the most played segment of this video
I missed old Linus. Knowing he's there protecting the Kernel from well meaning dummies makes me feel a bit better.
bro dyed the hair blue, looking like Ninja(fortnite)
I think a big lesson here is "don't follow random coding principles and best practices you don't understand".
A drill is a much better tool for making holes than a rock, but it can also do much more damage if you have zero comprehension of what you're holding in your hand.
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.
"making things more complicated than they need to be is a an apparent pass time of web development now"
PREACH BROTHER
I appreciate what JS's abstraction capability has done for our awareness. With it we've begun seeing the upper limit of what is a useful abstraction. And it's not something like lisp where some 0.01% of coders ever actually make anything real with it. You can't learn without making mistakes. JS has allowed many to make mistakes and begin learning from them.
You cannot apply discipline to yourself if you do not have freedom. It is painful, but it allows us to learn what good programming is.
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)"
In the mechanic world, we refer to XY problem as the can of worms paradox.- Don't be surprised when you find worms when opening a can of worms.
deciding how much abstraction is enough and how much is too much is one of the hard parts of being a dev.
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.
Solving problems that don’t exist isn’t just a problem with web dev, much of the startup world is like this as well.
The thread continues, and is quite interesting. Clearly Linus is a man of little patience but a good deal of wisdom. When you see a problem, sometimes the solution is to simplify it away rather than solve it.
Shiny object syndrome is something I am going to have to remember and use. That's amazing
This is recent. YEEEES!
Linus is back, the Kernel is saved!
Exactly what I keep repeating over and over.
Just because you CAN abstract does not mean you SHOULD.
The level of abstraction has to be carefully considered.
General rule I tend to use is: DO NOT ABSTRACT unless you have to and/or it really helps you (or the code - readability, maintainability etc.).
1000% agree with this. At my company, I sometimes get shit for rewriting, and rewriting the same AWS function (such as fetching file from S3 or another service) over and over again when my company has a wrapper for aws sdk. My fiew is DRY only matters when the underlying resource/code you are using has a high enough probability to change. Fun fact, all lambda function that used the company's wrapper for aws sdk failed after someone messed with the library
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.
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.
This hits home hard. I've felt this for quite some time too and I also feel like it has creeped into documentation, where the actual quality of the written content has decreased, even though the quantity is vast and there's a million essential dependencies linked which you are supposed to use to make a simple program work which in return you have to read their awful docs and learn their syntax anew. Sometimes even the english language is an issue it seems. In the end you have a web frontend for some cli tool that has existed for decades. This is an upsetting trend which only makes things harder for everyone involved.
As for the typical Linus rage: It's funny for us, but it's actually rough to get rectified like this, even when everything said is accurate. You just gotta take it and move on, seems the guy was a good sport about it, which is nice.
I understand the disdain for wrappers, but man, when they're just short hand, they're great
Yeah, mutually exclusive solutions.
That's one of my favorites. How does it get additions and concatenations correct in any reliable fashion without strong typing or different operators?
It doesn't!
Or all implicit conversions ever:
It's not a matter of if, only when. That's why I like helping people with c++. They either listen or their screams are very delightful. Same with very "smart" assembler code. Always entertaining when it's not your responsibility.
Yay 5 minutes after post! Can't wait to actually get into it!
6:00 thank you for this segment. I will view forum posts in a more distanced way from now on.
This is really key argument, thanks for sharing.