I love that someone is talking about this. The transfer of information from one human to another is complicated and difficult and deserves more intentionality. I definitely agree that documentation needs to be more than a brief summary. And that need grows exponentially with the size of the company. More developers need to realize that documentation is part of the job too, not just writing code.
Interesting point, and I'm 100% pro good documentation. However, as an old coder, I know that this problem was solved a long time ago with Classes. If these vague raw objects were instances of "User" with a method called "isAdmin" and no public "admin boolean" then, boom, no problemo! The main issue is that it's trending to vilanize OOP so people are reinventing the wheel with what they think is functional programming.
@@lucemiserlohn You need to decide whether to engage in a full debate or let the point go entirely. Simply pointing out that something is wrong without elaborating doesn't contribute meaningfully to the discussion.
Cool video! Documentation is important, but one of the big challenges is balancing it with tight deadlines... Clients often push for fast feature delivery, making it tough to dedicate time to proper documentation... The pressure to ship products fast sometimes pushes documentation down the priority list..
At the same time, for a large project with multiple developers you would probably deliver features faster if you had a culture of documentation since then you wouldn’t have to grep through large parts of could someone else wrote for multiple hours just to understand one function or class.
There will always be conflict between devs and business management where devs want to do things "right" and be mindful of what will be effective, maintainable, and stable in the long run, and business management wants to do things "fast" with some level of risk tolerance because that's what will make the business competitive, and only the creation of value to the user can justify the business's revenue. Both sides have valid points. Unfortunately, management often eventually runs into worse profits as a result of previous decisions to move too quickly. The case I guess I'm trying to make in this video is that it's worth it to allow devs time to document sufficiently, just like some companies allow devs time to write comprehensive unit tests.
Wow dude this video couldn't have come at a better time for me. I had the opinion that you shot down in the first 30 seconds, and realized that I was saying that pointers in C are too much of an abstraction because they didn't make sense to me and were "simpler" to me in assembly (and supposedly therefore better). Thank you!
I think the main idea here is to make everyone wary of abstractions. Abstractions are a great tool of solving problems of the same kind but for different entities, but it has to be used with caution. The problem is that people try and find the one size fits all solution, like the do with hash maps and interview. People tend to do things they read or heard some smarter person say, without actually understanding what they said, they just repeat, leading to code that has abstractions where it should not have.
100% with you. abstraction and proper encapsulation are key to speed up and better soft dev. from my experience most code bases are low quality and most devs don't know/don't care to make it better. it's exactly like you said. you can write some classes with proper methods and sweet encapsulation but they don't even look at it or care to understand it (they want it "lazy"). they raise PRs accessing object properties directly (for example)....it's imediate reject from me.
It's very optimistic to expect devs who don't even care to understand your abstraction to actually search, read and keep up to date some external documentation.
Very nice presentation. Problem is I've never seen a programmer want to or think about reading documentation for a class and its methods like this. Even if they do there is little faith in that the documentation has been maintained. I think the ideal is to have code that is readable and maintainable, i.e., code that documents itself. Anything beyond the usual "abstraction" might get ignored... unless they have to deal with it like it being part of a library that is pulled in everywhere.
If the code documents itself so well that all the contributors decide to use the abstractions that are already present, then that's awesome. And to a certain point of complexity, I think that's exactly what you want. I do also think projects can become so large and feature sets can become so complex that it's infeasible the code could be reasonably expected to document itself sufficiently. When you use a framework (Laravel, for example), when you approach a new problem your instinct is to go to the docs and see whether they have a built-in way to do it, and that's a consequence of having excellent documentation, IMO.
I prefer using OOP because simply scattering functions across files increases the risk of duplication. Someone might rewrite existing code because they couldn’t easily find the relevant functions or tools. By organizing functionality into classes, you group related methods logically, making it easier to locate, understand, and extend the code.
You can run across this same issue with OOP because someone might not notice a certain class already exists, or might think the logic is simple enough it doesn't warrant reading through the class or trying to learn how it works, and they'll reimplement. If the project is simple enough, it might be clear what's there and how to use it without needing much documentation. On larger projects though, this issue crops up a lot, even with OOP. I'd like to do a video on functional programming versus OOP and give examples on how you might approach the same feature in both ways.
@@fludeo1307 I agree. In this particular example an "User" class with no public properties and just a "isAdmin" method would be a simpler way to tackle the problem. Static types would also go a long way (with OOP or not)
leaky abstractions are the problem. when the abstraction makes it so I can't get the same performance as without it, that is a leak. I need to think under the covers of the abstraction. when the abstraction makes it harder to actually do what I'm trying to do, that's a leak. I need to think under the covers of the abstraction. even well thought abstractions have a cost, if at least during maintenance and in the face of (perpetual) requirements changes. and people often aren't taught how to recognize or make decisions regarding those costs. many people are taught to always maximally abstract in every place they can think to abstract. and most of those abstractions have a big cost with little or negative value. DRY is a metric that is a proxy for code quality. and once people focus on optimizing for a metric that's a proxy, it stops being that useful a metric. damn right I'm going to use abstractions. sparingly. when they make sense, and obviously solve many more problems than they cause. when they don't take forever to come up with. when I don't paint myself into a corner of design with them. and it will usually take me a while to figure out the drawbacks of whatever abstraction I make, so I'm prone to only put them in when I've already suffered a decent amount of pain without them.
Brilliant video. Thanks. I wish someone could tell me what I can do, I have an issue related to the video topic: We have lots of repos, and there's only my boss (the principal engineer) who understand how everything works. The code has grown a lot and there's zero code documentation, I am requested to write features without going out of the standard for how x, y or z has already been implemented in the code elsewhere from the module I'm working in. This results in him requesting me to rewrite entire feature branches several times until it follows how everything else works (I'm dedicated and would've written them propperly if I could've accessed those details beforehand). The business is fairly complicated, therefore the code also becomes complex due to a minimum complexity threshold. But if I ask the guy for details (because he IS the documentation) he's always going to have oversights that result in me redoing my work afterwards. My question: Is this a skill issue on my end? Should I be able to read the code better, open up myself more to the mess in the current code? What can I do to polish up a bit? I don't know what to do about it, is it normal to be requested to rewrite something 3, 4 different times? (I understand what I am doing in my code at least a bit, it's not always that my code is a mess but rather that it goes outside of the standard for how something else is written somewhere unknown to me). Is my perspective wrong? Thanks.
There is a skill to deciphering legacy code bases in order to "get along" with how they already do things, but it's a skill that your boss shouldn't have to expect everyone to be able to do to even be able to work. Unfortunately this is the case in many places because they haven't experienced the velocity improvement that comes from having clear documentation. I don't think it's your fault, but I do think in your case you'll have to just do your best to read through and understand what's available for you to use. One example is I've had to implement new api endpoints for a project that has an existing repo for the back end. Adding a new endpoint involves modifying at least three different files in very specific ways, following the pattern the existing endpoints are using. I've definitely missed changes I was supposed to make because it wasn't clear to me I had to make them because nothing was documented. So I'd recommend always trying to find whether there's an established pattern/methodology for doing something before beginning to implement something. There might not be, but it can't hurt to ask "Hey, when you guys need to write to the database, do you just call the dependency's methods directly, or is there a helper class I can use?". The more you work in big legacy code bases, the more people you're gonna have to talk to. The complexity might even warrant a phone call or face-to-face meeting to really get it.
I would disagree with you on a subjective point: The most important usage for abstraction is not avoiding copy+paste coding or even making it so a single change to the definition is propagated to all the callsites. Instead I would say that the most important usage for abstraction is about giving a clear and concise name to a block of code. It's an ability you don't have otherwise. When you think about abstraction like this, you still will want to abstract things even if the code isn't being reused in any way.
That's a really nice video. Can you also make some video about create that documentation? I'm not a developer but I'm working with infrastructure as a code and frequently I see terraform gymnastics or docker images writen in complicated way, even bash and python scripts are hard to understand. The knowledge is very distributed and mixed
Yup. Tools in the box. Use the right tool for the job. Document the job. Everyone loves the construction analogy in software development, so don't use a screwdriver to drive nails and make sure you update the as-built blueprints if you deviate from the provided plans. There are too many developers who don't understand this basic concept and anything that is hard (abstraction, pointers and memory management, etc) is bad because why not.
Remember abstraction works in levels, so we have db lvl repo lvl domain lvl http lvl, dont mix them. This will help You to decide what to abstract and what not to.
I've actually just been thinking about this same issue recently - we, as a community, keep talking about avoiding unecessary complexity, avoiding over-abstraction, code should be really easy to read, etc. We even make this disctintion between accidental vs essential complexity, where essential complexity is related to the domain, and accidental complexity is everything else and is inherently bad. And I feel like, as a culture, we've been pushing this abstraction-avoidance thing too far. Of course, any abstractions we create if fine, because we see the obvious benefit to them, but anytime we run into an abstraction someone else made that we don't immedietally click, well, that was obviously a bad abstraction - it was far too complicated, someone ought to refactor that. And as a result of this mindset, we're producing this rewrite culture, where we're having to constantly rewrite codebases from one set of abstractions to another set of abstractions we prefer. Better documentation might help, I agree. But I also think that, more fundamentally, we also just need to have a shift in our culture. We shouldn't be so afraid of complexity. We should be willing to be more patient when trying to understand code other people have written, and try to be more understanding and respectful of their choices. We should try working within their abstractions to the best we can for a while and try to understand their perspective before we go about up-ending everything. Maybe we'd even learn a thing or two by trying to try out someone else's way of thinking. And, ya know, sometimes the code really is rotten because it is unecessarily abstracted or underabstracted, and it really does need to be upended. Or maybe parts of it could be revisted, but the overall idea was fine - perhaps not what you would have picked, but it's fine. So not saying we shouldn't touch the abstractions other people have made, just that we, perhaps, need to be more thoughtful before we touch them.
This is one of the better use cases for AI. In my case, I've had good results uploading a single code file at a time to Claude AI (claude.ai) and asking it to produce human-readable documentation on how to use the methods in the file.
I get what you are going for and would argue that you miss the point. First of all you are right in that "thou shall not repeat business logic", it is a fair and accurate point. But abstraction is not just creating functions, it is also about encapsulating things inside objects and using inheritance. On some level, encapsulating things makes some sense, it will enforce some boundaries and avoid traps. However encapsulating things too much or before the needs arise is just as bad as not having encapsulation, that is why a lot of people including me are pushing back on abstraction and especially OOP. The point of fighting abstraction is that you may also never change the admin check or realize that you actually have 5 levels of permission for the user. Trying to predict futur use case before knowing them fully may lead you to create abstractions that are more complex than they need to be or that are just not correct for the use case. Either way you end up in a spot where you need to fight the abstractions that were created because they don't account for the specific thing you need. A recent example from my work is using a big library to receive messages. They have an abstract class for the support of communication and function exposed such as read that is blocking and a function poll that is non blocking. For performance reasons, we would need the poll or read to be blocking (ie get the message as soon as it arrives) but also not just block indefinitely to be able to exit the program gracefully. What happened is the creators didn't thing of that and didn't provide a way of doing this. So now you either change their abstraction or find out by digging into their abstraction that in the end they always use posix sockets and just get a hold on those and block poll with timeout on those. In the end, the abstraction was wrong and the cost of modifying it was high for something that was trivial, and that's the problem, abstraction is not a replacement for dumb straight forward code that does what you need, it is a tool to make dumb staight forward code easier to write/read and understand.
@@Nellak2011 it's ironic how OOP would solve this in the blink of an eye. A "User" class with a method "isAdmin" and no public "admin" property. It's trendy to bash on OOP
@@Zizaco It is not just Trendy but based on fundamentals. OOP creates a pit of failure. To be successful in that paradigm you must apply design patterns perfectly and deal with code bloat and boiler plate. It is like balancing a pencil on its tip. Meanwhile Functional Programming and related paradigms like DOP and DDD create a pit of success where it is actually hard to make obfuscated systems. The fundamental reason why is that OOP rigidly combines data and functions which creates coupling, whereas FP and DOP treat data as data and it is free and decoupled. So yea, OOP is trash even when dome perfectly. FP and Procedural are the only ways to program in a valid way.
@@Nellak2011 the last phrase in your comment shows how dogmatic your take is. I'd bet you don't have many years in the industry so you take the words of others on why OOP is bad. DOP is about performance and efficient processing (memory layout), not about design. Also it's not incompatible with OOP. I'm not claiming that OOP is the only valid approach (nor the best), but learning the fundamentals and why it was created in the first place can help avoid a lot of reinventing the wheel type of situations. I'm just pointing out that a 5 line "class" would solve the issue presented in the video in a somewhat simpler way. Mapping a "User" business entity to an "User" ~code perfectly aligns with DDD.
@@Zizaco Dogmatic? My take is the opposite actually. It is based on logical principles such as decoupling. Something OOP is not based on. An analogy may help. OOP says that the Earth is the center of the solar system, so we need complex epicycles (Design Patterns) to explain it and it is such a brittle model to any changes. FP says the sun is the center of the solar system, so we need only one principle to explain everything we see. Everything now all makes sense with one equation and is robust to changes. In FP we dont need design patterns, we just need 1 principle "Make it easy to change" and then an understanding of how to do that with functions. Read a book or something before you talk out of your ass 🤣🤣
Great observations, but I disagree with the proposed solution. Its not about docs, but about tests! Those are real world examples with schema, application, edge cases, short description. Tests must be consistent with code, docs just supposed to be. When I want to quickly catch-up how something works, I'm always looking for tests. So don't waste time on docs, write good tests!
I love that someone is talking about this. The transfer of information from one human to another is complicated and difficult and deserves more intentionality. I definitely agree that documentation needs to be more than a brief summary. And that need grows exponentially with the size of the company. More developers need to realize that documentation is part of the job too, not just writing code.
Interesting point, and I'm 100% pro good documentation. However, as an old coder, I know that this problem was solved a long time ago with Classes.
If these vague raw objects were instances of "User" with a method called "isAdmin" and no public "admin boolean" then, boom, no problemo!
The main issue is that it's trending to vilanize OOP so people are reinventing the wheel with what they think is functional programming.
There is so much wrong with your statement that I can't even begin.
@@lucemiserlohn You need to decide whether to engage in a full debate or let the point go entirely. Simply pointing out that something is wrong without elaborating doesn't contribute meaningfully to the discussion.
Cool video! Documentation is important, but one of the big challenges is balancing it with tight deadlines... Clients often push for fast feature delivery, making it tough to dedicate time to proper documentation... The pressure to ship products fast sometimes pushes documentation down the priority list..
At the same time, for a large project with multiple developers you would probably deliver features faster if you had a culture of documentation since then you wouldn’t have to grep through large parts of could someone else wrote for multiple hours just to understand one function or class.
There will always be conflict between devs and business management where devs want to do things "right" and be mindful of what will be effective, maintainable, and stable in the long run, and business management wants to do things "fast" with some level of risk tolerance because that's what will make the business competitive, and only the creation of value to the user can justify the business's revenue. Both sides have valid points. Unfortunately, management often eventually runs into worse profits as a result of previous decisions to move too quickly. The case I guess I'm trying to make in this video is that it's worth it to allow devs time to document sufficiently, just like some companies allow devs time to write comprehensive unit tests.
Wow dude this video couldn't have come at a better time for me. I had the opinion that you shot down in the first 30 seconds, and realized that I was saying that pointers in C are too much of an abstraction because they didn't make sense to me and were "simpler" to me in assembly (and supposedly therefore better). Thank you!
Pointers were the first thing in programming that made absolutely no sense to me. I didn’t get it for a long time.
I think the main idea here is to make everyone wary of abstractions.
Abstractions are a great tool of solving problems of the same kind but for different entities, but it has to be used with caution. The problem is that people try and find the one size fits all solution, like the do with hash maps and interview.
People tend to do things they read or heard some smarter person say, without actually understanding what they said, they just repeat, leading to code that has abstractions where it should not have.
100% with you. abstraction and proper encapsulation are key to speed up and better soft dev. from my experience most code bases are low quality and most devs don't know/don't care to make it better. it's exactly like you said. you can write some classes with proper methods and sweet encapsulation but they don't even look at it or care to understand it (they want it "lazy"). they raise PRs accessing object properties directly (for example)....it's imediate reject from me.
I've been procrastinating to watch this whole video for a long time
The examples given in the video are so real, keep up the nice work.
It's very optimistic to expect devs who don't even care to understand your abstraction to actually search, read and keep up to date some external documentation.
Yes because we have jobs.
Very nice presentation. Problem is I've never seen a programmer want to or think about reading documentation for a class and its methods like this. Even if they do there is little faith in that the documentation has been maintained. I think the ideal is to have code that is readable and maintainable, i.e., code that documents itself. Anything beyond the usual "abstraction" might get ignored... unless they have to deal with it like it being part of a library that is pulled in everywhere.
If the code documents itself so well that all the contributors decide to use the abstractions that are already present, then that's awesome. And to a certain point of complexity, I think that's exactly what you want. I do also think projects can become so large and feature sets can become so complex that it's infeasible the code could be reasonably expected to document itself sufficiently. When you use a framework (Laravel, for example), when you approach a new problem your instinct is to go to the docs and see whether they have a built-in way to do it, and that's a consequence of having excellent documentation, IMO.
We all faced that problem. Solid explanation right there
I prefer using OOP because simply scattering functions across files increases the risk of duplication. Someone might rewrite existing code because they couldn’t easily find the relevant functions or tools. By organizing functionality into classes, you group related methods logically, making it easier to locate, understand, and extend the code.
With poorly named classes you will get the same chaos with OOP.
You can run across this same issue with OOP because someone might not notice a certain class already exists, or might think the logic is simple enough it doesn't warrant reading through the class or trying to learn how it works, and they'll reimplement. If the project is simple enough, it might be clear what's there and how to use it without needing much documentation. On larger projects though, this issue crops up a lot, even with OOP.
I'd like to do a video on functional programming versus OOP and give examples on how you might approach the same feature in both ways.
@@fludeo1307 I agree. In this particular example an "User" class with no public properties and just a "isAdmin" method would be a simpler way to tackle the problem.
Static types would also go a long way (with OOP or not)
leaky abstractions are the problem.
when the abstraction makes it so I can't get the same performance as without it, that is a leak. I need to think under the covers of the abstraction.
when the abstraction makes it harder to actually do what I'm trying to do, that's a leak. I need to think under the covers of the abstraction.
even well thought abstractions have a cost, if at least during maintenance and in the face of (perpetual) requirements changes. and people often aren't taught how to recognize or make decisions regarding those costs. many people are taught to always maximally abstract in every place they can think to abstract. and most of those abstractions have a big cost with little or negative value.
DRY is a metric that is a proxy for code quality. and once people focus on optimizing for a metric that's a proxy, it stops being that useful a metric.
damn right I'm going to use abstractions. sparingly. when they make sense, and obviously solve many more problems than they cause. when they don't take forever to come up with. when I don't paint myself into a corner of design with them. and it will usually take me a while to figure out the drawbacks of whatever abstraction I make, so I'm prone to only put them in when I've already suffered a decent amount of pain without them.
Brilliant video. Thanks.
I wish someone could tell me what I can do, I have an issue related to the video topic:
We have lots of repos, and there's only my boss (the principal engineer) who understand how everything works.
The code has grown a lot and there's zero code documentation, I am requested to write features without going out of the standard for how x, y or z has already been implemented in the code elsewhere from the module I'm working in. This results in him requesting me to rewrite entire feature branches several times until it follows how everything else works (I'm dedicated and would've written them propperly if I could've accessed those details beforehand). The business is fairly complicated, therefore the code also becomes complex due to a minimum complexity threshold. But if I ask the guy for details (because he IS the documentation) he's always going to have oversights that result in me redoing my work afterwards.
My question: Is this a skill issue on my end? Should I be able to read the code better, open up myself more to the mess in the current code? What can I do to polish up a bit? I don't know what to do about it, is it normal to be requested to rewrite something 3, 4 different times? (I understand what I am doing in my code at least a bit, it's not always that my code is a mess but rather that it goes outside of the standard for how something else is written somewhere unknown to me). Is my perspective wrong? Thanks.
There is a skill to deciphering legacy code bases in order to "get along" with how they already do things, but it's a skill that your boss shouldn't have to expect everyone to be able to do to even be able to work. Unfortunately this is the case in many places because they haven't experienced the velocity improvement that comes from having clear documentation. I don't think it's your fault, but I do think in your case you'll have to just do your best to read through and understand what's available for you to use.
One example is I've had to implement new api endpoints for a project that has an existing repo for the back end. Adding a new endpoint involves modifying at least three different files in very specific ways, following the pattern the existing endpoints are using. I've definitely missed changes I was supposed to make because it wasn't clear to me I had to make them because nothing was documented. So I'd recommend always trying to find whether there's an established pattern/methodology for doing something before beginning to implement something. There might not be, but it can't hurt to ask "Hey, when you guys need to write to the database, do you just call the dependency's methods directly, or is there a helper class I can use?". The more you work in big legacy code bases, the more people you're gonna have to talk to. The complexity might even warrant a phone call or face-to-face meeting to really get it.
@@mcsamr Your guidance is greatly appreciated. Thank you for your support.
I would disagree with you on a subjective point: The most important usage for abstraction is not avoiding copy+paste coding or even making it so a single change to the definition is propagated to all the callsites. Instead I would say that the most important usage for abstraction is about giving a clear and concise name to a block of code. It's an ability you don't have otherwise. When you think about abstraction like this, you still will want to abstract things even if the code isn't being reused in any way.
That's a really nice video. Can you also make some video about create that documentation? I'm not a developer but I'm working with infrastructure as a code and frequently I see terraform gymnastics or docker images writen in complicated way, even bash and python scripts are hard to understand. The knowledge is very distributed and mixed
Yup. Tools in the box. Use the right tool for the job. Document the job. Everyone loves the construction analogy in software development, so don't use a screwdriver to drive nails and make sure you update the as-built blueprints if you deviate from the provided plans.
There are too many developers who don't understand this basic concept and anything that is hard (abstraction, pointers and memory management, etc) is bad because why not.
Remember abstraction works in levels, so we have db lvl repo lvl domain lvl http lvl, dont mix them. This will help You to decide what to abstract and what not to.
Great content!
solid points, but the argument is where should the line of abstraction be
4:30 Bless ya
Haha, thank you!
I've actually just been thinking about this same issue recently - we, as a community, keep talking about avoiding unecessary complexity, avoiding over-abstraction, code should be really easy to read, etc. We even make this disctintion between accidental vs essential complexity, where essential complexity is related to the domain, and accidental complexity is everything else and is inherently bad. And I feel like, as a culture, we've been pushing this abstraction-avoidance thing too far.
Of course, any abstractions we create if fine, because we see the obvious benefit to them, but anytime we run into an abstraction someone else made that we don't immedietally click, well, that was obviously a bad abstraction - it was far too complicated, someone ought to refactor that. And as a result of this mindset, we're producing this rewrite culture, where we're having to constantly rewrite codebases from one set of abstractions to another set of abstractions we prefer.
Better documentation might help, I agree. But I also think that, more fundamentally, we also just need to have a shift in our culture. We shouldn't be so afraid of complexity. We should be willing to be more patient when trying to understand code other people have written, and try to be more understanding and respectful of their choices. We should try working within their abstractions to the best we can for a while and try to understand their perspective before we go about up-ending everything. Maybe we'd even learn a thing or two by trying to try out someone else's way of thinking.
And, ya know, sometimes the code really is rotten because it is unecessarily abstracted or underabstracted, and it really does need to be upended. Or maybe parts of it could be revisted, but the overall idea was fine - perhaps not what you would have picked, but it's fine. So not saying we shouldn't touch the abstractions other people have made, just that we, perhaps, need to be more thoughtful before we touch them.
I love your thinking on this.
> if (user.admin === true) { user.onboarded = true }
Only in JavaScript.
Do you have any recommendations on what to use for documentation?
This is one of the better use cases for AI. In my case, I've had good results uploading a single code file at a time to Claude AI (claude.ai) and asking it to produce human-readable documentation on how to use the methods in the file.
js without typescript is the enemy
I get what you are going for and would argue that you miss the point. First of all you are right in that "thou shall not repeat business logic", it is a fair and accurate point. But abstraction is not just creating functions, it is also about encapsulating things inside objects and using inheritance.
On some level, encapsulating things makes some sense, it will enforce some boundaries and avoid traps. However encapsulating things too much or before the needs arise is just as bad as not having encapsulation, that is why a lot of people including me are pushing back on abstraction and especially OOP.
The point of fighting abstraction is that you may also never change the admin check or realize that you actually have 5 levels of permission for the user. Trying to predict futur use case before knowing them fully may lead you to create abstractions that are more complex than they need to be or that are just not correct for the use case. Either way you end up in a spot where you need to fight the abstractions that were created because they don't account for the specific thing you need.
A recent example from my work is using a big library to receive messages. They have an abstract class for the support of communication and function exposed such as read that is blocking and a function poll that is non blocking. For performance reasons, we would need the poll or read to be blocking (ie get the message as soon as it arrives) but also not just block indefinitely to be able to exit the program gracefully.
What happened is the creators didn't thing of that and didn't provide a way of doing this. So now you either change their abstraction or find out by digging into their abstraction that in the end they always use posix sockets and just get a hold on those and block poll with timeout on those.
In the end, the abstraction was wrong and the cost of modifying it was high for something that was trivial, and that's the problem, abstraction is not a replacement for dumb straight forward code that does what you need, it is a tool to make dumb staight forward code easier to write/read and understand.
What you're saying common sense. But common sense is not very common, even in developers.
I am so glad to hear someone actually talking about good software engineering rather than the over used OOP bullshit.
@@Nellak2011 it's ironic how OOP would solve this in the blink of an eye.
A "User" class with a method "isAdmin" and no public "admin" property. It's trendy to bash on OOP
@@Zizaco It is not just Trendy but based on fundamentals.
OOP creates a pit of failure.
To be successful in that paradigm you must apply design patterns perfectly and deal with code bloat and boiler plate.
It is like balancing a pencil on its tip.
Meanwhile Functional Programming and related paradigms like DOP and DDD create a pit of success where it is actually hard to make obfuscated systems.
The fundamental reason why is that OOP rigidly combines data and functions which creates coupling, whereas FP and DOP treat data as data and it is free and decoupled.
So yea, OOP is trash even when dome perfectly. FP and Procedural are the only ways to program in a valid way.
@@Nellak2011 the last phrase in your comment shows how dogmatic your take is.
I'd bet you don't have many years in the industry so you take the words of others on why OOP is bad.
DOP is about performance and efficient processing (memory layout), not about design. Also it's not incompatible with OOP.
I'm not claiming that OOP is the only valid approach (nor the best), but learning the fundamentals and why it was created in the first place can help avoid a lot of reinventing the wheel type of situations. I'm just pointing out that a 5 line "class" would solve the issue presented in the video in a somewhat simpler way.
Mapping a "User" business entity to an "User" ~code perfectly aligns with DDD.
@@Zizaco Dogmatic?
My take is the opposite actually. It is based on logical principles such as decoupling.
Something OOP is not based on.
An analogy may help.
OOP says that the Earth is the center of the solar system, so we need complex epicycles (Design Patterns) to explain it and it is such a brittle model to any changes.
FP says the sun is the center of the solar system, so we need only one principle to explain everything we see. Everything now all makes sense with one equation and is robust to changes.
In FP we dont need design patterns, we just need 1 principle "Make it easy to change" and then an understanding of how to do that with functions.
Read a book or something before you talk out of your ass 🤣🤣
a take so based i'm going to have to be nicer to javascript programmers
Great observations, but I disagree with the proposed solution. Its not about docs, but about tests! Those are real world examples with schema, application, edge cases, short description. Tests must be consistent with code, docs just supposed to be. When I want to quickly catch-up how something works, I'm always looking for tests. So don't waste time on docs, write good tests!
you consistently have L takes on your channel - shows that you have never worked in the industry before (in any meaninful capacity). I wish you luck.
Well, to each their own I guess
Maybe if you elaborated your critisism?