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 RUclips 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 RUclips. At the end of the day this is just a RUclips 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!
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.
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.
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.
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 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
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
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.
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.
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
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 👍
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.
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.
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
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.
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.
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 😊😊🎉
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.
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.
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.
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).
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
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
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!
TDD (Test Driven Development) may sound nice on paper, but it's a bad way to do it, and it encourages your bad starting assumptions. A better way to do stuff: 1. make the damn thing, and figure out down the road how the small details will work. 2. test if it does what you expected it to do. Now it will do what you want it to do rather than what you expected it to do or hoped it would do, and when you modify it in the future it will from the outside essentially look the same. Also, abstractions can be nice, but you don't need to abstract literally everything. This actually often leads to worse code, both in performance, and in it becoming a tangled mess that you hoped would work out in the beginning, but then the goal changed and you had to either rewrite it (and hopefully not make the same mistake again), or live with the ever growing mess of bad assumptions you have made. Also, just because something is an "industry standard", it doesn't mean that it's a good way to do it, it's just a popular way to do it. Sadly a lot of "industry standards" make it easy to make a mess while thinking it's not a mess. So instead figure out a way that works for your team, rather than something that works for someone else, and may not actually work for you, or work at all.
I actually never understood TDD, but I think what he might be trying to practice is more what a BA would typically do for you. A BA would ideally be able to do your data modelling for you while blackboxing the actual methods and classes needed. I have seen a team with a really good BA that planned out everything for them from end to end. The devs didn't need to do much thinking, they just wrote and tested to the requirements and was able to create very reusable and scalable code. There were some changes along the way, but it helped that someone already made the effort to plan all the logic flows.
@@JreTV-ib3en checking the video, he did copy the style, but the script is different since it is another theme. The selection of stock videos is also different. I guess this style is a recipe for views. I saw worse type of copying on youtube, where the youtube literally copy almost everything, even the title, just changing a word here or there.
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.
Thinking about scalability first is a mistake because you will not need it most of the time. Making it work first is much better than worrying about making it fast or scalable later. Especially since programmers have a terrible track record of knowing in advance what will be the bottleneck, so you're better off writing a reasonable version first. If performance becomes a problem, measure to find and fix the bottleneck.
You're describing a software engineer, not a good programer, a good programer actually focuses on how to solve the problem, doesn't care about scaling, a good programer has an understanding of data structures and algorithms, a lot of people confuse software engineering with computer science
"use comments" isn't necessary but especially if there's something you just wrote, think about reading this as a different person and thinking "why do I do this exactly?" and then write a comment explaining why so others can understand it easily
regardin the wheel I know that a team of people focused on developing something (e.g. OAuth) is going to be way better than me. Especially at covering all kinds of security vulnerabilities I can't even think about it.
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 RUclips 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 RUclips. At the end of the day this is just a RUclips 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.
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 🤷
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!
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💀
🤣🤣
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)
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.
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.
the small channels are really built different now a days , very good production quality.
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
ayooo this is fire, the explanations the editing... subscribed !!!
Love your style, this should have way more views!
Wish this sort of design thinking was taught in school… even a 1 credit seminar course would be really useful for newcomers.
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
Amazing video, completely agree with the black box and using existing frameworks points
It's kinda funny that my mentor said the same things to me when I first started my job. NIce video!
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
Really great video, man! Thanks!
This is so useful! As a highschool student I understood alot from this video! Thanks a lot Mr. Lattice
Glad it was helpful!
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
that last point really hit
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!
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.
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
the quality of your video as new a youtuber is amazing!!
Thank you so much!!
Great stuff bro, keep going.
Thanks, it means a lot
here before this video and channel blows up, great content!
Appreciate it!
Just subscribed dude, you have it in you
keep going
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!
love the aesthetic, its gonna pull views. I reckon a behind-the-scenes of ur video editing workflow would be popular too.
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.
Here before this goes viral
clean and apt visuals. Loved the vid.
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 best video I saw ever about programming. Cheers to more such content from you
Thanks!
Good advice to help me write better code.Keep up the good work
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.
Thanks for the video, lots of junior that don't really understand what programming is
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.
I think an extended version of this video with the concepts explained or with good and bad examples would be really itneresting.
Outstanding video! Can't wait to see more of your content
Love your style and content quality
loved the advice. Will try to implement, Thanks
Loved this... I often get stuck because I overthink all of the ways to do 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!
Ok, you got a new sub. I expect great things of this channel
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.
Nice insights. Really got me thinking.
Yep, you're going to become popular like the likes of BigBoxSWE (I'm new to this field)
Thank you
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.
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.
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
Here before you get big!
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 😊😊🎉
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!
Thank you for the helpful content. Keep up the great work! 😃
My pleasure!
Really good video.
Reminds me of fireship.
Excellent video!
I needed this video today
good video, you're gonna make it big 💯
Appreciate it
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.
"...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.
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.
Great advice!
Beside the materials you presented whether its true or wrong here, I like how you deliver information for your audience, keep going !
Omg how do you not 100k already
First tip is the bomb 👍
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.
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).
Modern Ideas type video in coding niche, I like it
Thanks, I'm glad you enjoyed!
Watching this actually video made me feel like a good programmer.
Great video! You earned yourself a sub.
Thanks!
wow nice video! now i gotta finish my crud.
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
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
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!
i still dont belive that its just a 6 min video
feels like my world has changed
OMG a programming video edited in the style similar to modern ideas
great channel. keep it up
TDD (Test Driven Development) may sound nice on paper, but it's a bad way to do it, and it encourages your bad starting assumptions.
A better way to do stuff: 1. make the damn thing, and figure out down the road how the small details will work. 2. test if it does what you expected it to do.
Now it will do what you want it to do rather than what you expected it to do or hoped it would do, and when you modify it in the future it will from the outside essentially look the same.
Also, abstractions can be nice, but you don't need to abstract literally everything. This actually often leads to worse code, both in performance, and in it becoming a tangled mess that you hoped would work out in the beginning, but then the goal changed and you had to either rewrite it (and hopefully not make the same mistake again), or live with the ever growing mess of bad assumptions you have made.
Also, just because something is an "industry standard", it doesn't mean that it's a good way to do it, it's just a popular way to do it. Sadly a lot of "industry standards" make it easy to make a mess while thinking it's not a mess. So instead figure out a way that works for your team, rather than something that works for someone else, and may not actually work for you, or work at all.
I actually never understood TDD, but I think what he might be trying to practice is more what a BA would typically do for you. A BA would ideally be able to do your data modelling for you while blackboxing the actual methods and classes needed. I have seen a team with a really good BA that planned out everything for them from end to end.
The devs didn't need to do much thinking, they just wrote and tested to the requirements and was able to create very reusable and scalable code. There were some changes along the way, but it helped that someone already made the effort to plan all the logic flows.
What I hate about college is they only care about the result, and never teach you about other use cases and scalability
Bro beat the youtube algorithm with one video.
Bro LITERALLY copy pasted the script & visuals from a popular video called "How to unfuck your brain" & made it about coding.
@@JreTV-ib3en checking the video, he did copy the style, but the script is different since it is another theme. The selection of stock videos is also different. I guess this style is a recipe for views. I saw worse type of copying on youtube, where the youtube literally copy almost everything, even the title, just changing a word here or there.
here b4 this blows up
Awesome vid man. After a sentence is done, take a tiny break, seems rushed :D Ur gonna be big ✌🏼
Will do! and thanks
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.
❤
this is awesome
lol i was sure its a huge channel, nice vid
Thanks
Thinking about scalability first is a mistake because you will not need it most of the time. Making it work first is much better than worrying about making it fast or scalable later. Especially since programmers have a terrible track record of knowing in advance what will be the bottleneck, so you're better off writing a reasonable version first. If performance becomes a problem, measure to find and fix the bottleneck.
You're describing a software engineer, not a good programer, a good programer actually focuses on how to solve the problem, doesn't care about scaling, a good programer has an understanding of data structures and algorithms, a lot of people confuse software engineering with computer science
This video made me feel like a good programmer.
"use comments" isn't necessary but especially if there's something you just wrote, think about reading this as a different person and thinking "why do I do this exactly?" and then write a comment explaining why so others can understand it easily
regardin the wheel
I know that a team of people focused on developing something (e.g. OAuth) is going to be way better than me. Especially at covering all kinds of security vulnerabilities I can't even think about it.
Make a long course to get started with Competitive Programming and keep making those LeetCode videos please!
I will, I plan on continuing the leetcode
The black box method and/or test driven development are kinda underrated (personal opinion, Junior Fev)