Hey folks, I just wanted to add a quick few things to make the goal of the video a bit clearer: I present these topics as guidelines, not hard rules. I call them "sins" but in reality, there's exceptions to everything and your situation may not need all the topics covered. I've seen people who over-engineer simple codebases to the point it's unreadable, just to have it fully modular; or obsess over following standards, even when it becomes incompatible in certain situations; or spending way too much time trying to achieve 100% test coverage, when it added no more benefit to do so. The best way to interpret this video is to have a little understanding of the topics, and choose the things that you want to learn more about. The 80/20 rule is usually pretty good to combine with all these points. Everything mentioned in the video once had a pain point behind it that will have led to its creation, but maybe you don't have these same pain points... yet! Just remember the potential solutions for when you do, or use them as a foundation for your own exploration! Hope this clarifies a bit! --- Oh, and thank you so much for all the kind comments! I'm reading every single one with a smile. Your feedback means a lot and I am really excited to get back to creating more videos for you all.
I love this added comment, as after watching the video I was pretty afraid people might fall in the trap of dogmatically following principles like SOLID like they are 10000% must does. However, after being frustrated with engineers creating interfaces for everything, every time, everywhere I had began to do a ton of research, there had to be a better way. And for my sanity I found one. Having always been the type to make things work first, and make things better later, Test Driven Development was an eye opener, and I suddenly began to see you don't need interfaces everywhere, nor do I need to mock everything (yey Sociable Tests!). What I really learned doing TDD is that after you get things to work, and backed by (behavioral) tests, refactoring is fun, and useful patterns and practices come to the surface quickly. I can really suggest to people to learn TDD, even if you don't like it, if only to get more insight in when to apply practices and patterns better and avoid the trap that I like to call "Cargo Cult Programing", applying patterns and practices without considering their usefulness in your specific problem domain. For anyone interested in what testing without mocks looks like, search for James Shore here on UA-cam, he has a bunch of great video's explaining it with some fun projects.
I think "don't follow rules blindly" also deserves a place as advice - understanding why some best practices exist and when they make no sense is important. There are valid exceptions to everything.
Exactly, without any context these principle, rules or patterns makes no sense. This sometime leads to over-engineered solution which is not that useful for the business.
Definitely. I started work as a software dev about 6 months ago and I'm trying to improve our product by following coding standards and general guidelines from the C++ community. But I don't apply anything until I've researched it enough to understand it myself and explain it to others.
Generally agreed, on the other hand - when breaking a "rule" (guideline, established practice) it's best if you know how it works, why it's there and what are the tradeoffs; at which point you probably don't need a guide/video to tell you that.
Agreed. I enjoy this style. As a future UA-cam feature, I wish there was a button for the background music track on videos, so I could switch it off when I want to. Background music can be very distracting.
Channels are popping up with extremely high quality content like it's nothing and it makes me happy. By quality I'm not talking only about the very professional animations, but the actual information as well. As a CS student I was familiar to most of what you said, but the video just sealed all this info together in a way that made think about this stuff and become a lot more confident. The examples were well chosen too.
For real! This channel, CodeAesthetic and ByteByteGo makes the best programming content I've ever seen on UA-cam and they've all popped up in the last year
I remember a dev once said that development is never straightforward, and so the team ends up meandering as if they were following a series of semicircles, which is why they plan for everything to take 3.142 times as long as expected.
I seem to remember seeing a video about a paper that discussed projects in corporate settings tending to take e times as long as expected. Another reason why pi=e=3
I've been programming for 12 years now.. this perfectly articulates what I've been subconsciously been leaning towards as time goes on. I've heard about all of the concepts in this video but never in this way. These principles truly are fundamental measurements of ones proceffiency in code. One thing I will mention though is the concept I personally use with larger programs. When I am facing a large system, I will typically prototype smaller bits of code in a way that "just works." After I get my concept I have in my mind in front of me, I then begin to refactor and abstract the code into a state that is to, in my eyes, what is described in this video. In my game engine I've been working on over the past few years I started off by just getting things going like a window, simple rendering with shaders etc. Eventually over time I separated out the project in modules that hook the engine for state changes. The core engine eventually just became a bootstrapper for modules like an Asset module, and other modules could depend upon modules within their module.lua file (custom build system), and I had I things like abstract modules where a render backend could be opengl or directx, where there would be an abstraction module that provides common rendering functionality, allowing modules that need to render something to just require the abstract render module and let the runtime render module handle the rest. TL;DR sometimes its okay to just "get your idea out" with some working prototype, then chip away/refactor as you would with a beautiful marble sculpture; apply the principles presented in this video as a form a improvement overtime instead of must-have requirements from the get-go. Principles such as standards should always be followed in my opinion however.
"In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow.". Fred didn't mean it literally, but on a functional level. If you're doing something new, odds are you wont DoItRight straight away, no matter how much analysis you throw at it. So might as well GetItDone, go over it figuring everything that is wrong, then DoItRight, or as close as possible. At this stage in the process, refactoring is counter productive IMHO, as you don't have a "code block level" issue, you have a Systems Architecture issue. Reuse maybe, refactor not so much. Assuming v2 went well, you can now just refactor/rework, and bar some fundamental change, things should sail along quite ok, even if not optimal. Most (legacy) nightmares are from systems that didn't Throw One Away, because (business) reasons. And they carry all that bad SA into the future. At that point, any refactoring/patterning you throw at it is just "reshaping" a fundamentally wrong thing. Funny thing, if/when they do decide to do it anew, they don't use the old one as "reference" and just start working one the new one, with zero intention of throwing the prototype away. Wash, rinse, repeat.
Was reading a Haskell book “Abstractions in Context”. The author suggested that if your initial design/interface isn’t perfect, don’t toss out the code when going back to improve it, but to wrap it in an improved interface (kind of like the adapter pattern) in order to provide a better interface to the user/calling code of the module.
@@jamesgood7894 Haskell has a easier time by dealing with immutables. In languages that deal mostly with "by reference", one of the main reasons you throw out a SA and replace it wholesale is not because of the code per se, but because of the bad side effects. Something that looked like a good idea in the prototype has become a true nightmare, and now you're in lock/mutex/semaphore hell because of it. No amount of refactoring will solve that, you need a new SA that deals with "what will happen and how to avoid it". Problem being, you can only know how big a nightmare it will turn into post facto. At the extreme end, it gets so bad you'd be better off running single threaded because you are waiting on something that is waiting on something that... ;)
Getting the idea out is perhaps the most important part, perhaps even trumping standards or principles or patterns. There is usually a distance between a blank slate and proof of concept. And within that distance is a graveyard of failed projects. Building that stamina to survive this is perhaps the most important for devs at the beginner level who are still grasping the mindset of programming itself. Have a process. Then improve that process. Just as it is too easy to devolve from developing a game into tweaking the game engine (and fail to produce a game), it is also easy to fall into the maze of standards to the point where the product no longer progresses, but gets stuck in the sea of refactors and compliance checks - a lot of movement of letters without useful function. With experience, both in coding and in procuring programming aids and tools over the years, we'll get better at separating prototypical code from final code, segmenting parts of the product to useful levels of abstraction, when to stop coding and start reviewing and refactoring, and even start to internalize some of the best practices to minimize the effort from prototype to product code. This is the typical audience for this video. Beginners are welcome to see the roadmap of their dev journey.
Small addition to the last point: Remember the Pareto principle 80% of the result is caused by 20% of the work. It is expected that you blaze through at the beginning of the project, only to slow down a lot afterwards. It’s not you, it’s everybody 😊
@@bobbobson6290 I apologize, but as an AI language model I am not able to create or run code. However, I can provide an example of these concepts using Python. ```python ``` import os ...
@Agilitea familiarize with python doing basic algorithms. First learn to speak fluently in this new language. Whatever you want to say, write it in python. All these topics will make sense after you know how to program and try to do it with someone else. The only exception is the topic on learn to properly name your things. That is simple and often ignored (stop naming your variables as a, b and c. Put the name that will make you understand your written code a week after you left it) Revisit this video everytime you think you've made a big step toward programming, because you will understand each time a little bit better and figure it out all topics spoken here, and maybe use it as a starting point for deep learning something later
@@fabdlnltc Thanks, I've actually never named my variables after letters though as my professor gives us training scenarios for our codeing assignments.
To expand on the first point, a lot of IDEs have an auto formatter that will fix your whitespace and indentation for you, and can be run on existing files all at once to clean everything up. If you're on a team, it's a good idea to create a configuration for the formatter and share it with everyone on the team so it's impossible for anyone to make formatting mistakes :)
Absolutely true, I forgot to include this point! Tools like "Prettier" and linters with auto-formatters can save you so much time and headache. Thanks for the addition!
Git hooks for the rescue! Although local ones aren't shared and until now I couldn't convince people to have them installed on server side, one can still have a shared hooks project that comes with automatic updates and an installer. Doesn't need to be for style, but syntax at least. Have seen it multiple times: A does a "minute" change that "can't possibly go wrong" and B spends days searching for an issue he never introduced himself. Ok, B might have read the git log, or bisected it, also when A doesn't even check the syntax how likely is it to have him install hooks, but you get the point.
@@local9 Absolutely! Also to do unit tests before pushing. Even when you --no-verify, it just nags until you do it a liiiitle better every time. Total game changer!
I would add one missing point; Teamwork/Communication You rarely work alone, so listen to every pain you or your team has (on or out code), and think together how to address them and solve it. Which is the heart of every agile methodology
The code I wrote primarily implemented some mathematical calculation. Code and it's documentation are not always well linked. So I made it a habit to describe the derivation, references to text books used and even put Matlab simulation code used directly in the comments so the next person to service the code could see the whole process and repeat it if changes were required. Years later I visited the company and the engineers that maintained my code thanked me.
Not sure if it's intentional, but I love your callback at 5:00 to the square hole TikTok meme. Gave me a good chuckle and now I want to see how far that actual metaphor of putting a circle in a square programming hole goes.
I was screaming and crying when they kept going in the square hole, but I’m also the guy who puts everything in the square hole (I’m so good at breaking software).
This videos are so ZEN. It's like code meditation. If you continue creating content like this , sharing your knowledge in this calm style , you will get a huge fanbase. Keep up the good work.
The amount of references in this video are crazy and hilarious! The CGP Grey reference (hexagons are bestagons), the DBZ reference, the tiktok meme, there's the brain one & I'm not sure if that's a silent nod to Fireship's brain one, and the L words repeating reminds me of the presentation of ChatGPT-4. Awesome video!
Video is stunning. I am learning to code, I am still a beginner, but your video inspires me to continue and to do so in the best way possible. The pace of your voice is relaxing yet not boring. The drawings and animations are a feast for the eyes. I subscribed :)
It really means a lot, thank you! And keep at it - programming can be endless fun and learning new things about it is the best part in my opinion. You get to create whatever your imagination and skill allows and so many possibilities unlock as you get better
Amazing Animations and video in general! I am a Junior Angular Dev and quite happy to see that most of the things mentioned here I'm either already doing or at least familiar with (due to occasional reminders by my great colleagues!
Thank you!! As much as the content, I appreciate the zen tone of this video. Reading good code is an enjoyable thing indeed. Adding to lesson 7, at any point during a coding task, never be afraid to revert all changes and start again. You'll be amazed at how quickly you will get back to the same progress point, but you'll have a cleaner design with all the things learned from the previous attempts 🥳
It's great to see that every single one of these concepts is what I'm being taught step by step in my graduate education to software developer. It's not always easy to link the idea or best practice to the actual writing of code, but seeing as how I've been doing this for only 6 months, I suppose in time it will become second nature :)
One of the best animated Videos I’ve ever witnessed. Absolutely stunned by your work. You put in a lot of effort, and it shows - and hopefully pays off for you. Keep it up 👍🏻
Man, this is so good. I'm sending this to my whole team tomorrow. For one, it is a great refresher and probably one of the best explanations and examples of SOLID I've seen. It an be tough to convey these ideas to teammates and this is a great refresher for those of us that think we know them. I tend to harp on things like formatting/style, SOLID principals, etc., but it makes such a huge difference in adding new things, finding/fixing bugs, and most importantly time to implement all those things. Great video and instant sub from me.
Outstanding video! So many concepts made accessible to everyone. I as a dyslexic programmer, REALLY appreciated the work that went into telling the story and visually representing everything. Absolutely bravo.
You know what's really SOLID? Your attention to detail in all these animations. When I saw the check marks appearing in sync with you describing the corresponding SOLID principles (at 09:00), my jaw literally dropped.
Awesome video. One simple paradigm I like to keep in mind along with these things is that 'premature optimization is the root of all evil'. When something needs optimization, you'll notice, and that's when you tackle it. Before that point, you're almost always adding complexity for little benefit.
self taught programmer here and over the last year and many of these are the things I've been realizing as my code grows more complex and needed more maintenance really nice to see a guide listing it out explicitly! so i can better plan out my next project
The advice on time and speed reminds me of the common cognitive trap called "Fluency effect", which says that we tend to think the things that run smooth in our mind would actually be so fluent in reality. Success from others seem so easy, such as cooking, writing, or playing sports.
when there is no unique way of doing something you need patterns to guide you. programming is one of those activities, like writing. it is somehow an art
For the one about not changing parent classes, I'll intentionally ignore it, but appreciate it. I don't want to use the term project, because it's like a growing foundation for many many projects, but I'm working on making my own engine. Part of that proccess is when I finish making a project functional, I refactor the code to make as many of those parts as possible part of the base engine, then remake the project with as little unique parts as possible. This allows things like, if I make a blackjack game, then making a solitaire game will be almost already done. And as I make new smaller projects, my tools for the next will be more, shrinking the size of other projects I want to make. Until eventually, I can make my dream game. Now, I do love layers of abstraction. While I'm pretty confident with my techstack, I could be wrong. What if I want Vulcan instead of OpenGL? What if CMake is actually the better option? What if I can write a better tool than what I chose? With abstraction layers, I can go into one file, change the code, comment out the old, and run everything without breakage(hopefully). This means I don't have to be perfect, just good enough. And if I have a regret, I can change it without losing progress elsewhere.
Great video! Always a sucker for animations. Also, one very overlooked caveat of things like design patterns, is that you also need to know when to apply a pattern, since sometimes you are simply complicating things for the sake of it. Sometimes a simpler, more linear code structure is better.
@@coderized any tip for animations? I want to start a language teaching channel and struggle to move away from my whiteboard and ugly face, your videos are fire I would like to know how you do them. Thank you Sir
I had to smile while watching this video. I remember going to an interview and questions asked about EACH point you make. I messed up one of the terms in SOLID and they recommended a couple of good books that helped fill in the gaps. But this is a very good overview of what good coding techniques and practices should be. I have since retired from programming. The commute was around 1.5 hours each way and although I loved the company for which I worked, they didn’t encourage remote work. It’s too bad, because a couple of years after I retired, COVID hit and all development work was remote……. Oh well…. Timing is most always everything.
Like most viewers of this type of content, of which the quality presented here is impeccable and deserves all praise, I find it hard to recognize when to apply the Programming Patterns that have been taaght to us when working on my own projects. The SOLID principle is easy to recall as it 'makes sense' and the same goes for the good habits like adequate naming conventions, testing, and documentation but them dammned patterns rarely come organically to me and often I have to stumble upon the realization that I needed to implement pattern X to solve/build Y. Thanks for the stellar vid!
Maybe another point that ties into proper naming: using proper types. They serve both as documentation and for static analysis tools. This saves you so many debugging sessions where you get unexpected values, because your editor/compiler will scream at you if you get it wrong. It also provides immense benefits to the rest of the team as they are able to inspect the shape of the data that comes out of your functions/methods.
Types in general I totally agree with. Types make code way more robust and predictable. Types in names, I think is unnecessary - though I'm not sure if you meant that
types is an obvious one. I would add using something like jsdoc (or the equivalent for other languages). If the functions are poorly written/named, then at least you get hints what the guy before you tried to do as he will have put a little effort to explain it using plain sentences.
@@coderized I disagree on this point actually. In general the video was great and by n large you are pretty safe to apply these broadly, but I have and will continue to argue for types in names until analyzers like Visual Studio's Intellisense can quickly and accurately deduce the type for me. I find that it often makes errors in more complex function and data structures, or when dealing with multiple typedefs/alias, or when meta programming becomes too advanced. Sure if it's a function local and it's a 30 line function, leave the type off, ok. But if this is something you are going to be passing around, exposing in an api, overriding, aliasing, or something, PLEASE use a type. I do not want to have to manually jump through 30 headers(or what ever your language of choice uses to resuse code files) just to figure out that *age* is a string and not an integer. And in larger programs, I don't want to have to run them and reach that point in the debugger either. Depending on the system that isn't even practical. I think there is a strong case to be made to leave types in names at least most of the time. Yes sometimes you can omit them, but I am far more likely to waste an hour figuring out where something is actually defined to look up the type than I am to struggle for an hour with the readability of your code because you went overboard and stuck a type suffix on everything.
Developers: We also need time for test? Business: How many? Developers: additionally 30% - 50% of coding time. Business: To expensive! Do without tests! Developers: But tests will help .... Business: We need product as fast as possible! Also no need write "Clean code", just make it workable! Maybe later (Never), will have time to clear code and write tests. ----------- In reality in time when you spend a lot of time to writing tests and ultra good code, others will go to market with bugged product and will get audience and more money for developing next features. When your product with excellent code and 99% code covered with tests will be ready, others will be faaar away with product where code is "shit".
This is great, thanks. I get what you mean by these being guidelines and not really rules. I love the idea of making my code "cool" and designing it in a way that it's easily expandable, but I've come to realize that if I'm just doing a small project for college that needs less than 100 lines of code... Then there's no need to overcomplicate it by making it modular, or by writing it in a way that will never produce errors. If it does what it was meant to do and it's easy to understand then that's really all it needs lol
I know nothing about coding other than the couple classes I've forgotten about in high school, but I still watched the video through. Very interesting and still think I understood the concepts
When someone doesn't say "hit that like button" in their video i feel like in the old days. And that instantly commands respect, so i'll leave this comment and a sub(might change my mind though, we'll see). Seeing that this is your first piece of content here - i think you've got it, but GL anyway!
Good content. This was a lot of stuff that I hadn't even considered before getting out of college, but I now consider in every single moment of every day in my career. I was expecting a clickbait from the title, but these are genuinely good tips that you don't hear every day. I don't think I ever fully understood the bit about dependency inversion until watching your video, I was just following a design pattern blindly.
I'm working on the largest project I've ever done, a python library for modding where's my water, and I've actually been doing some of these things already. I've actually been doing stuff in this project that I don't normally do, such as, splitting mostly everything into its own file, aka module, and I have found that it can be easier that way. I've also started using constants more, especially when I want to check if a value is the default value.
Great animations and explanations, definitely important topics for new programmers to learn as these tips will help them from falling into many of the pitfalls they could otherwise fall into. You have gained a new subscriber, and I am looking forward to what else you will be coming out with!
Beautiful video! Concise and clear explanation of so many essential topics! Also, nice voice, smooth and descriptive animations. Looking forward to seeing this channel evolve!
I normally don’t comment on videos but I wanted to say this video was amazing! With the absurd quality, I was thinking the channel had at least 100k subs. If you keep it up, I’m sure you’ll be there in no time!
Amazing video! As a person that usually overthinks problems and suffers from a severe case of impostor's syndrome, this video is a breath of fresh air. It's clear, concise and gets to the point - exactly what I needed! Also, the production quality of this video is just stellar! Do you use After Effects? Keep up the amazing work! Rock on!
Your video pretty much summarized everything I've been studying for the last couple of years or so, and STILL managed to make me understand everything in a fuller yet more simpler way, cheers man, your channel is bound to be successfull
As a senior lead dev who’s constantly trying to educate my coworkers to these principles and design patterns, I found this video to be one of the best overview on this subject. Thank you for this.
Also a senior dev and I came here looking to get some pointers for improvement but mostly just got an excellent summary of the principles of code quality that I try to teach my team members through code and design reviews.
You should really make more videos dude. I went to your main channel page to watch more and was disappointed when I didn't see more. I think you have a really relaxed way of talking and saying things, that coupled with your minimalistic video design style makes you fit into a profitable target niche. That target niche are people like myself that are trying to improve their coding, but at the same time have stressful jobs that keep them preoccupied. I watched your video after a long days work and found myself relaxed in an almost asmr sort of way, while at the same time learning something new. I hope to see more content from you in the future.
I love that when you gave an example for Single Responsibility, you took apart a Util class. My Hell, the number of programmers I've worked with in my career who just stuff everything into a Util class is *too damn high*.
I remember when I was reviewing a PR from a senior engineer, the sql query he pushed was not formatted nicely, it didn't align, and a lot of whitespaces at places where it should not be. I put some comments, one of them was a minor comment to format it for readability. He just replied "just focus on functionality, not aesthetics". 😅
Excellent video! Concise, professional and handy for any developer. 💯 I was aware of the "7 Deadly Programming Sins" covered here as you went through them, but having them so neatly packed in a Guidebook format is highly appreciated. 🙌 Thanks a lot, subscribed.✌️
I started implementing these last week as a complete noob 😁 I got discounted enough with my typos that I simplified as much into variables or designs I could change recursively in the script. . Change One and Multiply That was my approach. . I enjoyed this video. Both validating and provided me more perspective.
09:46 - as a mechanical engineer since 2005 I cannot think of a single time when we were given enough time to design anything. Never ahead of schedule because the project engineers never gave enough time. Even when the design department gave estimations, as we do, the paper pushers above always slash the times anyway, setting the timelines on a path to failure. Maybe coding is different. I'm a self taught programmer on my second year now. Great video - thank you.
i got hooked by the other video you made, never install locally. and now here i am, learning even im old and not a good developer. this video keeps reminds me what i need and should be focusing after creating tasks or project. you helped me a lot and thanks. more blessing and good luck with your future journey!
This video was very helpful. I would like to add 2 things I discovered during my study of computer science: 1) There is nothing quite as permanent as a quick fix. 2) The first 80% of creating code is writing code, and the remaining 80% of creating code is debugging it.
Did 11 minutes really pass me by? Great video! I'm amazed this is your first video on this channel it feels like you have a well defined style and I love it
I really appreciate how this video describes concrete steps and characteristics of modular & decoupled code instead of paying lip service to the ideas like most things ive seen online do.
Hey folks, I just wanted to add a quick few things to make the goal of the video a bit clearer:
I present these topics as guidelines, not hard rules. I call them "sins" but in reality, there's exceptions to everything and your situation may not need all the topics covered. I've seen people who over-engineer simple codebases to the point it's unreadable, just to have it fully modular; or obsess over following standards, even when it becomes incompatible in certain situations; or spending way too much time trying to achieve 100% test coverage, when it added no more benefit to do so. The best way to interpret this video is to have a little understanding of the topics, and choose the things that you want to learn more about. The 80/20 rule is usually pretty good to combine with all these points.
Everything mentioned in the video once had a pain point behind it that will have led to its creation, but maybe you don't have these same pain points... yet! Just remember the potential solutions for when you do, or use them as a foundation for your own exploration!
Hope this clarifies a bit!
---
Oh, and thank you so much for all the kind comments! I'm reading every single one with a smile. Your feedback means a lot and I am really excited to get back to creating more videos for you all.
Please keep uploading!!! This video was so great 👍
I love this added comment, as after watching the video I was pretty afraid people might fall in the trap of dogmatically following principles like SOLID like they are 10000% must does. However, after being frustrated with engineers creating interfaces for everything, every time, everywhere I had began to do a ton of research, there had to be a better way. And for my sanity I found one.
Having always been the type to make things work first, and make things better later, Test Driven Development was an eye opener, and I suddenly began to see you don't need interfaces everywhere, nor do I need to mock everything (yey Sociable Tests!). What I really learned doing TDD is that after you get things to work, and backed by (behavioral) tests, refactoring is fun, and useful patterns and practices come to the surface quickly. I can really suggest to people to learn TDD, even if you don't like it, if only to get more insight in when to apply practices and patterns better and avoid the trap that I like to call "Cargo Cult Programing", applying patterns and practices without considering their usefulness in your specific problem domain.
For anyone interested in what testing without mocks looks like, search for James Shore here on UA-cam, he has a bunch of great video's explaining it with some fun projects.
One of the most effective ways to double your productivity is to learn to touch-type.
Excellent video!!
This were good points but I wish the SOLID method was explained with code or something
I think "don't follow rules blindly" also deserves a place as advice - understanding why some best practices exist and when they make no sense is important. There are valid exceptions to everything.
Exactly, without any context these principle, rules or patterns makes no sense. This sometime leads to over-engineered solution which is not that useful for the business.
Definitely. I started work as a software dev about 6 months ago and I'm trying to improve our product by following coding standards and general guidelines from the C++ community. But I don't apply anything until I've researched it enough to understand it myself and explain it to others.
Generally agreed, on the other hand - when breaking a "rule" (guideline, established practice) it's best if you know how it works, why it's there and what are the tradeoffs; at which point you probably don't need a guide/video to tell you that.
In fact most of the "good practices" become crap when you have to do something enough complicated for that.
That's why I have finally rejected OOP 🙂
“Don't ever take a fence down until you know the reason it was put up.” ― G. K. Chesterton
I love how calmly everything is presented. There’s no music in the background either which leaves a few silences in between. It’s a welcome change
Yeah, it's like listening to someone doing a guided meditation, just on code. It's lovely.
*slits POONS throat* I couldn't take it anymore, something was definitely brewing. I had to cause chaos before it was too late.
Agreed. I enjoy this style. As a future UA-cam feature, I wish there was a button for the background music track on videos, so I could switch it off when I want to. Background music can be very distracting.
It also means I can play my own music while listening, which automatically improves my personal rating on tutorial type videos.
Yeah it's very soy
Channels are popping up with extremely high quality content like it's nothing and it makes me happy. By quality I'm not talking only about the very professional animations, but the actual information as well. As a CS student I was familiar to most of what you said, but the video just sealed all this info together in a way that made think about this stuff and become a lot more confident. The examples were well chosen too.
For real! This channel, CodeAesthetic and ByteByteGo makes the best programming content I've ever seen on UA-cam and they've all popped up in the last year
exactly this!
agree on all counts 100%
Welcome to the information age, brother
I don't know why I'm here, it's 3 am, i am tired, i have to study for my finals ... I don't even code... I watched this video twice
😂😂 great comment
How did you do?
Because you're nothing but a slave of the algorithm
Did you pass?
Why did you watch it? 🤣
I remember a dev once said that development is never straightforward, and so the team ends up meandering as if they were following a series of semicircles, which is why they plan for everything to take 3.142 times as long as expected.
That’s very poetic!
@@rb.xpi-tic
I seem to remember seeing a video about a paper that discussed projects in corporate settings tending to take e times as long as expected. Another reason why pi=e=3
Pythagoras sees what you did there.
I love me some pie, especially creampies!
5:03 "That's right, it goes in the square hole"
Came to find this comment. 😂
Nice summary, beautiful visuals.
Thank you Miroslav 💜
I've been programming for 12 years now.. this perfectly articulates what I've been subconsciously been leaning towards as time goes on. I've heard about all of the concepts in this video but never in this way. These principles truly are fundamental measurements of ones proceffiency in code. One thing I will mention though is the concept I personally use with larger programs. When I am facing a large system, I will typically prototype smaller bits of code in a way that "just works." After I get my concept I have in my mind in front of me, I then begin to refactor and abstract the code into a state that is to, in my eyes, what is described in this video. In my game engine I've been working on over the past few years I started off by just getting things going like a window, simple rendering with shaders etc. Eventually over time I separated out the project in modules that hook the engine for state changes. The core engine eventually just became a bootstrapper for modules like an Asset module, and other modules could depend upon modules within their module.lua file (custom build system), and I had I things like abstract modules where a render backend could be opengl or directx, where there would be an abstraction module that provides common rendering functionality, allowing modules that need to render something to just require the abstract render module and let the runtime render module handle the rest.
TL;DR sometimes its okay to just "get your idea out" with some working prototype, then chip away/refactor as you would with a beautiful marble sculpture; apply the principles presented in this video as a form a improvement overtime instead of must-have requirements from the get-go. Principles such as standards should always be followed in my opinion however.
Well said!
"In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow.". Fred didn't mean it literally, but on a functional level. If you're doing something new, odds are you wont DoItRight straight away, no matter how much analysis you throw at it. So might as well GetItDone, go over it figuring everything that is wrong, then DoItRight, or as close as possible.
At this stage in the process, refactoring is counter productive IMHO, as you don't have a "code block level" issue, you have a Systems Architecture issue. Reuse maybe, refactor not so much.
Assuming v2 went well, you can now just refactor/rework, and bar some fundamental change, things should sail along quite ok, even if not optimal.
Most (legacy) nightmares are from systems that didn't Throw One Away, because (business) reasons. And they carry all that bad SA into the future. At that point, any refactoring/patterning you throw at it is just "reshaping" a fundamentally wrong thing.
Funny thing, if/when they do decide to do it anew, they don't use the old one as "reference" and just start working one the new one, with zero intention of throwing the prototype away. Wash, rinse, repeat.
Was reading a Haskell book “Abstractions in Context”. The author suggested that if your initial design/interface isn’t perfect, don’t toss out the code when going back to improve it, but to wrap it in an improved interface (kind of like the adapter pattern) in order to provide a better interface to the user/calling code of the module.
@@jamesgood7894 Haskell has a easier time by dealing with immutables. In languages that deal mostly with "by reference", one of the main reasons you throw out a SA and replace it wholesale is not because of the code per se, but because of the bad side effects. Something that looked like a good idea in the prototype has become a true nightmare, and now you're in lock/mutex/semaphore hell because of it. No amount of refactoring will solve that, you need a new SA that deals with "what will happen and how to avoid it". Problem being, you can only know how big a nightmare it will turn into post facto. At the extreme end, it gets so bad you'd be better off running single threaded because you are waiting on something that is waiting on something that... ;)
Getting the idea out is perhaps the most important part, perhaps even trumping standards or principles or patterns. There is usually a distance between a blank slate and proof of concept. And within that distance is a graveyard of failed projects. Building that stamina to survive this is perhaps the most important for devs at the beginner level who are still grasping the mindset of programming itself.
Have a process. Then improve that process.
Just as it is too easy to devolve from developing a game into tweaking the game engine (and fail to produce a game), it is also easy to fall into the maze of standards to the point where the product no longer progresses, but gets stuck in the sea of refactors and compliance checks - a lot of movement of letters without useful function.
With experience, both in coding and in procuring programming aids and tools over the years, we'll get better at separating prototypical code from final code, segmenting parts of the product to useful levels of abstraction, when to stop coding and start reviewing and refactoring, and even start to internalize some of the best practices to minimize the effort from prototype to product code. This is the typical audience for this video. Beginners are welcome to see the roadmap of their dev journey.
Small addition to the last point: Remember the Pareto principle
80% of the result is caused by 20% of the work. It is expected that you blaze through at the beginning of the project, only to slow down a lot afterwards. It’s not you, it’s everybody 😊
We can apply that to many things. Such as 20% of coders will create 80% of bad code? 😂
0:38 use standards
1:20 learn principles
4:47 apply patterns
6:21 adequate names
8:00 test
9:10 realistic time
10:00 appropriate speed
you forgot banana D:
"Multiply by π"
& if you invent a new principle
Please explain it in simple words
"ChatGPT can you refactor my code to these principles?"
@@bobbobson6290 I apologize, but as an AI language model I am not able to create or run code. However, I can provide an example of these concepts using Python.
```python
```
import os
...
Dude, I really needed this video 15 years ago.
I hope every new learner can appreciate and understand everything here!
I'm new to python and programming as a whole and I am completely lost. All I've done is partially work on a cash register.
@Agilitea familiarize with python doing basic algorithms. First learn to speak fluently in this new language. Whatever you want to say, write it in python.
All these topics will make sense after you know how to program and try to do it with someone else. The only exception is the topic on learn to properly name your things. That is simple and often ignored (stop naming your variables as a, b and c. Put the name that will make you understand your written code a week after you left it)
Revisit this video everytime you think you've made a big step toward programming, because you will understand each time a little bit better and figure it out all topics spoken here, and maybe use it as a starting point for deep learning something later
@@fabdlnltc Thanks, I've actually never named my variables after letters though as my professor gives us training scenarios for our codeing assignments.
To expand on the first point, a lot of IDEs have an auto formatter that will fix your whitespace and indentation for you, and can be run on existing files all at once to clean everything up. If you're on a team, it's a good idea to create a configuration for the formatter and share it with everyone on the team so it's impossible for anyone to make formatting mistakes :)
Absolutely true, I forgot to include this point! Tools like "Prettier" and linters with auto-formatters can save you so much time and headache. Thanks for the addition!
Git hooks for the rescue!
Although local ones aren't shared and until now I couldn't convince people to have them installed on server side, one can still have a shared hooks project that comes with automatic updates and an installer.
Doesn't need to be for style, but syntax at least. Have seen it multiple times: A does a "minute" change that "can't possibly go wrong" and B spends days searching for an issue he never introduced himself.
Ok, B might have read the git log, or bisected it, also when A doesn't even check the syntax how likely is it to have him install hooks, but you get the point.
@@karoshi2 Git hooks with linting, soo much time saved, also been doing commit liniting so each commit has better messages.
@@local9 Absolutely! Also to do unit tests before pushing. Even when you --no-verify, it just nags until you do it a liiiitle better every time.
Total game changer!
Fascism!
I would add one missing point;
Teamwork/Communication
You rarely work alone, so listen to every pain you or your team has (on or out code), and think together how to address them and solve it. Which is the heart of every agile methodology
The code I wrote primarily implemented some mathematical calculation. Code and it's documentation are not always well linked. So I made it a habit to describe the derivation, references to text books used and even put Matlab simulation code used directly in the comments so the next person to service the code could see the whole process and repeat it if changes were required. Years later I visited the company and the engineers that maintained my code thanked me.
Not sure if it's intentional, but I love your callback at 5:00 to the square hole TikTok meme. Gave me a good chuckle and now I want to see how far that actual metaphor of putting a circle in a square programming hole goes.
Haha glad you liked it. I love that meme, makes me laugh every time
@@coderized I also enjoyed the 'Bestagons' reference. A man of culture, I see :P
I was screaming and crying when they kept going in the square hole, but I’m also the guy who puts everything in the square hole (I’m so good at breaking software).
I'll give you an idea of how far it can go:
If {
If {
If {
If {
If {...
This video is just amazing!
The animations are eye-catching, I never felt even half a minute bored and the 7 points are top-tier.
Brilliant production quality! Nice to see so many coding channels booming that go beyond just solving problems.
This videos are so ZEN. It's like code meditation. If you continue creating content like this , sharing your knowledge in this calm style , you will get a huge fanbase. Keep up the good work.
The amount of references in this video are crazy and hilarious! The CGP Grey reference (hexagons are bestagons), the DBZ reference, the tiktok meme, there's the brain one & I'm not sure if that's a silent nod to Fireship's brain one, and the L words repeating reminds me of the presentation of ChatGPT-4. Awesome video!
Video is stunning. I am learning to code, I am still a beginner, but your video inspires me to continue and to do so in the best way possible. The pace of your voice is relaxing yet not boring. The drawings and animations are a feast for the eyes. I subscribed :)
It really means a lot, thank you! And keep at it - programming can be endless fun and learning new things about it is the best part in my opinion. You get to create whatever your imagination and skill allows and so many possibilities unlock as you get better
Yo I'm a beginner too wanna learn together drop ur discord
@@deus6950 I'll set up a Discord at around 10k subs I think :)
@@coderized ok that's good the original comment
Amazing Animations and video in general! I am a Junior Angular Dev and quite happy to see that most of the things mentioned here I'm either already doing or at least familiar with (due to occasional reminders by my great colleagues!
Thank you!! As much as the content, I appreciate the zen tone of this video. Reading good code is an enjoyable thing indeed. Adding to lesson 7, at any point during a coding task, never be afraid to revert all changes and start again. You'll be amazed at how quickly you will get back to the same progress point, but you'll have a cleaner design with all the things learned from the previous attempts 🥳
Great video! Not usually my type of thing, but when I got to the end, I got a strong urge to subscribe, for some reason
It's great to see that every single one of these concepts is what I'm being taught step by step in my graduate education to software developer. It's not always easy to link the idea or best practice to the actual writing of code, but seeing as how I've been doing this for only 6 months, I suppose in time it will become second nature :)
One of the best animated Videos I’ve ever witnessed. Absolutely stunned by your work. You put in a lot of effort, and it shows - and hopefully pays off for you. Keep it up 👍🏻
Man, this is so good. I'm sending this to my whole team tomorrow. For one, it is a great refresher and probably one of the best explanations and examples of SOLID I've seen. It an be tough to convey these ideas to teammates and this is a great refresher for those of us that think we know them. I tend to harp on things like formatting/style, SOLID principals, etc., but it makes such a huge difference in adding new things, finding/fixing bugs, and most importantly time to implement all those things.
Great video and instant sub from me.
Thanks Ben, I appreciate the feedback! :)
Outstanding video! So many concepts made accessible to everyone. I as a dyslexic programmer, REALLY appreciated the work that went into telling the story and visually representing everything. Absolutely bravo.
last phrase was so good
. anyone can write code that machine understands 👍🏻
I was not expecting a reference to the square hole video
Can’t imagine using dependency inversion and making interfaces for everything for a code base under 50,000 lines
You know what's really SOLID? Your attention to detail in all these animations. When I saw the check marks appearing in sync with you describing the corresponding SOLID principles (at 09:00), my jaw literally dropped.
I loved the word "banana" flashing at the very end of the video to compel me to subscribe. Smart and discreet. 👍
5:01 "That's right, it goes in the square hole."
This is now my gold standard for programming content, and you were right I did smile at the end!
Happy to see you back with great stuff as always!
Good to be back! It was a while making this one and much more to come!
Awesome video. One simple paradigm I like to keep in mind along with these things is that 'premature optimization is the root of all evil'. When something needs optimization, you'll notice, and that's when you tackle it. Before that point, you're almost always adding complexity for little benefit.
self taught programmer here and over the last year and many of these are the things I've been realizing as my code grows more complex and needed more maintenance
really nice to see a guide listing it out explicitly! so i can better plan out my next project
The advice on time and speed reminds me of the common cognitive trap called "Fluency effect", which says that we tend to think the things that run smooth in our mind would actually be so fluent in reality. Success from others seem so easy, such as cooking, writing, or playing sports.
We want projects that get easier with time, NOT harder.
Underrated line.
"Remember that creation goes hand-in-hand with problems..." @9:44 Absolute truth. Excellent video @Coderized
Wow, i didn't expect that much quality on a channel with only 170 subscribers, 171 now.
Thanks! I hope to make many more of similar quality - probably a bit shorter and more frequent in the future though! :)
ehm.. 14.4K now 😃🥳🥳
@@johnsausage wow! And half a million views, congrats @Coderized!
Thank you both! As you can imagine I'm pretty stoked at the growth 😊
when there is no unique way of doing something you need patterns to guide you. programming is one of those activities, like writing. it is somehow an art
For the one about not changing parent classes, I'll intentionally ignore it, but appreciate it.
I don't want to use the term project, because it's like a growing foundation for many many projects, but I'm working on making my own engine. Part of that proccess is when I finish making a project functional, I refactor the code to make as many of those parts as possible part of the base engine, then remake the project with as little unique parts as possible. This allows things like, if I make a blackjack game, then making a solitaire game will be almost already done. And as I make new smaller projects, my tools for the next will be more, shrinking the size of other projects I want to make. Until eventually, I can make my dream game.
Now, I do love layers of abstraction. While I'm pretty confident with my techstack, I could be wrong. What if I want Vulcan instead of OpenGL? What if CMake is actually the better option? What if I can write a better tool than what I chose? With abstraction layers, I can go into one file, change the code, comment out the old, and run everything without breakage(hopefully). This means I don't have to be perfect, just good enough. And if I have a regret, I can change it without losing progress elsewhere.
Yeah I actually don't like that rule either and wish I'd left it out
@@coderized Lol! Makes me feel better about myself!
Great video! Always a sucker for animations. Also, one very overlooked caveat of things like design patterns, is that you also need to know when to apply a pattern, since sometimes you are simply complicating things for the sake of it. Sometimes a simpler, more linear code structure is better.
Totally agree. I might cover patterns in more detail in an upcoming video and I'll be sure to explain this. Thanks for the comment!
Great point
@@coderized any tip for animations? I want to start a language teaching channel and struggle to move away from my whiteboard and ugly face, your videos are fire I would like to know how you do them. Thank you Sir
This is such high quality content, easily becoming one of my favorites to recommend to others and beginners.
I had to smile while watching this video. I remember going to an interview and questions asked about EACH point you make. I messed up one of the terms in SOLID and they recommended a couple of good books that helped fill in the gaps. But this is a very good overview of what good coding techniques and practices should be. I have since retired from programming. The commute was around 1.5 hours each way and although I loved the company for which I worked, they didn’t encourage remote work. It’s too bad, because a couple of years after I retired, COVID hit and all development work was remote……. Oh well…. Timing is most always everything.
I am curious at what age have you retired, if you don't mind me asking
Like most viewers of this type of content, of which the quality presented here is impeccable and deserves all praise, I find it hard to recognize when to apply the Programming Patterns that have been taaght to us when working on my own projects.
The SOLID principle is easy to recall as it 'makes sense' and the same goes for the good habits like adequate naming conventions, testing, and documentation but them dammned patterns rarely come organically to me and often I have to stumble upon the realization that I needed to implement pattern X to solve/build Y.
Thanks for the stellar vid!
Your presentation and visual style is so good!!
hexagon is the bestagon
Definitely
Maybe another point that ties into proper naming: using proper types. They serve both as documentation and for static analysis tools. This saves you so many debugging sessions where you get unexpected values, because your editor/compiler will scream at you if you get it wrong. It also provides immense benefits to the rest of the team as they are able to inspect the shape of the data that comes out of your functions/methods.
Types in general I totally agree with. Types make code way more robust and predictable. Types in names, I think is unnecessary - though I'm not sure if you meant that
Hungarian notation? Just say no!
types is an obvious one. I would add using something like jsdoc (or the equivalent for other languages). If the functions are poorly written/named, then at least you get hints what the guy before you tried to do as he will have put a little effort to explain it using plain sentences.
@@coderized Definitely not in your variable names, wouldn't want to make refactoring the codebase impossible for the next dev that comes along 😅
@@coderized I disagree on this point actually. In general the video was great and by n large you are pretty safe to apply these broadly, but I have and will continue to argue for types in names until analyzers like Visual Studio's Intellisense can quickly and accurately deduce the type for me. I find that it often makes errors in more complex function and data structures, or when dealing with multiple typedefs/alias, or when meta programming becomes too advanced. Sure if it's a function local and it's a 30 line function, leave the type off, ok. But if this is something you are going to be passing around, exposing in an api, overriding, aliasing, or something, PLEASE use a type. I do not want to have to manually jump through 30 headers(or what ever your language of choice uses to resuse code files) just to figure out that *age* is a string and not an integer. And in larger programs, I don't want to have to run them and reach that point in the debugger either. Depending on the system that isn't even practical. I think there is a strong case to be made to leave types in names at least most of the time. Yes sometimes you can omit them, but I am far more likely to waste an hour figuring out where something is actually defined to look up the type than I am to struggle for an hour with the readability of your code because you went overboard and stuck a type suffix on everything.
Quality Audio, Quality Visuals and Informative content. Amazed by the efforts put in to create this video. Definitely deserves a Subscribe.
The slowly unveiling "neuron activation" meme written as code is just a cherry on top (starting 6:20)
Developers: We also need time for test?
Business: How many?
Developers: additionally 30% - 50% of coding time.
Business: To expensive! Do without tests!
Developers: But tests will help ....
Business: We need product as fast as possible! Also no need write "Clean code", just make it workable! Maybe later (Never), will have time to clear code and write tests.
-----------
In reality in time when you spend a lot of time to writing tests and ultra good code, others will go to market with bugged product and will get audience and more money for developing next features.
When your product with excellent code and 99% code covered with tests will be ready, others will be faaar away with product where code is "shit".
Bro you are rising up the bars of what makes a good programming content
This is great, thanks. I get what you mean by these being guidelines and not really rules. I love the idea of making my code "cool" and designing it in a way that it's easily expandable, but I've come to realize that if I'm just doing a small project for college that needs less than 100 lines of code... Then there's no need to overcomplicate it by making it modular, or by writing it in a way that will never produce errors. If it does what it was meant to do and it's easy to understand then that's really all it needs lol
Exactly right :)
This is a crazy level of production. Great job.
I was smiling when you said that it's worth it to see that smile :)
I really appreciate your content
Keep up the good work
Hofstadter's law: it will always take longer than you expect, even when accounting for Hofstadter's law
I know nothing about coding other than the couple classes I've forgotten about in high school, but I still watched the video through. Very interesting and still think I understood the concepts
Was hoping you had more videos since this one is so good. Looking forward to seeing more of your content in the future.
Thank you Chris, working on the next as we speak!
I actually can't believe this is your first video on this page. It's one of the best I've seen on youtube! Great work, Coderized.
Thank you! That's awesome encouragement 😊
When someone doesn't say "hit that like button" in their video i feel like in the old days. And that instantly commands respect, so i'll leave this comment and a sub(might change my mind though, we'll see). Seeing that this is your first piece of content here - i think you've got it, but GL anyway!
Great video, thank you. Appreciate the quality of your animations, especially considering this is your only video. Nice!
Good content. This was a lot of stuff that I hadn't even considered before getting out of college, but I now consider in every single moment of every day in my career. I was expecting a clickbait from the title, but these are genuinely good tips that you don't hear every day. I don't think I ever fully understood the bit about dependency inversion until watching your video, I was just following a design pattern blindly.
Happy I was able to help clarify some things for you! :)
I'm working on the largest project I've ever done, a python library for modding where's my water, and I've actually been doing some of these things already. I've actually been doing stuff in this project that I don't normally do, such as, splitting mostly everything into its own file, aka module, and I have found that it can be easier that way. I've also started using constants more, especially when I want to check if a value is the default value.
Oh hi lmao I know you from Scratch I'm @--Explosion--
Great animations and explanations, definitely important topics for new programmers to learn as these tips will help them from falling into many of the pitfalls they could otherwise fall into. You have gained a new subscriber, and I am looking forward to what else you will be coming out with!
Info-channels with this style have been popping up lately. I'm in danger of getting addicted to them all.
Funny that I used to follow the same rule for estimation. And was also giving it out as an advice but people kept thinking I am joking.
The animation is lovely and impressive! I see your CGPGrey reference 🙂
Beautiful video! Concise and clear explanation of so many essential topics!
Also, nice voice, smooth and descriptive animations.
Looking forward to seeing this channel evolve!
This is kind of my Software Engineering 2 class in a nutshell
The editing of the video, and your narrative voice are both very wholesome. It was a pleasant video to watch
“Only hexagons are bestagons”
Solid reference
I normally don’t comment on videos but I wanted to say this video was amazing! With the absurd quality, I was thinking the channel had at least 100k subs. If you keep it up, I’m sure you’ll be there in no time!
Thanks so much! Means a lot :)
Dude just want to say these animations were fire! 🔥 made each concept so much easier to follow and understand 😁
Amazing video! As a person that usually overthinks problems and suffers from a severe case of impostor's syndrome, this video is a breath of fresh air. It's clear, concise and gets to the point - exactly what I needed!
Also, the production quality of this video is just stellar! Do you use After Effects?
Keep up the amazing work! Rock on!
I engoyed the video very much the animation is unique and i like your style
keep on!
subscribed.
what a lovely video. i love how compassion is baked into the messaging, which is rare in dev videos.
Your video pretty much summarized everything I've been studying for the last couple of years or so, and STILL managed to make me understand everything in a fuller yet more simpler way, cheers man, your channel is bound to be successfull
Awesome comment, thank you!
Nice CGPGrey reference there.
That's right, it goes in the square hole
Bro the video is so well made, Animation is just too good! one of the best videos i ever watched you really make things simple to understand!
That quote at the end is one every programmer should know
3:11 Grey must be proud of you
As a senior lead dev who’s constantly trying to educate my coworkers to these principles and design patterns, I found this video to be one of the best overview on this subject. Thank you for this.
Also a senior dev and I came here looking to get some pointers for improvement but mostly just got an excellent summary of the principles of code quality that I try to teach my team members through code and design reviews.
You should really make more videos dude. I went to your main channel page to watch more and was disappointed when I didn't see more. I think you have a really relaxed way of talking and saying things, that coupled with your minimalistic video design style makes you fit into a profitable target niche. That target niche are people like myself that are trying to improve their coding, but at the same time have stressful jobs that keep them preoccupied. I watched your video after a long days work and found myself relaxed in an almost asmr sort of way, while at the same time learning something new. I hope to see more content from you in the future.
Thanks Nick, means a lot! Next video coming out next week hopefully and I'm really excited about it!
I love that when you gave an example for Single Responsibility, you took apart a Util class. My Hell, the number of programmers I've worked with in my career who just stuff everything into a Util class is *too damn high*.
I remember when I was reviewing a PR from a senior engineer, the sql query he pushed was not formatted nicely, it didn't align, and a lot of whitespaces at places where it should not be. I put some comments, one of them was a minor comment to format it for readability. He just replied "just focus on functionality, not aesthetics". 😅
Excellent video! Concise, professional and handy for any developer. 💯
I was aware of the "7 Deadly Programming Sins" covered here as you went through them, but having them so neatly packed in a Guidebook format is highly appreciated. 🙌
Thanks a lot, subscribed.✌️
I started implementing these last week as a complete noob 😁 I got discounted enough with my typos that I simplified as much into variables or designs I could change recursively in the script.
.
Change One and Multiply
That was my approach.
.
I enjoyed this video. Both validating and provided me more perspective.
09:46 - as a mechanical engineer since 2005 I cannot think of a single time when we were given enough time to design anything. Never ahead of schedule because the project engineers never gave enough time. Even when the design department gave estimations, as we do, the paper pushers above always slash the times anyway, setting the timelines on a path to failure. Maybe coding is different. I'm a self taught programmer on my second year now. Great video - thank you.
Seriously. Management poisons every industry honestly. Good management is harder to find than good engineering
@@HonsHon amen mate 🍻
i got hooked by the other video you made, never install locally. and now here i am, learning even im old and not a good developer. this video keeps reminds me what i need and should be focusing after creating tasks or project. you helped me a lot and thanks. more blessing and good luck with your future journey!
This video was very helpful. I would like to add 2 things I discovered during my study of computer science:
1) There is nothing quite as permanent as a quick fix.
2) The first 80% of creating code is writing code, and the remaining 80% of creating code is debugging it.
I love the subtle interne memes in this video
Did 11 minutes really pass me by? Great video! I'm amazed this is your first video on this channel it feels like you have a well defined style and I love it
So, who else got that CGP Grey reference?
You've inspired me to write article on this, thanks man
I really appreciate how this video describes concrete steps and characteristics of modular & decoupled code instead of paying lip service to the ideas like most things ive seen online do.
he knew what he was doing in 05:08....
The hexagon goes... In the SQUARE HOLE