DISCLAIMER: THIS VIDEO IS FOR A GENERAL AUDIENCE AND WILL NOT GET YOU EMPLOYED(sadly). Programming is subjective, and I'm sure I put some incorrect things in this video, so take what I say with a grain of salt. These are all just my opinions as a content creator/programmer. At the end of the day, a UA-cam video can not make you a professional programmer. but I hope it helps even one person who's beginning to learn to program/code. Also be sure to check out my inspirations for this video in the description, such as ModernIdeas and Fireship. Also, watching this back, I made the music way too loud. Sorry if it's hard to hear! Lastly, I appreciate each and every one of you for your feedback, even the negatives, as I want to give the best advice and video possible. Thank you all!
It's a very good video and well thought. If people complain, it's because they can't handle reality. I was exactly reflecting on the black box concept in these days.
@@p19shelt I agree. The video was well made and had good general advice for a programmer. The comment about bootcamp/clean code was just a dig with some truth in it, but it doesn't mean it was a bad video. The creator's self doubt in his comments makes newer developers unsure if they should trust his advice. Just ask for fair criticism and choose which ones to improve on the next video.
@@p19shelt I understand my advice is general because it's made for a broad audience, as most videos are. I believe in myself 100%, which is why I don't delete any negative comments and instead I try and learn from them. I'm pretty open minded and I understand people have different views on what makes a good programmer. So when I reply to comments like these, it's not self doubt, it's just me learning your opinion and explaining mine. but ultimately if you were looking for non-general advice on programming, you shouldn't be looking on UA-cam. At the end of the day this is just a UA-cam video, not a course.
@21stchill18 This doesn't even make sense my guy. If the algorithm has already been invented, you can't reinvent it. You can only learn and understand it.
@@maidenlesstarnished8816 pretty sure there more than one way to do the same thing. that's the exact reason we're still inventing new algorithms each and every year, getting slightly better in each.
1. Don't think about the processing yet, just the scalability and big picture 2. Make your code readable. Comments, meaningful names, conventions 3. Use frameworks & libraries to save time 4. Think in process, not in code, think of the solution not the code
The last one I think is well-meaning but is a bit of a trap. Programming languages are much more precise and unambiguous than natural language, so if you're working in a particular environment it may be easier to think in terms of the tools that environment provides. Much like how when planning how to build a cabinet you would think in terms of the tools you have rather than "magically form this complicated three-dimensional shape out of plywood". That said, if you need a tool but are not limited on technologies, thinking about what the requirements are could help make a selection.
I want to shoot myself when I see comments in code. Comments should only be there if you have to hardcode magic numbers (ie DB ids), if there is something so goofy that you have to comment so someone knows why you did it that way, or if there is no way to make something less complex so you have to leave a comment explaining it for a future dev. The only other time I think you should absolutely leave it is when you need to leave doco code for custom library utilities in an application. It is really nice when somebody writes javadoc on these kind of functions so my Intellisense can give me a rundown of the library when I hover over methods. I've seen it enough times where somebody has a function called "getTaskList" and then the comment above the function says "returns the task list"... Ya thanks... Didn't know what I would be getting based on the function name... Really saved me -_- . I see this in so many tutorials, and I swear the language I see this the most in is Python. Useless comments are so much worse than not having the comment at all. You are writing code for other coders. It is also worth thinking that if your code is so convoluted or complex that you need comments to read it, then there might be something wrong with your code. When I have to pull somebody's code and it's littered with comments, the first thing I do is remove all the useless ones so I can actually see what the code is doing. Sorry for the mini rant. I just hate useless comments and people should get in the habit of writing code that doesn't need to have the comments.
@@beterbarker I agree for the most part, particularly comments that are either clearly autogenerated (uselessly) or a line-by-line description of what the code does. I hear from friends in uni or that went to uni in the past that there professors are extremely pro-comment, which probably doesn't help. Just today I had to review some code with line-by-line comments, and then I found a method blisfully comment-free. The kicker was it was a 6-line C# method along the lines of: ``` HandleErrors(short[] errors) { List errs = new List(); foreach(var err in errors) { if(err > 0) errs.Add(errors[err]); } SendErrorsSomewhere(errs); } ``` I genuinely have no idea what the goal was (maybe just send all the error codes greater than zero?) but...wow. Some human actually wrote this, supposedly tested it, and thought it was good to go.
@@beterbarkeruseless comments is not the same as documenting your code. There are some extremely small functions which do a single operation but still require entire paragraphs of documentation in order to be understood, eg. the fast inverse square root in DOOM.
@@okie9025 that falls under the category of something so complex that it can't be simplified so it should need a comment. It also falls under the category of being library/utility code. I covered that in my original comment. The reason I rant is because I see so many college kids come out thinking they need to comment every single line because that's what they're encouraged to do during school. I'm speaking from experience in what I see during code reviews. I've seen people use comments as a crutch for poorly written code. I get why they push comments in academics so instructors can see the thought process, but I wish more people were taught coming out of school that you should reserve comments for things that actually need it.
treating things like a black box is actually a really really good tip. i'm used to think about every single section of my code as some sort of box that does "magic" once looked inside, which every function has, inherently, consecutive series of algorithms. in the C/C++ community, we are frequently encouraged to know how your code works under the hood, and how every tiny bit works like a concert, which is fascinating, but not always the right scenario, specially for bigger, scaled projects. TLDR: you don't need to reimplement the sorting algorithm if there is a default, safe and performant approach, unless you have a very good reason to. decompose only the important parts of your code, and let the others be in the "just works" field. really good video and looking forward to the next ones!
i was taught to think like a good programmer. i'm so glad someone is finally calling this out. people genuinely don't wanna make these changes to become better at programming
There is some very solid advice in this video, that I don't see people often talk about. The black box method should be how most problems are approached. Test driven development is how I have built some very complicated things, and treating the code as a black box (#1) and focusing on its inputs and output first, makes it really easy to write tests and develop until the tests pass. Thinking in processes (#4) also helps figure out the structure for these inputs and outputs, as well as assisting in migrating you code to other better suited languages, as well as improving your existing code in languages you know of. My best advice for anyone who really wants to follow these advices in this video, is start building things. Don't watch tutorials and guides, don't chase videos that tell you how to get better at something, just build stuff. Keep building and keep failing. Failure is a step forward when it comes to learning. Keep the ideas in this video in the back of your mind, maybe write it down, visit every now and then, and try to implement them in your projects. Some of the advice here may not sound magical enough to make you a "genius programmer", but as your knowledge evolves through experience, they will start to click.
@@RaZziaN1 Black box method or testing? If black box method, then it’s not really a waste of time if you do it quick in your head. It’s a framework for thinking, not an out of the way process you go through. The most you would do is write pseudocode. That’s obviously for the difficult stuff. If you’re working on a project, odds are you’re gonna come across a few difficult things that needs careful planning and thinking, and just diving right in with writing out the code, could mess things up down the line when the code base grows larger. But taking a step back and thinking about what goes in and what goes out, not only helps clarify what the functions are going to be responsible for, but also what you’re gonna name your functions, and how you’re going to test them if that’s what you’re going to do. In the end, the black box method isn’t going to help you when solving like a simple problem, like solving a leetcode question or writing out a function your boss tells you to write. The hard part is knowing what to write, which leetcode or your boss handle in that context. As for testing, it’s only practical on medium-large scale projects, which is mostly what I myself have worked on, though I guess you would only need to do it if you’re responsible for it at your job, or if the project is a personal one. I just think it’s nice to experiment with writing tests, as it forces you to simplify the inputs and outputs of your functions, as well as making them pure, which is making sure a set of inputs always return the same outputs.
i eventually developed thinking is process when i spent a year trying to find a suitable engine/language for game making. i actually got myself hopping and learning basics again and again.
I think the last tip about failure is key. Thinking of failure as valuable means you have a different mindset when things don't work, which is often when you're most frustrated. Yea we might wish we always wrote perfect code, but if you always did then you have less understanding of what could go wrong.
black box method is really nice. First thing to do is to build an abstraction with a mockup, and when it integrates into existing logic well, implement an actual class suitable for business
When I saw the title and thumbnail, I thought I was watching a video with hundreds of thousands of views. I finally looked at the view count again, and I was reminded that I was watching a small channel. Keep up the good work.
People always say break down problems to smaller chunks. But you can't know where to slice up a problem if you've never solved it before. You need to make mistakes to solve problems. Therefore using wrong abstractions and wrong methods. You can't know what chunks to use if you don't know the chunks themselves. If I asked a normal person to perform brain surgery on me. Then just say "don't worry it's easy just break the problem into smaller chunks". I wonder how that will go.
Not only that, but trying to come up with a "perfect" black box solution will only end up making you even more frustrated. Sometimes, especially if you don't have any experience, is to just start coding and improving as you go. There's even a term for it: analysis paralysis. At the end of the day, you got to find a balance between what you are strive for vs what is possible to accomplish right now.
This really helped me understand, I’m starting to get into electronics and a part of that is coding so getting recommend this video was a huge lifesaver
Damn, not even a 1000 subs is absolutely criminal for the quality of this video and how genuinely insightful it is, but at least I get to call myself an OG when you pass 100k, keep it up bro.
Great video, and very reaffirming. As someone in the middle of developing these mindsets, any new developers should listen to what this guy has to say 👍
This is really underrated I know its just have been 1 day but it needs more than 1k views Great editing Great explanation Just a mindblowing video well done
Not everything requires the black box method, but if it's sufficiently complicated, it can help tremendously. I had an example at work where several people spent literal months trying to figure out a good user interface to solve a problem, but I could feel that they were digging themselves into a hole. I took a step back and try to think of the end result that we're trying to achieve, and then compare that to the basic information we begin with. From there, it's a question about how to fill in the gaps, so I focused on that and came up with an example to solve it in a single day. I think this can work as an example of black box thinking. Result (output), what we have (input), and how we fill in the gaps (implementation). It's a lot easier to know what you're missing when you know what you're trying to get. Side note: Don't fall in love with your solution. The sunken cost fallacy is real. Most of my work on this problem was to convince them to even consider my solution instead of digging further into their own hole.
This is a fine video for people who don't know anything about programming or never watched/read something about programming. Tells some of the basic things, all points except 1# are fine, but lack some nuance. With a title like this, you could have talked about the mental model programmers devolop over time. 1# is kinda pushing for "premature abstraction" and I hate saying "premature something", because some *health* forsight is good. But without extra work now or in the past it's easy to ake the wrong decision and waste a lot of time Having experience or asking someone who dealt with this problem OR doing some reading, sketches, experiments, prototypes can save a lot of time and pain. Good think is, as a beginner you don't have to worry to much about most these, you can ignore or work around most problems with enought time and no pressure. About mental models: How a programmer thinks about a problem, how to identify, formulate and implemt a solution. It is a bit like math, but you typical problem aren't math equalation. ONE way to summatize it: It's having data and doing something with it, as in "science of computation". Computers have their own rules, like clock cycles, accesing registers + difference between memory stack and heap, efficient use of threads, network communication, GPUs etc. And don't get me started on structing your code and internal interactions between pieces, because real life is messy and you code will have to handle it. Working with stupid edge-cases when used in real scenarios and working around technical debt, old conventions + standards or inintuitve limits of your computer, code language and/or framework. It's fun to see your stuff actually work.
Although it's not what I intended, I definitely agree with the possibility of #1 coming off that way. I more so wanted to encourage a test driven development approach, and for people to clearly understand the high level of what they want their code to do. But I definitely see how it can come off as premature abstraction. Thanks for your feedback, I'll take it into consideration for my next!
One of the sad parts is that learning programming is not a straightforward way. There's no a defined path, it's all about experimentation and practice.. Usually, people who know how to solve a specific problem have just encountered something similar in the past, and reapply/extrapolate that knowledge on new problems. So, one might be quite hesitant to say that some specific rule Y would make one a genius... it seems that it's just the ability to learn quickly, adapt, and just spend lots of time on a specific subject... which is so abstract that can be applied to any skill 🍞
@@sultim7570Besides Practical Experience, doing things like: Reading about theory and technical details (I'm a CS-Student btw :P), Looking at the code of others, Reading documentation and best practices, Reading discussion and opinions or Having some people you can ask about problems ... all that can really add up over time. And please don't you think I'm a pro or something, I just read a lot, did a few projects and love puzzle games.
The tip I always give to my students is to try and solve the problem in paint (or on a piece of paper) before even thinking about the code. It makes wonders.
Programmer = Coder = Software Engineer. There's no upgrades, titles are separated to introduce artificial differences in hierarchy. Each one of them needs to know the problem and how to implement a solution that works best to solve it. There's no role where someone blindly types code, or writes a program because someone asked you to.
@@bl00dspec75 Yes, critical thinking is required in all roles, but in general, the expected roles and responsibilities *are* actually different with each title. I don't think it's artificial difference in hierarchy. In addition to implementation, SWEs are also expected to design solutions for ambiguous problems usually across a broader array of systems and come up with the tasks for implementation. Programmers are expected to be able to implement these tasks successfully.
Bro I just checked your channel, seems you're starting a new channel. All the best❤ .... I was so impressed that I wanted to cover all the videos you've been making till now ( like it's rare for me that I get such good videos) already subscribed and waiting for more 😊😊🎉
I realised that I had to think in terms of process when I went a bit more deep into game development. If you want to make an object move towards another object it's pretty easy to understand it and get to coding right away. But when you want to achieve stuff like procedural animation you will realise how, while it's still objects moving towards other objects, it's harder to get to coding right away, You have to view the process, understand how procedural animation is based on inverse kinematics and understand the logic behind inverse kinematics. This is why when I want to learn something new in programming in general I search for the logic, the process instead of the code. Edit: but that's just one of many ofc. There are these magic words which hold all the logic and process behind a code. Cellular automata and 2D voxels is the base behind how a game like Noita can exist, context steering is an interesting way you can make fights with your enemies better, don't even get me started about quadtrees.
Why are people expecting this dude to give you the blueprint to making the next Google or something?? Lol the advice in this video is good, consolidated, and most importantly actionable.
As a programmer, before ever thinking about efficiency, you must think about correctness. It doesn't matter how fast you are if you're wrong. Make it run, make it right, make it fast.
I was more trying to insinuate that abstraction allows you to break down problems and focus on things you might miss if you don't. I was trying to say that abstraction can be used to help you solve the problem. Apologies if it wasn't clear, but thanks for the feedback, I'll take it into account!
i clicked on this video just for the content, And this is really good, content 10/10, editing 10/10, script 10/10, But i was a little disappointed by the number of subs and views i hope this blows up! you got a sub btw
the true mark of a genius programmer is knowing that oauth 2.0, jwts, sso, login UIs, openid connect, sessions, and cookies have absolutely nothing to do with each other
Most people do test manually, like in the old days. That's OK too. Writing it is just for the repeated test after each change "is it still OK", "is it still OK", etc.
@@holger_p I've never been opposed to the idea I just never worked at a place that did it 😅 starting a new job soon where they use Jest though so hopefully I'll learn a lot doing that
@@estoyboy you do it for yourself, or you bring it yourself into the company and get a promotion. You just need to ask, if you are allowed to invest some time.
corollary to the first point wrt scaling: think about what scaling is actually needed of the black box. There are many instances where a piece of code will only run sporadically, and optimizing for speed is a waste of time, as a beginner I found myself spending afternoons attempting to shave nanos off the runtime of functions that would run once a second or so, with no real sensitivity to latency(e.g. not hft).
I often see comments like "beginners shouldn't use IDEs and libraries or frameworks to study programming", but in fact, the terminal and the programming language itself are nothing but a specific sort of interface and tool itself. If we really were to follow this advice, I think beginners should start out writing assembler with 0s and 1s on paper before ever touching anything.
A genius loves abstractions or complexity but they made it look simple because they also know their own limit of how smart they are , People who are not smart don't know their own limit so they became arrogant and boast about how smart they are, The Dunning-Kruger effect with their own cognitive bias
terry made his own language to make it easier to program his own OS. If that's not an abstract way of programmimg (compared to just using ordinary C and standard methods of OSdev) then I don't know what is.
IMO, drawing algorithm again, again and again is key for think in terms of process. In my university, my professors used to build random projects, now I think these were truly good for understanding programming even thought I just randomly did copy and paste and seek the solution on the process of making that copied outdated code to work. so I believe in @abtix comment as getting better will be depended on the attempt after failure
Hi Lattice, I discovered your UA-cam channel a few days ago, and I've to say I'm at first was watching a huge UA-cam creator and not a small channels because of the highquality content, and their lore is awesome. So, a HUGE thank you! After a little research (sorry, not sorry), I realized that you're not fully leveraging your Twitter, UA-cam, and personal website. With your passion, expertise, and engaging content, I believe you could build authority via these organic channels, grow your audience more, and possibly become a successful creator by the end of the year. As a ghostwriter and senior full-stack developer, I can help you repurpose the content you already have on your UA-cam channel to create engaging titles, descriptions, short and long-format posts on Twitter, threads, blogs, and much more! I would like to share my portfolio with some examples of how I would approach this and would love to know your thoughts.
It's all "black boxes" and "clean code" until you need to optimize. And when you need to optimize, it's often already too late to structure this all in cache and branch predition-friendly manner.
Shh, if those kids could read, they would be very disappointed. From my 7 years of experience I learned that pro programmers are plain programmers and code is code. All those clean code street programmer 10x chad talk is bullshit and only needed sparsely, with the supervision of an actual senior with set number of years of working experience. In my personal projects I found that many of the problems could be completely eliminated if I just wrote code; plain old unfiltered 1 function programs that do everything. No need to micro abstract and clean code everything. Doing so will yield bad results in the short and long term combined, but you get the feeling that you're doing everything "right". The faster you do a program, the faster you learn its inner workings and the hiccups involved.
There are always 3 forces fighting each other: readability, optimization, and low coupling. And you can't get everything. Any of these properties in your code should be "good enough" and fit the task. In microcontrollers and game engines, optimization is a priority. But in billing systems - readability and low coupling are important. Because any misunderstanding in business logic or a vulnerable error will cost you much more money than one additional server in the cloud. So it all depends on the purpose of your system and the capabilities that this software performs
@@MrShnaiderTV Quite an interesting viewpoint. I've never worked on a such systems and much of my experience is in graphics programming and operating systems where performance and throughput is high-priority.
DISCLAIMER: THIS VIDEO IS FOR A GENERAL AUDIENCE AND WILL NOT GET YOU EMPLOYED(sadly). Programming is subjective, and I'm sure I put some incorrect things in this video, so take what I say with a grain of salt. These are all just my opinions as a content creator/programmer. At the end of the day, a UA-cam video can not make you a professional programmer. but I hope it helps even one person who's beginning to learn to program/code. Also be sure to check out my inspirations for this video in the description, such as ModernIdeas and Fireship. Also, watching this back, I made the music way too loud. Sorry if it's hard to hear! Lastly, I appreciate each and every one of you for your feedback, even the negatives, as I want to give the best advice and video possible. Thank you all!
It's amazing video. And with certain abstractions in mind it can be applied to ANY field of work.
Great job!
Delete this. Ur advice applies to any video and ur comments show u don't believe in urself.
It's a very good video and well thought. If people complain, it's because they can't handle reality. I was exactly reflecting on the black box concept in these days.
@@p19shelt I agree. The video was well made and had good general advice for a programmer. The comment about bootcamp/clean code was just a dig with some truth in it, but it doesn't mean it was a bad video. The creator's self doubt in his comments makes newer developers unsure if they should trust his advice. Just ask for fair criticism and choose which ones to improve on the next video.
@@p19shelt I understand my advice is general because it's made for a broad audience, as most videos are. I believe in myself 100%, which is why I don't delete any negative comments and instead I try and learn from them. I'm pretty open minded and I understand people have different views on what makes a good programmer. So when I reply to comments like these, it's not self doubt, it's just me learning your opinion and explaining mine. but ultimately if you were looking for non-general advice on programming, you shouldn't be looking on UA-cam. At the end of the day this is just a UA-cam video, not a course.
My professor once said "You don't have to create the algorithm if it already exist. You just have to know, understand, and implement it"
Guess what your professor was wrong. Probably that's why hes still teaching how to do things, not doing anything himself.
@21stchill18 This doesn't even make sense my guy. If the algorithm has already been invented, you can't reinvent it. You can only learn and understand it.
@@maidenlesstarnished8816 pretty sure there more than one way to do the same thing. that's the exact reason we're still inventing new algorithms each and every year, getting slightly better in each.
@21stchill18 In which case a new algorithm was invented. That's not what their professors quote was about.
@@maidenlesstarnished8816 wth are you talking about. I've replied to your comment not what their professor said.
Sounds like what someone who read too many pages of clean code and just got out of a bootcamp would say
lol not wrong, (for clarification, I've never read clean code or done a bootcamp, I just thought this was a funny comment)
My exact thoughts.
Can we please create good content!
bro doesn't even deny it
so... is the content reliable or good?
@@unknownperson9234 Neither.
1. Don't think about the processing yet, just the scalability and big picture
2. Make your code readable. Comments, meaningful names, conventions
3. Use frameworks & libraries to save time
4. Think in process, not in code, think of the solution not the code
The last one I think is well-meaning but is a bit of a trap. Programming languages are much more precise and unambiguous than natural language, so if you're working in a particular environment it may be easier to think in terms of the tools that environment provides. Much like how when planning how to build a cabinet you would think in terms of the tools you have rather than "magically form this complicated three-dimensional shape out of plywood".
That said, if you need a tool but are not limited on technologies, thinking about what the requirements are could help make a selection.
I want to shoot myself when I see comments in code. Comments should only be there if you have to hardcode magic numbers (ie DB ids), if there is something so goofy that you have to comment so someone knows why you did it that way, or if there is no way to make something less complex so you have to leave a comment explaining it for a future dev. The only other time I think you should absolutely leave it is when you need to leave doco code for custom library utilities in an application. It is really nice when somebody writes javadoc on these kind of functions so my Intellisense can give me a rundown of the library when I hover over methods.
I've seen it enough times where somebody has a function called "getTaskList" and then the comment above the function says "returns the task list"... Ya thanks... Didn't know what I would be getting based on the function name... Really saved me -_- . I see this in so many tutorials, and I swear the language I see this the most in is Python. Useless comments are so much worse than not having the comment at all. You are writing code for other coders.
It is also worth thinking that if your code is so convoluted or complex that you need comments to read it, then there might be something wrong with your code. When I have to pull somebody's code and it's littered with comments, the first thing I do is remove all the useless ones so I can actually see what the code is doing.
Sorry for the mini rant. I just hate useless comments and people should get in the habit of writing code that doesn't need to have the comments.
@@beterbarker I agree for the most part, particularly comments that are either clearly autogenerated (uselessly) or a line-by-line description of what the code does. I hear from friends in uni or that went to uni in the past that there professors are extremely pro-comment, which probably doesn't help.
Just today I had to review some code with line-by-line comments, and then I found a method blisfully comment-free. The kicker was it was a 6-line C# method along the lines of:
```
HandleErrors(short[] errors)
{
List errs = new List();
foreach(var err in errors)
{
if(err > 0)
errs.Add(errors[err]);
}
SendErrorsSomewhere(errs);
}
```
I genuinely have no idea what the goal was (maybe just send all the error codes greater than zero?) but...wow. Some human actually wrote this, supposedly tested it, and thought it was good to go.
@@beterbarkeruseless comments is not the same as documenting your code. There are some extremely small functions which do a single operation but still require entire paragraphs of documentation in order to be understood, eg. the fast inverse square root in DOOM.
@@okie9025 that falls under the category of something so complex that it can't be simplified so it should need a comment. It also falls under the category of being library/utility code. I covered that in my original comment. The reason I rant is because I see so many college kids come out thinking they need to comment every single line because that's what they're encouraged to do during school. I'm speaking from experience in what I see during code reviews.
I've seen people use comments as a crutch for poorly written code. I get why they push comments in academics so instructors can see the thought process, but I wish more people were taught coming out of school that you should reserve comments for things that actually need it.
treating things like a black box is actually a really really good tip. i'm used to think about every single section of my code as some sort of box that does "magic" once looked inside, which every function has, inherently, consecutive series of algorithms. in the C/C++ community, we are frequently encouraged to know how your code works under the hood, and how every tiny bit works like a concert, which is fascinating, but not always the right scenario, specially for bigger, scaled projects.
TLDR: you don't need to reimplement the sorting algorithm if there is a default, safe and performant approach, unless you have a very good reason to. decompose only the important parts of your code, and let the others be in the "just works" field.
really good video and looking forward to the next ones!
i was taught to think like a good programmer. i'm so glad someone is finally calling this out. people genuinely don't wanna make these changes to become better at programming
Literally thought this was a big channel until I peeked at the view count. Production quality is HUGE in here!! Awesome content ❤
Appreciate it!!
Bro LITERALLY copy pasted the script & visuals from a popular video called "How to unfuck your brain" & made it about coding.
@@JreTV-ib3en visuals are similar but the topic of this video is its own thing 🤔 don't know where you got that from
@@henryisaway topic different, same script ... just replace words based on topic ... 0 creativity.
@@JreTV-ib3en whatever you say, mate 🤷
There is some very solid advice in this video, that I don't see people often talk about. The black box method should be how most problems are approached. Test driven development is how I have built some very complicated things, and treating the code as a black box (#1) and focusing on its inputs and output first, makes it really easy to write tests and develop until the tests pass. Thinking in processes (#4) also helps figure out the structure for these inputs and outputs, as well as assisting in migrating you code to other better suited languages, as well as improving your existing code in languages you know of.
My best advice for anyone who really wants to follow these advices in this video, is start building things. Don't watch tutorials and guides, don't chase videos that tell you how to get better at something, just build stuff. Keep building and keep failing. Failure is a step forward when it comes to learning. Keep the ideas in this video in the back of your mind, maybe write it down, visit every now and then, and try to implement them in your projects. Some of the advice here may not sound magical enough to make you a "genius programmer", but as your knowledge evolves through experience, they will start to click.
sounds great, but no one builds programs this way, it's waste of time in real life. It's used mainly as interview question and that's it.
@@RaZziaN1 Black box method or testing? If black box method, then it’s not really a waste of time if you do it quick in your head. It’s a framework for thinking, not an out of the way process you go through. The most you would do is write pseudocode. That’s obviously for the difficult stuff. If you’re working on a project, odds are you’re gonna come across a few difficult things that needs careful planning and thinking, and just diving right in with writing out the code, could mess things up down the line when the code base grows larger. But taking a step back and thinking about what goes in and what goes out, not only helps clarify what the functions are going to be responsible for, but also what you’re gonna name your functions, and how you’re going to test them if that’s what you’re going to do. In the end, the black box method isn’t going to help you when solving like a simple problem, like solving a leetcode question or writing out a function your boss tells you to write. The hard part is knowing what to write, which leetcode or your boss handle in that context.
As for testing, it’s only practical on medium-large scale projects, which is mostly what I myself have worked on, though I guess you would only need to do it if you’re responsible for it at your job, or if the project is a personal one. I just think it’s nice to experiment with writing tests, as it forces you to simplify the inputs and outputs of your functions, as well as making them pure, which is making sure a set of inputs always return the same outputs.
i eventually developed thinking is process when i spent a year trying to find a suitable engine/language for game making. i actually got myself hopping and learning basics again and again.
YUP! Just Build It (swoosh)
It's kinda funny that my mentor said the same things to me when I first started my job. NIce video!
I think the last tip about failure is key. Thinking of failure as valuable means you have a different mindset when things don't work, which is often when you're most frustrated. Yea we might wish we always wrote perfect code, but if you always did then you have less understanding of what could go wrong.
Amazing video, completely agree with the black box and using existing frameworks points
black box method is really nice. First thing to do is to build an abstraction with a mockup, and when it integrates into existing logic well, implement an actual class suitable for business
When I saw the title and thumbnail, I thought I was watching a video with hundreds of thousands of views. I finally looked at the view count again, and I was reminded that I was watching a small channel. Keep up the good work.
Thank you!
I didn't notice until I read this. 😮
Bro LITERALLY copy pasted the script & visuals from a popular video called "How to unfuck your brain" & made it about coding.
Man. You're going to BLOW UP, very fast! This is some HIGH QUALITY content.
I appreciate that!
Bro LITERALLY copy pasted the script & visuals from a popular video called "How to unfuck your brain" & made it about coding.
People always say break down problems to smaller chunks. But you can't know where to slice up a problem if you've never solved it before. You need to make mistakes to solve problems. Therefore using wrong abstractions and wrong methods. You can't know what chunks to use if you don't know the chunks themselves.
If I asked a normal person to perform brain surgery on me. Then just say "don't worry it's easy just break the problem into smaller chunks". I wonder how that will go.
this is why we should fuzz everything.
Not only that, but trying to come up with a "perfect" black box solution will only end up making you even more frustrated. Sometimes, especially if you don't have any experience, is to just start coding and improving as you go. There's even a term for it: analysis paralysis.
At the end of the day, you got to find a balance between what you are strive for vs what is possible to accomplish right now.
Yeah it's pretty hard to know what the correct abstraction is until you can see why another one is wrong
No one tells you why the box is black. It’s because it works faster
💀
now this is a x10 developer
Something that only Peter griffin would say.
....i dont feel like this joke was told right💀
🤣🤣
the small channels are really built different now a days , very good production quality.
Wish this sort of design thinking was taught in school… even a 1 credit seminar course would be really useful for newcomers.
ayooo this is fire, the explanations the editing... subscribed !!!
This really helped me understand, I’m starting to get into electronics and a part of that is coding so getting recommend this video was a huge lifesaver
Love your style, this should have way more views!
Here before this goes viral
This is so useful! As a highschool student I understood alot from this video! Thanks a lot Mr. Lattice
Glad it was helpful!
Damn, not even a 1000 subs is absolutely criminal for the quality of this video and how genuinely insightful it is, but at least I get to call myself an OG when you pass 100k, keep it up bro.
thanks!
Great video, and very reaffirming. As someone in the middle of developing these mindsets, any new developers should listen to what this guy has to say 👍
Thanks, it means a lot!
the quality of your video as new a youtuber is amazing!!
Thank you so much!!
I had a mock google interview yesterday. The number one advice that my interviewer gave me was to use the black box method. Subscribed!!!
Wow, I'm happy to hear that! thanks for the sub and good luck with your interviews
I think an extended version of this video with the concepts explained or with good and bad examples would be really itneresting.
love the aesthetic, its gonna pull views. I reckon a behind-the-scenes of ur video editing workflow would be popular too.
Engaging editing style and solid advice. Keep going and the subscribers will come. Just getting this on the suggested page is a big achievement 💪
Thanks a lot
On part with bigboxswe, fireship, dreams of code, code aesthetic, etc etc. Great video, and great quality.
Thank you so much!
unique style too
On par, 'right'!
Bro LITERALLY copy pasted the script & visuals from a popular video called "How to unfuck your brain" & made it about coding.
Really great video, man! Thanks!
Thanks for the video, lots of junior that don't really understand what programming is
here before this video and channel blows up, great content!
Appreciate it!
This is really underrated
I know its just have been 1 day but it needs more than 1k views
Great editing
Great explanation
Just a mindblowing video well done
Thank you!
Yep, you're going to become popular like the likes of BigBoxSWE (I'm new to this field)
Thank you
Thinking as a true programmer is making your code so complicated and not maintainable for your team so your company can't get rid of you.
Great stuff bro, keep going.
Thanks, it means a lot
Not everything requires the black box method, but if it's sufficiently complicated, it can help tremendously.
I had an example at work where several people spent literal months trying to figure out a good user interface to solve a problem, but I could feel that they were digging themselves into a hole. I took a step back and try to think of the end result that we're trying to achieve, and then compare that to the basic information we begin with. From there, it's a question about how to fill in the gaps, so I focused on that and came up with an example to solve it in a single day.
I think this can work as an example of black box thinking. Result (output), what we have (input), and how we fill in the gaps (implementation). It's a lot easier to know what you're missing when you know what you're trying to get.
Side note: Don't fall in love with your solution. The sunken cost fallacy is real. Most of my work on this problem was to convince them to even consider my solution instead of digging further into their own hole.
that last point really hit
The best video I saw ever about programming. Cheers to more such content from you
Thanks!
This is a fine video for people who don't know anything about programming or never watched/read something about programming. Tells some of the basic things, all points except 1# are fine, but lack some nuance. With a title like this, you could have talked about the mental model programmers devolop over time.
1# is kinda pushing for "premature abstraction" and I hate saying "premature something", because some *health* forsight is good. But without extra work now or in the past it's easy to ake the wrong decision and waste a lot of time Having experience or asking someone who dealt with this problem OR doing some reading, sketches, experiments, prototypes can save a lot of time and pain.
Good think is, as a beginner you don't have to worry to much about most these, you can ignore or work around most problems with enought time and no pressure.
About mental models: How a programmer thinks about a problem, how to identify, formulate and implemt a solution.
It is a bit like math, but you typical problem aren't math equalation. ONE way to summatize it: It's having data and doing something with it, as in "science of computation".
Computers have their own rules, like clock cycles, accesing registers + difference between memory stack and heap, efficient use of threads, network communication, GPUs etc.
And don't get me started on structing your code and internal interactions between pieces, because real life is messy and you code will have to handle it. Working with stupid edge-cases when used in real scenarios and working around technical debt, old conventions + standards or inintuitve limits of your computer, code language and/or framework.
It's fun to see your stuff actually work.
Although it's not what I intended, I definitely agree with the possibility of #1 coming off that way. I more so wanted to encourage a test driven development approach, and for people to clearly understand the high level of what they want their code to do. But I definitely see how it can come off as premature abstraction. Thanks for your feedback, I'll take it into consideration for my next!
One of the sad parts is that learning programming is not a straightforward way. There's no a defined path, it's all about experimentation and practice..
Usually, people who know how to solve a specific problem have just encountered something similar in the past, and reapply/extrapolate that knowledge on new problems.
So, one might be quite hesitant to say that some specific rule Y would make one a genius... it seems that it's just the ability to learn quickly, adapt, and just spend lots of time on a specific subject... which is so abstract that can be applied to any skill 🍞
@@sultim7570Besides Practical Experience, doing things like:
Reading about theory and technical details (I'm a CS-Student btw :P), Looking at the code of others, Reading documentation and best practices, Reading discussion and opinions or Having some people you can ask about problems ... all that can really add up over time.
And please don't you think I'm a pro or something, I just read a lot, did a few projects and love puzzle games.
Just subscribed dude, you have it in you
keep going
Good advice to help me write better code.Keep up the good work
Loved this... I often get stuck because I overthink all of the ways to do it
bro this looks like modern ideas youtube channel, i love his style
The tip I always give to my students is to try and solve the problem in paint (or on a piece of paper) before even thinking about the code. It makes wonders.
loved the advice. Will try to implement, Thanks
Outstanding video! Can't wait to see more of your content
Really good video.
Reminds me of fireship.
Love your style and content quality
Programmer = Coder. The upgrade of that is an Engineer
Yes, agreed 1000%. Thank you for calling this out
Programmer = Coder = Software Engineer. There's no upgrades, titles are separated to introduce artificial differences in hierarchy.
Each one of them needs to know the problem and how to implement a solution that works best to solve it.
There's no role where someone blindly types code, or writes a program because someone asked you to.
@@bl00dspec75 Yes, critical thinking is required in all roles, but in general, the expected roles and responsibilities *are* actually different with each title. I don't think it's artificial difference in hierarchy.
In addition to implementation, SWEs are also expected to design solutions for ambiguous problems usually across a broader array of systems and come up with the tasks for implementation. Programmers are expected to be able to implement these tasks successfully.
clean and apt visuals. Loved the vid.
here b4 this blows up
Beside the materials you presented whether its true or wrong here, I like how you deliver information for your audience, keep going !
Bro I just checked your channel, seems you're starting a new channel. All the best❤ .... I was so impressed that I wanted to cover all the videos you've been making till now ( like it's rare for me that I get such good videos) already subscribed and waiting for more 😊😊🎉
Ok, you got a new sub. I expect great things of this channel
I noticed that you edit your videos like modern ideas. 👍
Yes him and @this.science are huge inspirations for my editing
@@LatticeCodes inspiration is a good thing.
Watching this actually video made me feel like a good programmer.
Modern Ideas type video in coding niche, I like it
Thanks, I'm glad you enjoyed!
This is how we were taught when I was in school in the late 80's.
Automated tests didn't exist back then. Not even on the horizon.
Keep up the work and stay consistent with uploads, great and quality advice👍🏻. Also remember me before your chanel geets super famous 🤐
Thank you, If that happens I won't forget!
Here before you get big!
Omg how do you not 100k already
Excellent video!
I needed this video today
Nice insights. Really got me thinking.
I realised that I had to think in terms of process when I went a bit more deep into game development. If you want to make an object move towards another object it's pretty easy to understand it and get to coding right away. But when you want to achieve stuff like procedural animation you will realise how, while it's still objects moving towards other objects, it's harder to get to coding right away, You have to view the process, understand how procedural animation is based on inverse kinematics and understand the logic behind inverse kinematics. This is why when I want to learn something new in programming in general I search for the logic, the process instead of the code.
Edit: but that's just one of many ofc. There are these magic words which hold all the logic and process behind a code. Cellular automata and 2D voxels is the base behind how a game like Noita can exist, context steering is an interesting way you can make fights with your enemies better, don't even get me started about quadtrees.
Thank you for the helpful content. Keep up the great work! 😃
My pleasure!
فيدو حلو استمر متابعك من الشرق الأوسط ❤
شكرا لك، وأنا أقدر ذلك
Why are people expecting this dude to give you the blueprint to making the next Google or something?? Lol the advice in this video is good, consolidated, and most importantly actionable.
As a programmer, before ever thinking about efficiency, you must think about correctness. It doesn't matter how fast you are if you're wrong.
Make it run, make it right, make it fast.
OMG a programming video edited in the style similar to modern ideas
We really don't need more people perpetuating the idea that thinking about how to abstract a problem you haven't even solved yet is a good idea.
I was more trying to insinuate that abstraction allows you to break down problems and focus on things you might miss if you don't. I was trying to say that abstraction can be used to help you solve the problem. Apologies if it wasn't clear, but thanks for the feedback, I'll take it into account!
First tip is the bomb 👍
i clicked on this video just for the content, And this is really good, content 10/10, editing 10/10, script 10/10, But i was a little disappointed by the number of subs and views i hope this blows up! you got a sub btw
Appreciate it!
@@LatticeCodes thanks
Great advice!
wow nice video! now i gotta finish my crud.
Awesome vid man. After a sentence is done, take a tiny break, seems rushed :D Ur gonna be big ✌🏼
Will do! and thanks
How to think like A GENIUS Programmer: Know the difference between authentication and authorization, before you start using OAuth or JWT.
the true mark of a genius programmer is knowing that oauth 2.0, jwts, sso, login UIs, openid connect, sessions, and cookies have absolutely nothing to do with each other
This video made me feel like a good programmer.
"...create test cases" I definitely have a long way to go then as I've never written a test in my life
Most people do test manually, like in the old days. That's OK too. Writing it is just for the repeated test after each change "is it still OK", "is it still OK", etc.
@@holger_p I've never been opposed to the idea I just never worked at a place that did it 😅 starting a new job soon where they use Jest though so hopefully I'll learn a lot doing that
@@estoyboy you do it for yourself, or you bring it yourself into the company and get a promotion. You just need to ask, if you are allowed to invest some time.
good video, you're gonna make it big 💯
Appreciate it
this is awesome
Great video! You earned yourself a sub.
Thanks!
Muito bom o seu vídeo, sucesso!
muito obrigado!
Nice suggestion 😊
Thanks 😊
Thank you for the small amount of Flashbanks :)
My pleasure!
I was here before this starts to blow up
Thanks, it means a lot!
corollary to the first point wrt scaling: think about what scaling is actually needed of the black box. There are many instances where a piece of code will only run sporadically, and optimizing for speed is a waste of time, as a beginner I found myself spending afternoons attempting to shave nanos off the runtime of functions that would run once a second or so, with no real sensitivity to latency(e.g. not hft).
What I hate about college is they only care about the result, and never teach you about other use cases and scalability
lol i was sure its a huge channel, nice vid
Thanks
I often see comments like "beginners shouldn't use IDEs and libraries or frameworks to study programming", but in fact, the terminal and the programming language itself are nothing but a specific sort of interface and tool itself. If we really were to follow this advice, I think beginners should start out writing assembler with 0s and 1s on paper before ever touching anything.
You missed the point
@@NoOne-ev3jn can you please explain?
i agree, a terminal program in an OS is actually still extremely high level, the only difference between a terminal and an advanced IDE is a UI.
@@okie9025 Yes, that's my point. Both are just UI. There's nothing more advanced about text UIs other than the steeper learning curve.
please do not conflate abstraction and genius. "An idiot admires complexity, a genius admires simplicity" - Terry Davis, RIP
A genius loves abstractions or complexity but they made it look simple because they also know their own limit of how smart they are ,
People who are not smart don't know their own limit so they became arrogant and boast about how smart they are, The Dunning-Kruger effect with their own cognitive bias
terry made his own language to make it easier to program his own OS. If that's not an abstract way of programmimg (compared to just using ordinary C and standard methods of OSdev) then I don't know what is.
great channel. keep it up
i still dont belive that its just a 6 min video
feels like my world has changed
IMO, drawing algorithm again, again and again is key for think in terms of process. In my university, my professors used to build random projects, now I think these were truly good for understanding programming even thought I just randomly did copy and paste and seek the solution on the process of making that copied outdated code to work. so I believe in @abtix comment as getting better will be depended on the attempt after failure
Hi Lattice,
I discovered your UA-cam channel a few days ago, and I've to say I'm at first was watching a huge UA-cam creator and not a small channels because of the highquality content, and their lore is awesome. So, a HUGE thank you!
After a little research (sorry, not sorry), I realized that you're not fully leveraging your Twitter, UA-cam, and personal website. With your passion, expertise, and engaging content, I believe you could build authority via these organic channels, grow your audience more, and possibly become a successful creator by the end of the year.
As a ghostwriter and senior full-stack developer, I can help you repurpose the content you already have on your UA-cam channel to create engaging titles, descriptions, short and long-format posts on Twitter, threads, blogs, and much more! I would like to share my portfolio with some examples of how I would approach this and would love to know your thoughts.
It's all "black boxes" and "clean code" until you need to optimize. And when you need to optimize, it's often already too late to structure this all in cache and branch predition-friendly manner.
Shh, if those kids could read, they would be very disappointed.
From my 7 years of experience I learned that pro programmers are plain programmers and code is code. All those clean code street programmer 10x chad talk is bullshit and only needed sparsely, with the supervision of an actual senior with set number of years of working experience.
In my personal projects I found that many of the problems could be completely eliminated if I just wrote code; plain old unfiltered 1 function programs that do everything. No need to micro abstract and clean code everything. Doing so will yield bad results in the short and long term combined, but you get the feeling that you're doing everything "right". The faster you do a program, the faster you learn its inner workings and the hiccups involved.
There are always 3 forces fighting each other: readability, optimization, and low coupling. And you can't get everything. Any of these properties in your code should be "good enough" and fit the task. In microcontrollers and game engines, optimization is a priority. But in billing systems - readability and low coupling are important. Because any misunderstanding in business logic or a vulnerable error will cost you much more money than one additional server in the cloud. So it all depends on the purpose of your system and the capabilities that this software performs
@@MrShnaiderTV Quite an interesting viewpoint. I've never worked on a such systems and much of my experience is in graphics programming and operating systems where performance and throughput is high-priority.
wao this is exactly what our ("Informatik" in german) teacher is telling us