Well, I guess the entire concept of software engineering rests on the basis on abstractions. Each developer will decide which layers of abstraction are relevant to them. Theoretically, a properly created layer of abstraction with exposed APIs should have its implementation details be unimportant to the user. However, in reality knowing implementation details is often times important. If a user spends all of their time learning the implementation, they will be less productive in their task. But always avoiding learning implementation results is a poor knowledge base.
One of the things I loved from the first College I went into to study Multimedia Engineering, is that they always teached us the low level details, sometimes even creating those abstractions in our own to understand them, and then we moved one layer of abstraction up. So even using abstractions, we learned the inner workings, and when needed we were able to change them.
I remember seeing someone's (Bjarne Stroustrup's?) phrase about levels of abstraction: it's designed like onion, you peel them off layer by layer and the more levels you peel off, the more you cry.
At last, someone who understands my thoughts... Ive always thought that its important to know what's going on behind the scenes of each action when writing code
Ok I very much agree with this. In the beginning I wanted things to be more abstract, now the more I know, the lower level I want to work at. The thing about abstraction is that its built on top of objective reality, and that reality will always exist and will always be a consideration whether you like it or not. The more complex things you need to do the more that reality will come back to remind you of its existence. I hadn't thought about what you said near the end though, that the people who have the most to gain from abstractions are the people that know the underlying systems and the abstractions inside out. Which is ironically the opposite of people using the abstractions because they don't want to know what's actually happening. The funny thing is that I've been finding the lower-level stuff is actually easier to learn over all than the high level abstractions. Because you just need to learn how the computer works. If you know about how it works, if you know how to model data and if you understand algorithms then thats everything. You can now tackle any problem using the same tools. Compare this with an ever-changing and evolving set of convoluted frameworks and abstractions, some with little to no basis in anything actually going on under the hood. They might seem like less work and effort to get into, but in the long term the constant changing nature of those things, coupled with the headaches of debugging and having to push past what they are designed to do when you need more complex things, suddenly just sticking to lower level stuff becomes simple by comparison.
Totally agree! The first popular high level languages like Java allowed us to avoid the pain of working at a low level and focus on engineering business logic. Not to mention targeting multiple OS with the same codebase. Even higher level languages like PHP, Javascript and Python allow us to prototype quickly or build web applications. The low code idea is a gimmick. Just imagine all of the second by second tweaks and errors we make while building software. Think of all the possibilities of abstraction, interfaces, data structures and computation. Mathematical libraries, document generation, cryptographic functions. Now imagine trying to build a UI that allows users to build that same software without having to code. Now imagine allowing the same users to work at a low level, allocating memory and dereferencing. We'd spend more time trying to debug the low code software than actually building anything.
Low code is good to quickly get internal apps out but you lose flexibility. As long people know what the tool is good for and what not it's great
2 ปีที่แล้ว +11
Totally agree. The more I use Spark/Dask for data processing workflows, the more I I'm looking into making the core of the logic just in rust/CPP (and parallelise it via k8s). Leaky abstractions (Spark rdd/Dask df) make it a lot more problematic to manage memory requirements ESPECIALLY in highly distributed envs.
2 ปีที่แล้ว +5
"Black box" is just a convenient excuse not to know what's going on in your own Business logic. That's dangerous
2 ปีที่แล้ว +1
@jeff pentagon i did, it's fun but that is not the point. In spark JVM takes ~300MB of ram from every executor regardless of executor's size. In workloads where I use > 2k executors it's starting to sum up. I just feel like we could do exactly the same thing but much more efficiently. Modern cpp is memory safe enough, without the a need for a GC, to try it (not to mention rust).
In my experience -- within a restricted context (like you mention @18:45), well-designed low/no code systems can provide significant reduction in development effort with a manageable performance penalty. On the flip side, one does need to be alert to the pervasive and indiscriminate use of no/low code configurations. If used pervasively and indiscriminately, the system/application can quickly evolve into a "code-figuration" monstrosity -- i.e. an unwieldy and unsightly mess of configuration (declarative abstractions) that tries to mimic code (imperative abstractions), with the added "features" of poor performance and scalability. In other words you could end up with the worst of both worlds -- like the example that you mention of ORMs. Someone once said that ORMs are an example of taking two good technologies/paradigms in their own right (OO and RDBMS) and bringing them together to create a poor-performance and difficult-to-maintain mess.
My take would be to use the highest possible level of abstraction that can meet your needs, and combine this with necessary steps down that take care of edge cases. I agree with knowing what is happening behind the scenes from the perspective of a nerd only. It is a red herring that will comprimise your productivity. Use the black box. Use the sdk/api. Skip the stuff that has been done already. Dig down further when necessary, nothing is stopping you. I remember trying to get websoxkets to work with javascript and PHP when I was a kid. I couldn't do it. The protocol is intentionally complicated to stop browsers/servers from using it accidentally. After becoming a pro, and learning about libraries, I had a working chat within a day. Sure, the library might not end up fitting my use case- in which the time spent on the library is wasted. But not knowing beforehand, the chances you will be taken care of are very high. Are there exceptions? Of course. And that's what makes the true engineer- someone who can address them when needed, who can learn about what is hidden by abstraction and be productive quickly.
I agree with most of what you have to say, and I'll even say that the languages I primarily work with are PHP, JS, Python, and even a bit of Java, so I can't speak for engineering with low level languages. I also wouldn't define myself as an engineer. I think you miss a lot of the point though, and that's business. Sure, for complex algorithmically heavy areas with a lot resource management needs you're going to need someone with a more computer science/software engineering background. But let's be real here, a lot of businesses are just using simple CRUD based applications that aren't really that resource heavy with more emphasis on UI/UX. I'd say that's the bulk of web development and mobile development right now. So backend frameworks with ORM's merged with frontend frameworks like React are going to accomplish everything a company needs for less. As much as it would be nice to write elegant beautifully performing apps, the reality is if you didn't use a framework the application would more than likely turn into a hot mess of egotistical devs trying to set opinionation standards to be followed by everyone else. Which is why the no framework movement, which rebels against the low code movement, rarely accomplished what was needed of it. I'm with you in spirit here, where I, a full stack dev mostly working frontend these days, see's over complication of front ends all of the time. Given I'm a backend dominant full stack developer, I'd personally prefer just laying html on the page with a little positioning. The problem is that these overly complicated frontends, that are built on resource heavy frameworks on top of a high level language, make for user experiences that the user wants without reinventing the wheel. It's a smart business decision. I'm not saying the business end of it is great. If the industry required the people that have software engineering/ comp science degrees to be used to the fullest, I'd either be out of a job or in a perfect world delegated enough time to learn more complex things. My personal opinion of all of this is just treat each thing as a tool and instead of reverting back to the lowest level to accomplish a task, know what tool is the best for it.
Imo that's continuation of principle "nationalize losses, privatize benefits", for a business it's easier to not bother with optimization and offload the price to buyer needing better hardware to run the app. It was also supported by hardware improving incredibly fast, so upgrading hardware was reasonable thing to do, and with hardware approaching physical limits and improvement slowing down, it might become more of a problem to businesses. Not really a problem if you only need a simple application, but with complexity increasing it'll become exponentially more expensive. We might even "go back" to using very specialized tooling for particular applications, like mainframes at their time. Don't know how much that'll affect most of the market though, as often all that's needed is a simple app, and there are patterns for building these. Maybe after all the bicycles are invented and it's a matter of choice and minor configuration changes.
To me no code is like saying we don't need to talk anymore, we just need gestures. Sure, it's much easier to learn, anybody can, but you lose a lot of fine detail. You can imagine a technology so abstract, you just tell it "build me a social media website". But now not only you don't know what happens at the CPU / memory level, which technology it uses, which architecture it invented, you also don't even know very high level specs anymore (what's the purpose of this website? How do we use it? How is it organized?). You'd be like, hey but that's not what I want though. This feature is useless. And so on. This already happens at a lower level. We use libraries, technologies, ... without understanding them, so you realise later that it's not really what you want (these objects don't get garbage collected, this function uses a slow algorithm etc) I think working at a lower level forces you to be confronted to the actual problems of your idea. Using abstractions without even understanding what is being abstracted is just ignoring the problems you're abstracting, which are still problems nonetheless!
I partly agree with this. I actually feel it a LOT, but at the same time, I feel like you kinda didn't address the tradeoff that we're actually getting from this. It's not that people are scared of the complexity -- or that's at least, not all of it -- there's also the fact that we're trying to create more and more complex systems with our technology, and we're struggling to find a general-purpose way of expressing those high-level goals. I don't think the problem is abstraction itself, so much as being too eager to abstract on top of abstract on top of abstract, rather than looking at the abstraction that's become standard and saying 'maybe we should fit some more functionality into this'. At this point, I feel like some technology sectors are actually harder to learn than if you were doing everything lower level, because a lot of the abstraction system should be flattened into a single more complicated abstraction rather than a bunch of 'simple' layers that are incredibly leaky and don't simplify anything but the simplest use cases. High level is good, but as you seemed to be saying, it is a balancing act. I just feel like you undervalue some of the pros here, that's all. But maybe that's my zoomer started-with-C++ brain talking. :P
I think ultimately, the need to abstract higher and higher level concepts is inevitable in a civilization where computers are becoming old tech -- becoming the foundations of how we do things. We just need to be more careful with how we're doing that. New technologies like Rust are, I think, a good example of how to do abstraction well -- looking at where it's actually needed, and building it from the ground up. A big part of the problem is that our programming industry is highly decentralized and disorganized. No one really decides what the final product of human civilization's codebase will look like -- we just work as individuals with what we have, or what we're paid to do, usually prioritizing short-term product goals and optimizing for that bottom line. It's tragedy of the commons. As a civilization, this has resulted in us being incentivized to make abstractions for smaller use cases that then get popularized to use cases that make less sense, and because no one wants to maintain another fork of a codebase they didn't write, and the original people who wrote it won't get paid more to add your use case to it, or a module system allowing it to cover more use cases. In a nutshell, I think the problem is that when we SHOULD be refactoring and retrofitting the code to fit new use cases, we often just throw an abstraction on top of it because it's much easier in the short term -- you don't have to touch anything inside of it. I wonder what sort of public policy could help to prevent this problem. Maybe publicly funded grants for code that serves common use cases? But ah, I don't know how well that'd work in practice. :P
I love your channel and waiting to hear everytime you post new content. Other than your channel which other links/channels do you recommend for backend engineering .
People write 2 lines of high level language code and consider job done, they dont know the efforts were put in back to write the liberary. Enterprises are driven to profit as long job is done , lines of code dont matter to them. Low code is just to get more work from a single employee..
I love SQL Server because the SQL profiler lets me look into exactly what queries Entity Framework is generating, which in turn gives me more confidence in that layer of abstraction. I’d have a hard time trusting that abstraction otherwise, but I guess that’s kind of what we all do with higher level languages lol
good one, I also like to go in deep towards this technologies, especially with database and operating system. but if we think In a freshmen or newbie point view they easily got burn-out when started with these low levels. I believe this low level skill will be on demand because of the infrastructure as a service
Also totally agree. This year I’ve started working as a software engineer, as an intern at the beginning, but recently, as a full time developer. I was working in two development teams throughout this time - first team was eager to use all high level features of spring boot, that hide many internal details. At first, I thought it’s really powerful, you may create services very quickly, but after some time, I’ve realized I know shit about “what is happening under the hood”. Second team has slightly different approach, they rather omit things that are hiding too much and I think this approach is much more healthier for a longer run.
abstraction without implementation is gateway for problem in future. i am having a constant running battle with a junior in the office that wants to use laravel without having the core knowledge of PHP.
Software development in general will get out of the Stone Age when low code tools implement Domain Specific Modeling for code generation. This has been used in enterprise software development for decades in a few tools that don't use UML, like MetaEdit, which is a legacy tool at this point. So I'd say a better visual notation based on better domain modeling is where software development is evolving. Right now the low-code tools are for simpler things, minus Wappler and Bildr for developers, which are still early in the so-called low-code ecosystem.
I hear what you say, but how about domain specific languages (DSLs). If a programming language was created to solve a business domain specific problem, it could possibly be low code, scalable, and efficient as long as it is contained within the real world business domain area it was designed for.
I think there are a few things being combined in the discussion about low/no code, and I think universally we can agree that: - low / no code has its place, but... - ideally the low / no code solution is flexible (i.e. not opinionated), because... - eventually the low / no code solution will have problems, and you don't want to be locked into it when you do It's like why I liked Flask over Django. The former abstracts away the boring and annoying stuff. The latter is bloated and opinionated, and good luck figuring out how to deviate off the intended path.
totally agree with you. the very fact of hiding the stuff is dubbed as "high level" made no sense to me. I feel assembly and c programming are high level as it requires high-level intelligence, practice and patience to work with😅. I always tell my students that learning C/C++ is the best to start with programming since it gives the complete picture. I advise them, you do what hell you want to do in the job, they may use wonderful abstracted languages in their backend but in my class you must suffer with this so that you may not suffer no more.
I see ORMs as the opposite of what you said. They are a way to get started on a prototype while I better understand the internal technology then I can move on to tuning the project to the performance requirements.
Nice video. But I think most backend engineers completely miss the point. The abstractions do help in the direction of having to "not know details" (at least upfront), but it's all about making the code language closer to t he product language so that the product can close the gap quickly and, therefore, evolve quickly.
Yeah man its an old topic and falls under a matter of preference, after C we could not really keep up with the abstractions, cause the compiler output was thousands of line of assembly just when you import something like stdio, and the binary was already on the millions of lines equivalent (The old guys would do some programming in binary in machines like EDSAC). A respectable back end engineer should at least be able to go deeper than most on some of these topics but even then your productivity will take a hit and at the rate in which computers keep progressing that might come a time where a single person can build an analogous "skyscraper" in software. As a back end engineer i think we are overestimating our usefulness, I can see the need for this job for the next 30-40 years, but even that might be a stretch .
@RAVI the point you did not understand (unfortunately) is: as a software engineer, whatever the tool you are using within you company or in your personnal project, you need to understand things how works behind the scenes, go in depth, this is what the author tried to draw your attention to but you stubornnely stuck in the idea that you need to reinvent everything.
Well, I guess the entire concept of software engineering rests on the basis on abstractions. Each developer will decide which layers of abstraction are relevant to them. Theoretically, a properly created layer of abstraction with exposed APIs should have its implementation details be unimportant to the user. However, in reality knowing implementation details is often times important. If a user spends all of their time learning the implementation, they will be less productive in their task. But always avoiding learning implementation results is a poor knowledge base.
One of the things I loved from the first College I went into to study Multimedia Engineering, is that they always teached us the low level details, sometimes even creating those abstractions in our own to understand them, and then we moved one layer of abstraction up. So even using abstractions, we learned the inner workings, and when needed we were able to change them.
I remember seeing someone's (Bjarne Stroustrup's?) phrase about levels of abstraction: it's designed like onion, you peel them off layer by layer and the more levels you peel off, the more you cry.
Totally agree. Learning C++, Data Structures and Algorithms totally opened my eyes to understanding how everything works.
This is the only channel where I have actually clicked the bell icon to make sure I always see your latest videos. Keep up the great work, Hussein!
At last, someone who understands my thoughts... Ive always thought that its important to know what's going on behind the scenes of each action when writing code
Man! Your back-end engineering show is awesome... keep it up!
Ok I very much agree with this. In the beginning I wanted things to be more abstract, now the more I know, the lower level I want to work at.
The thing about abstraction is that its built on top of objective reality, and that reality will always exist and will always be a consideration whether you like it or not. The more complex things you need to do the more that reality will come back to remind you of its existence.
I hadn't thought about what you said near the end though, that the people who have the most to gain from abstractions are the people that know the underlying systems and the abstractions inside out. Which is ironically the opposite of people using the abstractions because they don't want to know what's actually happening.
The funny thing is that I've been finding the lower-level stuff is actually easier to learn over all than the high level abstractions. Because you just need to learn how the computer works. If you know about how it works, if you know how to model data and if you understand algorithms then thats everything. You can now tackle any problem using the same tools. Compare this with an ever-changing and evolving set of convoluted frameworks and abstractions, some with little to no basis in anything actually going on under the hood. They might seem like less work and effort to get into, but in the long term the constant changing nature of those things, coupled with the headaches of debugging and having to push past what they are designed to do when you need more complex things, suddenly just sticking to lower level stuff becomes simple by comparison.
Interesting. In which use cases (examples) would low level be better than high level?
Totally agree! The first popular high level languages like Java allowed us to avoid the pain of working at a low level and focus on engineering business logic. Not to mention targeting multiple OS with the same codebase.
Even higher level languages like PHP, Javascript and Python allow us to prototype quickly or build web applications.
The low code idea is a gimmick. Just imagine all of the second by second tweaks and errors we make while building software. Think of all the possibilities of abstraction, interfaces, data structures and computation. Mathematical libraries, document generation, cryptographic functions. Now imagine trying to build a UI that allows users to build that same software without having to code. Now imagine allowing the same users to work at a low level, allocating memory and dereferencing.
We'd spend more time trying to debug the low code software than actually building anything.
Low code is good to quickly get internal apps out but you lose flexibility. As long people know what the tool is good for and what not it's great
Totally agree. The more I use Spark/Dask for data processing workflows, the more I I'm looking into making the core of the logic just in rust/CPP (and parallelise it via k8s). Leaky abstractions (Spark rdd/Dask df) make it a lot more problematic to manage memory requirements ESPECIALLY in highly distributed envs.
"Black box" is just a convenient excuse not to know what's going on in your own Business logic. That's dangerous
@jeff pentagon i did, it's fun but that is not the point.
In spark JVM takes ~300MB of ram from every executor regardless of executor's size. In workloads where I use > 2k executors it's starting to sum up.
I just feel like we could do exactly the same thing but much more efficiently. Modern cpp is memory safe enough, without the a need for a GC, to try it (not to mention rust).
@jeff pentagon I died!
@ whatever dude
In my experience -- within a restricted context (like you mention @18:45), well-designed low/no code systems can provide significant reduction in development effort with a manageable performance penalty. On the flip side, one does need to be alert to the pervasive and indiscriminate use of no/low code configurations. If used pervasively and indiscriminately, the system/application can quickly evolve into a "code-figuration" monstrosity -- i.e. an unwieldy and unsightly mess of configuration (declarative abstractions) that tries to mimic code (imperative abstractions), with the added "features" of poor performance and scalability. In other words you could end up with the worst of both worlds -- like the example that you mention of ORMs. Someone once said that ORMs are an example of taking two good technologies/paradigms in their own right (OO and RDBMS) and bringing them together to create a poor-performance and difficult-to-maintain mess.
My take would be to use the highest possible level of abstraction that can meet your needs, and combine this with necessary steps down that take care of edge cases. I agree with knowing what is happening behind the scenes from the perspective of a nerd only. It is a red herring that will comprimise your productivity. Use the black box. Use the sdk/api. Skip the stuff that has been done already. Dig down further when necessary, nothing is stopping you.
I remember trying to get websoxkets to work with javascript and PHP when I was a kid. I couldn't do it. The protocol is intentionally complicated to stop browsers/servers from using it accidentally. After becoming a pro, and learning about libraries, I had a working chat within a day. Sure, the library might not end up fitting my use case- in which the time spent on the library is wasted. But not knowing beforehand, the chances you will be taken care of are very high. Are there exceptions? Of course. And that's what makes the true engineer- someone who can address them when needed, who can learn about what is hidden by abstraction and be productive quickly.
I agree with most of what you have to say, and I'll even say that the languages I primarily work with are PHP, JS, Python, and even a bit of Java, so I can't speak for engineering with low level languages. I also wouldn't define myself as an engineer.
I think you miss a lot of the point though, and that's business. Sure, for complex algorithmically heavy areas with a lot resource management needs you're going to need someone with a more computer science/software engineering background. But let's be real here, a lot of businesses are just using simple CRUD based applications that aren't really that resource heavy with more emphasis on UI/UX. I'd say that's the bulk of web development and mobile development right now. So backend frameworks with ORM's merged with frontend frameworks like React are going to accomplish everything a company needs for less.
As much as it would be nice to write elegant beautifully performing apps, the reality is if you didn't use a framework the application would more than likely turn into a hot mess of egotistical devs trying to set opinionation standards to be followed by everyone else. Which is why the no framework movement, which rebels against the low code movement, rarely accomplished what was needed of it.
I'm with you in spirit here, where I, a full stack dev mostly working frontend these days, see's over complication of front ends all of the time. Given I'm a backend dominant full stack developer, I'd personally prefer just laying html on the page with a little positioning. The problem is that these overly complicated frontends, that are built on resource heavy frameworks on top of a high level language, make for user experiences that the user wants without reinventing the wheel. It's a smart business decision.
I'm not saying the business end of it is great. If the industry required the people that have software engineering/ comp science degrees to be used to the fullest, I'd either be out of a job or in a perfect world delegated enough time to learn more complex things. My personal opinion of all of this is just treat each thing as a tool and instead of reverting back to the lowest level to accomplish a task, know what tool is the best for it.
Imo that's continuation of principle "nationalize losses, privatize benefits", for a business it's easier to not bother with optimization and offload the price to buyer needing better hardware to run the app. It was also supported by hardware improving incredibly fast, so upgrading hardware was reasonable thing to do, and with hardware approaching physical limits and improvement slowing down, it might become more of a problem to businesses. Not really a problem if you only need a simple application, but with complexity increasing it'll become exponentially more expensive. We might even "go back" to using very specialized tooling for particular applications, like mainframes at their time.
Don't know how much that'll affect most of the market though, as often all that's needed is a simple app, and there are patterns for building these. Maybe after all the bicycles are invented and it's a matter of choice and minor configuration changes.
Congratulations for 10 million channel views
To me no code is like saying we don't need to talk anymore, we just need gestures. Sure, it's much easier to learn, anybody can, but you lose a lot of fine detail.
You can imagine a technology so abstract, you just tell it "build me a social media website". But now not only you don't know what happens at the CPU / memory level, which technology it uses, which architecture it invented, you also don't even know very high level specs anymore (what's the purpose of this website? How do we use it? How is it organized?). You'd be like, hey but that's not what I want though. This feature is useless. And so on.
This already happens at a lower level. We use libraries, technologies, ... without understanding them, so you realise later that it's not really what you want (these objects don't get garbage collected, this function uses a slow algorithm etc)
I think working at a lower level forces you to be confronted to the actual problems of your idea. Using abstractions without even understanding what is being abstracted is just ignoring the problems you're abstracting, which are still problems nonetheless!
I partly agree with this. I actually feel it a LOT, but at the same time, I feel like you kinda didn't address the tradeoff that we're actually getting from this.
It's not that people are scared of the complexity -- or that's at least, not all of it -- there's also the fact that we're trying to create more and more complex systems with our technology, and we're struggling to find a general-purpose way of expressing those high-level goals. I don't think the problem is abstraction itself, so much as being too eager to abstract on top of abstract on top of abstract, rather than looking at the abstraction that's become standard and saying 'maybe we should fit some more functionality into this'.
At this point, I feel like some technology sectors are actually harder to learn than if you were doing everything lower level, because a lot of the abstraction system should be flattened into a single more complicated abstraction rather than a bunch of 'simple' layers that are incredibly leaky and don't simplify anything but the simplest use cases.
High level is good, but as you seemed to be saying, it is a balancing act. I just feel like you undervalue some of the pros here, that's all. But maybe that's my zoomer started-with-C++ brain talking. :P
I think ultimately, the need to abstract higher and higher level concepts is inevitable in a civilization where computers are becoming old tech -- becoming the foundations of how we do things.
We just need to be more careful with how we're doing that. New technologies like Rust are, I think, a good example of how to do abstraction well -- looking at where it's actually needed, and building it from the ground up.
A big part of the problem is that our programming industry is highly decentralized and disorganized. No one really decides what the final product of human civilization's codebase will look like -- we just work as individuals with what we have, or what we're paid to do, usually prioritizing short-term product goals and optimizing for that bottom line. It's tragedy of the commons.
As a civilization, this has resulted in us being incentivized to make abstractions for smaller use cases that then get popularized to use cases that make less sense, and because no one wants to maintain another fork of a codebase they didn't write, and the original people who wrote it won't get paid more to add your use case to it, or a module system allowing it to cover more use cases.
In a nutshell, I think the problem is that when we SHOULD be refactoring and retrofitting the code to fit new use cases, we often just throw an abstraction on top of it because it's much easier in the short term -- you don't have to touch anything inside of it.
I wonder what sort of public policy could help to prevent this problem. Maybe publicly funded grants for code that serves common use cases? But ah, I don't know how well that'd work in practice. :P
I love your channel and waiting to hear everytime you post new content. Other than your channel which other links/channels do you recommend for backend engineering .
People write 2 lines of high level language code and consider job done, they dont know the efforts were put in back to write the liberary.
Enterprises are driven to profit as long job is done , lines of code dont matter to them.
Low code is just to get more work from a single employee..
Hussein, u should try GOLang!
I feel the same as you.
I think that Rust is a very good option to be more close to the machine again
I love SQL Server because the SQL profiler lets me look into exactly what queries Entity Framework is generating, which in turn gives me more confidence in that layer of abstraction. I’d have a hard time trusting that abstraction otherwise, but I guess that’s kind of what we all do with higher level languages lol
Yup. Profiles and debuggers attached everywhere for me, all the time.
good one, I also like to go in deep towards this technologies, especially with database and operating system. but if we think In a freshmen or newbie point view they easily got burn-out when started with these low levels. I believe this low level skill will be on demand because of the infrastructure as a service
great content man! keep it up!
Also totally agree. This year I’ve started working as a software engineer, as an intern at the beginning, but recently, as a full time developer.
I was working in two development teams throughout this time - first team was eager to use all high level features of spring boot, that hide many internal details. At first, I thought it’s really powerful, you may create services very quickly, but after some time, I’ve realized I know shit about “what is happening under the hood”.
Second team has slightly different approach, they rather omit things that are hiding too much and I think this approach is much more healthier for a longer run.
abstraction without implementation is gateway for problem in future. i am having a constant running battle with a junior in the office that wants to use laravel without having the core knowledge of PHP.
Software development in general will get out of the Stone Age when low code tools implement Domain Specific Modeling for code generation. This has been used in enterprise software development for decades in a few tools that don't use UML, like MetaEdit, which is a legacy tool at this point. So I'd say a better visual notation based on better domain modeling is where software development is evolving. Right now the low-code tools are for simpler things, minus Wappler and Bildr for developers, which are still early in the so-called low-code ecosystem.
Thanks Hussein
I hear what you say, but how about domain specific languages (DSLs). If a programming language was created to solve a business domain specific problem, it could possibly be low code, scalable, and efficient as long as it is contained within the real world business domain area it was designed for.
I think there are a few things being combined in the discussion about low/no code, and I think universally we can agree that:
- low / no code has its place, but...
- ideally the low / no code solution is flexible (i.e. not opinionated), because...
- eventually the low / no code solution will have problems, and you don't want to be locked into it when you do
It's like why I liked Flask over Django. The former abstracts away the boring and annoying stuff. The latter is bloated and opinionated, and good luck figuring out how to deviate off the intended path.
We use PEGA in our company, It's a low code platform.
totally agree with you. the very fact of hiding the stuff is dubbed as "high level" made no sense to me. I feel assembly and c programming are high level as it requires high-level intelligence, practice and patience to work with😅. I always tell my students that learning C/C++ is the best to start with programming since it gives the complete picture. I advise them, you do what hell you want to do in the job, they may use wonderful abstracted languages in their backend but in my class you must suffer with this so that you may not suffer no more.
Do a crash course on Aeron
I see ORMs as the opposite of what you said. They are a way to get started on a prototype while I better understand the internal technology then I can move on to tuning the project to the performance requirements.
The matter is not simple need more discussion.
With more explorations and research.
Problems don't get simpler simply because of the interface to solve the changes.
There is already something like this that has been running businesses for decades. It's all based on Excel! Better tools can only improve things.
Nice video. But I think most backend engineers completely miss the point. The abstractions do help in the direction of having to "not know details" (at least upfront), but it's all about making the code language closer to t he product language so that the product can close the gap quickly and, therefore, evolve quickly.
this is why ppl like u have to make better abstractions for us :p
Very nice
I appreciate you very much, Hussein. Do you have a video where you mention a list of must-learn concepts to learn about DBs?
Yeah man its an old topic and falls under a matter of preference, after C we could not really keep up with the abstractions, cause the compiler output was thousands of line of assembly just when you import something like stdio, and the binary was already on the millions of lines equivalent (The old guys would do some programming in binary in machines like EDSAC). A respectable back end engineer should at least be able to go deeper than most on some of these topics but even then your productivity will take a hit and at the rate in which computers keep progressing that might come a time where a single person can build an analogous "skyscraper" in software. As a back end engineer i think we are overestimating our usefulness, I can see the need for this job for the next 30-40 years, but even that might be a stretch .
Hey Hussein I am starting on backend engineering, Can you suggest me some books on networking and databases.
Designing data intensive applications
@@Kekszmester Thanks man 👍
@@Kekszmester and any on networking stuff?
@@muhammadsami479 I only read networking in go. It was great
@@Kekszmester Thank you👍
Apps are no code solutions, you just abstracted your code as an app
Security too
You can have scalable, performant and three lines of specification all together but our AI isn't there yet.
What you think about Salesforce and their declarative tools to implement data manipulation and processes?
Nice for basic sales process automation which is what it was originally designed for. The more you get outside that sweat spot the worse it gets IMO.
@@clouddeveloper4549 Most definitely. It's getting better though especially in the Support Service and Marketing space.
And there is tailwind css as well😅
Well, not C but Rust.
I hate JS....
Syntax is wierd not suitable for large apps from my stand point..
In time people will loose their skill and get rusted..
You don't know what you don't know, can you be specific and review some tools?
This guy want me to write a database, load balancer, and may be an ALU unit on semiconductor level for an todo app which my client might not use.
you are missing the point
@RAVI the point you did not understand (unfortunately) is: as a software engineer, whatever the tool you are using within you company or in your personnal project, you need to understand things how works behind the scenes, go in depth, this is what the author tried to draw your attention to but you stubornnely stuck in the idea that you need to reinvent everything.
The whole idea that he discussed just passed through your head. lol
@@mohamedyassinesoubki6178 I do understand what he is saying, but what he is saying not practical all the time
@@mohamedyassinesoubki6178 Yes! and that's how a software engineer can become a hacker by knowing how things work from scratch
Watch this man at 1.7x and it will become less painful
ty
even x2.5 does not help, noise/signal ratio is way too low and all videos I tried rather are a brain dump with no structure/system behind it. Torture.
you don't need to do that, just leave if you are not interested
Go touch grass or something
I don't know, it seemed fine to me. Brain dumps are fine to listen to sometimes, and he has a nice voice :)
Spit it out man! Gave up already!