Knowledge Transfer

Recorded live on twitch, GET IN

Become a backend engineer. Its my favorite site

This is also the best way to support me is to support yourself becoming a better backend engineer.

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))

[franciscoerramuspe]

Dude how is it possible that every single one of your shorts gives better advice than 99% of tech content in social media

[invrtd]

That's true for any field where knowledge is shared, not just software engenering.

[salarsan]

There are two proverbs for this:
- "A master has failed more times than the beginner has tried."
- "Ever tried. Ever failed. No matter. Try again. Fail again. Fail better."

[LaerteBarbalho]

My dude is typing while his hands are in the air. That's a true pro developer.

[MarcusVeres]

“An expert is a man who has made all the mistakes which can be made, in a very narrow field.” - Niels Bohr ⚛️

[AlanChunkyMunky]

You also literally just described being an artist in the entertainment industry. I always explain to students how the concepts and principles feel like fog in a dark room. We think we understand it but we can’t really grasp it, measure it, etc. just gotta keep trudging through until the fog becomes tangible and something you can actually use

[OnepieceIsMine]

Thanks man for sharing these videos, helps me a lot to understand this industry better.
Thank you again❤

[RegularNobody]

You, my dude, just described not only software engineering, but all possible skills out there. Every single one of them.
Knowing what to do is good; knowing *why* you need to do what you need to do is a whole other container of worms.

[SiiKiiN]

I’ve also considered the fact that software knowledge communication exists at a higher abstraction level than any programming language. What basically happens is that we define these rules such as, solid, dry, clean, which are more of a learned heuristic than true linguistic devices. Single responsibility is a word which as defined is concrete but in the context of programming, it’s a abstract tool which really only communicates what I would call “the pointer” to the heuristic rather than the actual value stored at the pointer which would be a longer possibly book length explanation.

[lightleviathan]

he... replaced subway surfers and south park clips with programming

this is why prime is the goat

[victorwidell]

It is great when you are struggling with something to find out others have had the same issues, and have taken the time to articulate exactly why the issue arises and what is a good solution.

Then you can understand the issue and apply the solution sensibly.

[sorcdk]

A lot of the problem comes down to not understanding what advice is actually good, and when it makes sense to use it, until you have actually tried them out and experience the kinds of problems they lead to, and seen the problems that some of them can resolve.

[nasrihaithem]

Im getting alot of shorts of this Dr disrespect the programmer, and i dont mind it

[Rafaelito]

That's so true... 10 years after just now I'm being able to apply stuff I was taught in Jr years. That's usually how it goes, except for super smart people

[felixbertoni]

CS teacher here, and let me both agree and disageee with this.

The main problem is that software engineering is a complex field, and often "good design" as single responsibility principle are introduced with minimal examples which hides the complexity, and therefore makes the design not needed, if not counterproductive.

Take for example SRP mentioned above, one of the basics of software design, but if my software is 100 lines long, having two specialized classes or a single multipurpose one will not make a big difference. Having two classes could even be less efficient in that case.

But still, knowledge communication is really important, as, done the right way, it saves a shitload of time by not having to rediscover the wheel.

One mistake we often make is to introduces design principles as principles, and not as solutions to a problem. "Each class in a software shall be responsible of a single thing, and exclusively responsible of it". Could be a principle-formulation of the SRP. A problem-formulation could be more "To make the software easier to modify (<- the problem), I want that if I were to change an atomic aspect of the software specifications, I would only need to edit a single atomic component of the software. In order to do so, each component shall be exclusively responsible of an atomic aspect of specifications." Of course this formulation is imperfect, since it would require examples, but it gives an insight of the "whyyyy". Then of course, experience will help better define things, as for examp'e what should be considered atomic or not, but when the person encounters the problem of making the software easier to edit, the to the solution is clearer.

[liquidvapour]

This is why teamwork, mentoring, pairing, and plenty of space to fail is soo important

[razzak]

So true, i know that I need to improve my understanding of open/closed principle

[LearnValkey]

Single responsibility principle in a nutshell: this function handles payments only.

[sylvereleipertz]

With good exemples, showing you the path that leads to the problem first and only then the solution to that problem, you can still get things.

[ItsMrEzzy]

It's like something I came to realize lately..

To become good, you have to be bed first.. you cannot be good in an instant (especially in programming), do your best, first times are always bad.. then you get better.. it's okay, you write code, beginner junior code.. it's okay, you fail, you fail, you fail.. it's okay.. THEN you get good, you get better, you get smarter, only THEN you become an expert..