There was a reddit post where a guy asked what to use to build a website that contains a few static pages. The answers were a laundry list of frameworks. But what do I expect from a react sub...
A lot of SWEs don't interact with Hardware anymore and many go decades thinking the GPU, Ethernet port, CPU, etc. works like magic. I've seen quasi religious articles on these things and people being impressed with mundane things. Here's a little exercise for you, build an Ethernet frame and send it through a raw socket. No TCP no framework. It's not as hard as you think it is. Then try to create your own network protocol.
Dude who are you ?? Like what do you do that is extremely impressive am 22 and I am still struggling with fundamentals ..started doing dsa in C because I realised I really need to understand those fundamentals and I have built a miniature git , this is an impressive suggestion here ....would love to know what you do further and how your journey to here was like
Great video, we need to understanding frameworks to make living, cause a lot of job offers demand them, but we need to have deeper knowledge about ghe fundamentals. Based on this i started my own journey to solidify my SWE knowledge before the wave of the AI.. THANKS FOR SHARING!
@@dekev7503I didn’t get a degree in CS and I was self taught and I am now working for 4 years now as a software engineer at IBM. Not sure what you’re talking about
@@user-ze9tj9yj4t Good for you, but that’s besides the point. Of course there are self taught programmers working on various parts of different projects doesn’t make y’all engineers any more than working on the wiring of a car makes an electrician an automobile Engineer🤷🏼♂️.
TBH I don't enjoy this hype. It is not the first time " is going to make software engineers obsolete" Kinda tired of this statements. And I would agree with what "Pragmatic engineer" Gergely wrote on X that this hype targets non-tech folks promising cheep replacement of software engineers. And they believe.
I agree, it is important to know that nothing happens magically and you should learn this deep knowledge to a certain extent. The problem I have with it is that you can't remember everything, for instance if in an interview they ask you to describe Boole algorithms it starts to loose it's purpose since this knowledge is so common in development that it is instinctively known without even knowing what Boole algorithms is. Same for principle like SOLID, you can totally grasp the concept without knowing how to describe each letter, I think that we expect developers to remember too much knowledge.
Interview questions is actually different problem in Tech industry. Some interviewers just copy-paste questions without understanding how they connected to the work itself, even the questions about CS. And they don't understand what they evaluating with specific questions. E.g., I am not going to ask about trie from an iOS engineer just because it's mostly not used there, but I would ask more algorithmic questions to Graphics engineer. That what I usually trying to follow when I need to create interview questions: they should cover foundational knowledge as well, but connected to actual requirements. And it's not an easy task actually.
@@roman_v_code Yes you're right it can be hard to create good interviews questions for a role, my point is we shouldn't devaluate competences of a developer based on a lack of knowledge if he knows how to fulfill requirements, sometimes foundational knowledge can be unknowingly learnt. My view on this is not related to programming world only, I had to struggle with this during my studies, in traditional education, the focus were so much on accumulating knowledge rather than applying it to create or achieve something meaningful. I think that being wrong because we didn't learn by heart a complex knowledge even if the end result fully meets the requirements is counter productive.
Sure, deep knowledge is great, but you have to pick and choose your battles. You can't just keep peeling the layers of the onion until infinity, you'll never get anything done that way. I can use goroutines correctly and build apps, without knowing that paper and how they're implemented under the hood. A great baker doesn't need to know the chemical structures of flour or the ingredients he uses or how his oven is engineered to bake good bread.
It does not mean you should learn all deep knowledge before you can make something. I don't know all the stuff for sure, but I always continue to dig deeper and learn more. It always pays off.
@@roman_v_code Off course, I totally agree. My point is that you should know when to unpack something for deeper understanding and when you should just use the abstraction or the API and move on.
@@d_andreev The problem is, people aren't even learning the APIs they're leveraging; they're trying to minimize as much engagement with the API and its docs and abstraction model as much as possible. And what's even worse is, they're bringing this same approach to their *own* team's project! Trying to speedrun their onboarding and trying to learn as little as possible of the surface area of the project so they can jump in, make a change with no knowledge of its context, thrash around a bit on inevitable trivial bugs, and then jump out. And they take no interest in having any information become part of their long term memory, and just repeat this process continuously, becoming "Expert Beginners" with absolutely no depth to their technical ability. No one's saying you need to become an expert in digital circuit design to program. But we're doing the equivalent of a med student never learning either anatomy or any of the surgical instruments, and then in their first surgery grabbing a picture from Google Images of the anatomy of the hand, going "eh that seems straightforward enough", cobbling together a messy fix, and then calling it a day and will do the same for someone's leg the next day.
Most programmers pick as few battles as possible and are expecting the same paychecks. So often the teams get bigger, but they're all juniors. As a result they're not completing projects, they're being let go, and the jobs are drying up or going overseas. Every company I consult for is going overseas and hiring only juniors. I see very few great bakers in the programming world, but they've moved to very specific high paying jobs or started new ventures.
Because now job demands a programmer to know 1000+ skillsets. If he can live for 2000 years and be slave of work only then he can has 1000+ deep knowledge
Not really. You can be specialised in one thing, but have a wide range of additional knowledge. The problem that some devs do not go deeper for the things they are specialising. Of course you cannot know everything deep, that is impossible. but it does not mean you should not go deeper into stuff you work with daily.
my best experience was when i wrote backend web framework in python using wsgi. turns out it wasnt really hard. it made me learn that micro frameworks are all you need. if it doesnt fit you make your own :D highly abstracted full frameworks are good in some specialised things, but suck at other things, because you need to use workarrounds to achieve those other things. and those workarrounds dont integrate with the rest of the framework so you end up banging your head.
Agree. Frameworks usually very opinionated and you need to choose them carefully for your needs. Otherwise you could get into situations of too many hacks
В какой-то момент появилось очень много "обучающих курсов" типа "за 3 месяца вы начнете зарабатывать миллионы". И я видел достаточно людей кто после таких курсов не сильно то хотели учиться дальше, а на этих курсах на самом деле далеко не уедешь. А им обещали после курсов получать зарплату senior разработчика. Никто же не предлагает курсы хирурга за 3 месяца :) Мы, к счастью, людей не лечим, но знаний надо набрать для работы в дОлгую
Deep knowledge would require learning computer circuitry, binary, assembly and the implementation of every single library you use, and the libraries that does libraries use, and so on. I say it is sufficient to understand what every command you use does.
I m so curious I left all high level stuff and I stick only with C and Assembly Because now the tech industry provides so many abstraction that’s hide the essence of how the real thing work under the hood And it I’ll be difficult for the next gen to understand …
I would not discard high level stuff at all. There is always a right tool for something, so I personally would not go like only C and Assembly. At least for commercial software development. It is always a tradeoff.
I left "the web" behind for non-technical reasons. To be precise, the half hour time zone "software" "developers", the piles of garbage they create, the balls of mud they roll, the managers that keep them, etc. And got back to my C.
@@roman_v_code AI tools can produce inefficient code and weaken problem-solving skills if relied on too heavily. Without a solid understanding of the basics, problems often arise when debugging or modifying the code. For instance, using a recursive Quicksort implementation without understanding concepts like stack overflow or optimizations can lead to issues, particularly when scaling or deploying the code in production.
Without deep knowledge your program is not based in reality anymore. I see many developers work-shipping design patterns as the only true meaning to have happy developers after life. SOLID, KISS, Design patterns, look at the people that promotes it, you are in a SECT and your a just a follower that never questions if there is no other way that is better? What makes you think that your product is actually useful? Yes you shipped it, but could be complete garbage. Good developers can create tools out of nothing when they need to. To fix broken projects we need to create new code that does not exist on the internet to create bridges between the badly developed code. We can only do that when we have deep knowledge.
There was a reddit post where a guy asked what to use to build a website that contains a few static pages. The answers were a laundry list of frameworks. But what do I expect from a react sub...
@@Max-zs6cj 😂😂 yeah, that was an incorrect place to ask
Squarespace lmao, it will be up in 5 minutes
A lot of SWEs don't interact with Hardware anymore and many go decades thinking the GPU, Ethernet port, CPU, etc. works like magic. I've seen quasi religious articles on these things and people being impressed with mundane things.
Here's a little exercise for you, build an Ethernet frame and send it through a raw socket. No TCP no framework. It's not as hard as you think it is. Then try to create your own network protocol.
Dude who are you ?? Like what do you do that is extremely impressive am 22 and I am still struggling with fundamentals ..started doing dsa in C because I realised I really need to understand those fundamentals and I have built a miniature git , this is an impressive suggestion here ....would love to know what you do further and how your journey to here was like
sounds like a Wednesday in embedded :P perhaps not every Wednesday, but pretty close to the second Wednesday of every month :D
I agree 100% with you sir. Greetings from DR.
hey! thanks for watching 🙂
Programmers without deep knowledge will be re'laced by AI
Great video, we need to understanding frameworks to make living, cause a lot of job offers demand them, but we need to have deeper knowledge about ghe fundamentals.
Based on this i started my own journey to solidify my SWE knowledge before the wave of the AI..
THANKS FOR SHARING!
@@MohcinBounouara-rx1wz nice! 👍🏻
@@MohcinBounouara-rx1wz thanks for watching 🙂
if you use framework you can deep knowledge in framework. learn fundamental of framework.
This is why I get so annoyed when programmers and software developers refer to themselves as software Engineers
Can you explain the difference just for knowing what steps I need to take to become a engineer,
thankyou
@ go to college and get an actual Engineering degree ( or at least a CS degree). Boot Camp and self study wouldn’t teach you nearly enough.
@@dekev7503funny you would say that, Engineering /CS degree won’t teach you nearly enough as well, most of things you learn on the fly
@@dekev7503I didn’t get a degree in CS and I was self taught and I am now working for 4 years now as a software engineer at IBM. Not sure what you’re talking about
@@user-ze9tj9yj4t Good for you, but that’s besides the point. Of course there are self taught programmers working on various parts of different projects doesn’t make y’all engineers any more than working on the wiring of a car makes an electrician an automobile Engineer🤷🏼♂️.
@Roman V - Not only did Tony Hoare write the CSP paper, he also developed the quicksort algorithm.
thanks :)
AI generated code is huge. .
Good devs will be in demand to fix issues in future..
Just enjoy the hype now
TBH I don't enjoy this hype. It is not the first time " is going to make software engineers obsolete"
Kinda tired of this statements. And I would agree with what "Pragmatic engineer" Gergely wrote on X that this hype targets non-tech folks promising cheep replacement of software engineers. And they believe.
I agree, it is important to know that nothing happens magically and you should learn this deep knowledge to a certain extent.
The problem I have with it is that you can't remember everything, for instance if in an interview they ask you to describe Boole algorithms it starts to loose it's purpose since this knowledge is so common in development that it is instinctively known without even knowing what Boole algorithms is.
Same for principle like SOLID, you can totally grasp the concept without knowing how to describe each letter, I think that we expect developers to remember too much knowledge.
Interview questions is actually different problem in Tech industry. Some interviewers just copy-paste questions without understanding how they connected to the work itself, even the questions about CS. And they don't understand what they evaluating with specific questions.
E.g., I am not going to ask about trie from an iOS engineer just because it's mostly not used there, but I would ask more algorithmic questions to Graphics engineer.
That what I usually trying to follow when I need to create interview questions: they should cover foundational knowledge as well, but connected to actual requirements. And it's not an easy task actually.
@@roman_v_code Yes you're right it can be hard to create good interviews questions for a role, my point is we shouldn't devaluate competences of a developer based on a lack of knowledge if he knows how to fulfill requirements, sometimes foundational knowledge can be unknowingly learnt.
My view on this is not related to programming world only, I had to struggle with this during my studies, in traditional education, the focus were so much on accumulating knowledge rather than applying it to create or achieve something meaningful.
I think that being wrong because we didn't learn by heart a complex knowledge even if the end result fully meets the requirements is counter productive.
Sure, deep knowledge is great, but you have to pick and choose your battles. You can't just keep peeling the layers of the onion until infinity, you'll never get anything done that way.
I can use goroutines correctly and build apps, without knowing that paper and how they're implemented under the hood. A great baker doesn't need to know the chemical structures of flour or the ingredients he uses or how his oven is engineered to bake good bread.
It does not mean you should learn all deep knowledge before you can make something. I don't know all the stuff for sure, but I always continue to dig deeper and learn more. It always pays off.
@@roman_v_code Off course, I totally agree. My point is that you should know when to unpack something for deeper understanding and when you should just use the abstraction or the API and move on.
@@d_andreev The problem is, people aren't even learning the APIs they're leveraging; they're trying to minimize as much engagement with the API and its docs and abstraction model as much as possible. And what's even worse is, they're bringing this same approach to their *own* team's project! Trying to speedrun their onboarding and trying to learn as little as possible of the surface area of the project so they can jump in, make a change with no knowledge of its context, thrash around a bit on inevitable trivial bugs, and then jump out. And they take no interest in having any information become part of their long term memory, and just repeat this process continuously, becoming "Expert Beginners" with absolutely no depth to their technical ability.
No one's saying you need to become an expert in digital circuit design to program. But we're doing the equivalent of a med student never learning either anatomy or any of the surgical instruments, and then in their first surgery grabbing a picture from Google Images of the anatomy of the hand, going "eh that seems straightforward enough", cobbling together a messy fix, and then calling it a day and will do the same for someone's leg the next day.
Most programmers pick as few battles as possible and are expecting the same paychecks. So often the teams get bigger, but they're all juniors. As a result they're not completing projects, they're being let go, and the jobs are drying up or going overseas. Every company I consult for is going overseas and hiring only juniors. I see very few great bakers in the programming world, but they've moved to very specific high paying jobs or started new ventures.
@ yeah. I don’t think that not going for new challenges is the way to go
Because now job demands a programmer to know 1000+ skillsets. If he can live for 2000 years and be slave of work only then he can has 1000+ deep knowledge
Not really. You can be specialised in one thing, but have a wide range of additional knowledge.
The problem that some devs do not go deeper for the things they are specialising. Of course you cannot know everything deep, that is impossible. but it does not mean you should not go deeper into stuff you work with daily.
abstractions are the enemy of deep knowledge
But they make development easier and fast.
@@UNMEASURED100 it depends. Average mid-size Java codebase is an abstraction hell that is hard to navigate long-term. But in some cases it could help
no they aren't
Yes, it tends to be this way.
How can you get that deep knowledge without abstraction?
my best experience was when i wrote backend web framework in python using wsgi. turns out it wasnt really hard.
it made me learn that micro frameworks are all you need. if it doesnt fit you make your own :D
highly abstracted full frameworks are good in some specialised things, but suck at other things, because you need to use workarrounds to achieve those other things. and those workarrounds dont integrate with the rest of the framework so you end up banging your head.
Agree.
Frameworks usually very opinionated and you need to choose them carefully for your needs.
Otherwise you could get into situations of too many hacks
Кажется основная проблема в том, что глубокое познание базы не приносит деньги в моменте, поэтому начинающие разрабы могут её пропускать
В какой-то момент появилось очень много "обучающих курсов" типа "за 3 месяца вы начнете зарабатывать миллионы". И я видел достаточно людей кто после таких курсов не сильно то хотели учиться дальше, а на этих курсах на самом деле далеко не уедешь. А им обещали после курсов получать зарплату senior разработчика.
Никто же не предлагает курсы хирурга за 3 месяца :) Мы, к счастью, людей не лечим, но знаний надо набрать для работы в дОлгую
We're using things much older than that. You need to see the old math papers ^_^
I am not surprised by this anymore :D
Deep knowledge would require learning computer circuitry, binary, assembly and the implementation of every single library you use, and the libraries that does libraries use, and so on. I say it is sufficient to understand what every command you use does.
And the chemistry of how the logic gates work at the molecular level.
Just play Zachtronics games
never heard about that. Quickly checked, seems interesting!
They are the best. I think I own every one. Definitely created to cater to programmers.
hey you stole my bitmoji lol
haha😃
I m so curious I left all high level stuff and I stick only with C and Assembly
Because now the tech industry provides so many abstraction that’s hide the essence of how the real thing work under the hood
And it I’ll be difficult for the next gen to understand …
I would not discard high level stuff at all. There is always a right tool for something, so I personally would not go like only C and Assembly. At least for commercial software development. It is always a tradeoff.
I left "the web" behind for non-technical reasons. To be precise, the half hour time zone "software" "developers", the piles of garbage they create, the balls of mud they roll, the managers that keep them, etc. And got back to my C.
Javascript is the definition of shallow programming...
well, there are some good part in JS :) But I would not start learning development from JavaScript, too much things it can taught you wrong
Do we really need deep knowledge? We can just give prompt to AI what we need, pack things and ship the product.
But can you really? I still do not see these examples for something more complex than simple website with 3 pages
and the code "AI tools" produce is not maintainable long-term
Yh that has never worked. You'll hit the wall pretty quickly with AI.
@@roman_v_code AI tools can produce inefficient code and weaken problem-solving skills if relied on too heavily. Without a solid understanding of the basics, problems often arise when debugging or modifying the code. For instance, using a recursive Quicksort implementation without understanding concepts like stack overflow or optimizations can lead to issues, particularly when scaling or deploying the code in production.
Without deep knowledge your program is not based in reality anymore. I see many developers work-shipping design patterns as the only true meaning to have happy developers after life. SOLID, KISS, Design patterns, look at the people that promotes it, you are in a SECT and your a just a follower that never questions if there is no other way that is better?
What makes you think that your product is actually useful? Yes you shipped it, but could be complete garbage.
Good developers can create tools out of nothing when they need to. To fix broken projects we need to create new code that does not exist on the internet to create bridges between the badly developed code. We can only do that when we have deep knowledge.