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.
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!
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.
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.
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
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.
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.
If you get to know a language really well and are comfortable using it, it will help you a lot with the general understanding of programming, companies will NOT hire someone who only knows one language, but they will hire someone who has a very good foundation and general understanding of programming. An example could be, that a company uses a language that you haven’t tried before, but you have great understanding of programming, they ask you to create a web application capable of retrieving data from their database, because of your great understanding of programming and the underlying infrastructure that is behind such a web application, you know that you would have to setup a backend with an api that connects securely to the front end of the web app, now you would split this up into smaller challenges that needs to be overcome. These said challenges could be: How do I create a rest api?, How do I retrieve data from the database? How do I display the data on the frontend? And so forth. This way of thinking will benefit a coder so much in terms of progressing and developing yourself and your skills. Most importantly this will make huge projects way easier to create ;)
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
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.
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.
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.
While I fully appreciate the idea behind the "blackbox method" philosophy, a more concrete advice would be to learn the ideas introduced by category theory for programming. The required thinking structure to actually follow the "blackbox method" can be found there.
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 👍
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.
The main thing is just to gain experience so that you can understand the bigger picture. Keep these points in mind while coding, and you'll seem like a genius programmer in months/years once you've understood why these points are important and make your life easier.
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).
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.
I understood he is advocating for test-driven development, not for design-driven development. He talked about one box that is black, not about making boxes. Whcih doesn't come without issues either, but at least it is ok if done right. The video is intentionally vague and pandering. "Goal driven development", he calls it, as in "don't type for fun" or something.
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 had a similar thing or not? I am playing this game where you need to think of your own build or copy it from others, it sometimes took me hours of thinking to finish the build I am thinking about because it's a rpg type of game where armors has unique perk that sometimes work or not to others so I spend hours thinking how to harmonize the perks to works well, I first think of what I am building, for example, it's a healer build, I'll think if it's a full support, semi damage or durable healer and think what would be good to use for that and which armor perks to use that will works well on it, but whether it works or not is based when I done it, sometimes it works well sometimes horrible and I even ask other players for their builds and somewhat improve or change it a little bit to fit my ideas, I don't know if that similar or not but yeah that's all
It's very important not to overuse the black box method. It easily leads to significant overabstraction when applied as dogma. If you are a programmer you are usually not just putting together a bunch of independent puzzle pieces, you are building a system. If you have 3 black boxes that are unlikely to change in the near term and only interact with each other, combine them into one big black box so you can optimize how they interact and get a better solution in the end. Overabstraction leads to confusing code and poor performance.
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.
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.
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 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.
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.
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.
@@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.
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
@@lucaxtshotting2378 nah not really lol oauth 2.0 - authorization spec jwts - crypto signed json, useful for secure server-server communication sso - ability to use a single auth service for multiple disconnected apps login UIs - a login UI doesn't depend on the auth, it can be an SPA, static HTML page, whatever openid connect - authentication spec, pairs well with oauth 2.0 but they aren't necessarily dependent on eachother sessions - an abstract idea of long-lived stateful data cookies - a way to implement sessions in web browsers
def testLists(*lists): # * makes it so that the function can take in infinite number of variables when calling it from another function a = set() for i in lists: for item in i: if item not in a: a.add(item) b = sorted(a) return b
@@fahim1943 lmao, coding in C? Why don't you go fix your memory leaks instead of downplaying other valid programming languages that don't have the same problems as you do?
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.
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.
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!
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.
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
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.
@@JreTV-ib3en lmao not wrong. Copied the form and filled it with the most NPC AI genned content.
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)
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
It's kinda funny that my mentor said the same things to me when I first started my job. NIce video!
the small channels are really built different now a days , very good production quality.
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.
damn, absolutely love this video. These are truly the skills that matter in the end!
here before this video and channel blows up, great content!
Appreciate it!
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 !!!
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.
If you get to know a language really well and are comfortable using it, it will help you a lot with the general understanding of programming, companies will NOT hire someone who only knows one language, but they will hire someone who has a very good foundation and general understanding of programming. An example could be, that a company uses a language that you haven’t tried before, but you have great understanding of programming, they ask you to create a web application capable of retrieving data from their database, because of your great understanding of programming and the underlying infrastructure that is behind such a web application, you know that you would have to setup a backend with an api that connects securely to the front end of the web app, now you would split this up into smaller challenges that needs to be overcome. These said challenges could be: How do I create a rest api?, How do I retrieve data from the database? How do I display the data on the frontend? And so forth. This way of thinking will benefit a coder so much in terms of progressing and developing yourself and your skills. Most importantly this will make huge projects way easier to create ;)
This is so useful! As a highschool student I understood alot from this video! Thanks a lot Mr. Lattice
Glad it was helpful!
Love your style, this should have way more views!
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
Really great video, man! Thanks!
Outstanding video! Can't wait to see more of your content
Great stuff bro, keep going.
Thanks, it means a lot
loved the advice. Will try to implement, Thanks
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.
love the aesthetic, its gonna pull views. I reckon a behind-the-scenes of ur video editing workflow would be popular too.
Really good video.
Reminds me of fireship.
the quality of your video as new a youtuber is amazing!!
Thank you so much!!
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!
I think an extended version of this video with the concepts explained or with good and bad examples would be really itneresting.
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
Thanks for the video, lots of junior that don't really understand what programming is
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.
Your list is kidn of over the place. But yeah, this one doesn't have a face either.
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.
Thanks for this video.
The best video I saw ever about programming. Cheers to more such content from you
Thanks!
Just subscribed dude, you have it in you
keep going
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!
Good advice to help me write better code.Keep up the good work
Ok, you got a new sub. I expect great things of this channel
clean and apt visuals. Loved the vid.
that last point really hit
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
While I fully appreciate the idea behind the "blackbox method" philosophy, a more concrete advice would be to learn the ideas introduced by category theory for programming. The required thinking structure to actually follow the "blackbox method" can be found there.
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
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!
Here before this goes viral
Excellent video!
Love your style and content quality
Yep, you're going to become popular like the likes of BigBoxSWE (I'm new to this field)
Thank you
Nice insights. Really got me thinking.
Watching this actually video made me feel like a good programmer.
Beside the materials you presented whether its true or wrong here, I like how you deliver information for your audience, keep going !
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.
The main thing is just to gain experience so that you can understand the bigger picture. Keep these points in mind while coding, and you'll seem like a genius programmer in months/years once you've understood why these points are important and make your life easier.
307k view witn 6k subs, impressive. good stuff mate
Modern Ideas type video in coding niche, I like it
Thanks, I'm glad you enjoyed!
Great advice!
I needed this video today
Thank you for the helpful content. Keep up the great work! 😃
My pleasure!
great channel. keep it up
wow nice video! now i gotta finish my crud.
Here before you get big!
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).
Omg how do you not 100k already
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.
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
I understood he is advocating for test-driven development, not for design-driven development. He talked about one box that is black, not about making boxes.
Whcih doesn't come without issues either, but at least it is ok if done right.
The video is intentionally vague and pandering. "Goal driven development", he calls it, as in "don't type for fun" or something.
Technically op have a point.
Great video! You earned yourself a sub.
Thanks!
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 😊😊🎉
OMG a programming video edited in the style similar to modern ideas
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 b4 this blows up
good video man
I had a similar thing or not? I am playing this game where you need to think of your own build or copy it from others, it sometimes took me hours of thinking to finish the build I am thinking about because it's a rpg type of game where armors has unique perk that sometimes work or not to others so I spend hours thinking how to harmonize the perks to works well, I first think of what I am building, for example, it's a healer build, I'll think if it's a full support, semi damage or durable healer and think what would be good to use for that and which armor perks to use that will works well on it, but whether it works or not is based when I done it, sometimes it works well sometimes horrible and I even ask other players for their builds and somewhat improve or change it a little bit to fit my ideas, I don't know if that similar or not but yeah that's all
Damn this video is good.
Thanks!
It's very important not to overuse the black box method. It easily leads to significant overabstraction when applied as dogma.
If you are a programmer you are usually not just putting together a bunch of independent puzzle pieces, you are building a system. If you have 3 black boxes that are unlikely to change in the near term and only interact with each other, combine them into one big black box so you can optimize how they interact and get a better solution in the end. Overabstraction leads to confusing code and poor performance.
This video made me feel like a good programmer.
good video, you're gonna make it big 💯
Appreciate it
"...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.
Thank you for the small amount of Flashbanks :)
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.
lol i was sure its a huge channel, nice vid
Thanks
First tip is the bomb 👍
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 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.
wao this is exactly what our ("Informatik" in german) teacher is telling us
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.
this is awesome
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
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 black box method and/or test driven development are kinda underrated (personal opinion, Junior Fev)
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.
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
@@okie9025 am I missing a joke here?
@@lucaxtshotting2378 nah not really lol
oauth 2.0 - authorization spec
jwts - crypto signed json, useful for secure server-server communication
sso - ability to use a single auth service for multiple disconnected apps
login UIs - a login UI doesn't depend on the auth, it can be an SPA, static HTML page, whatever
openid connect - authentication spec, pairs well with oauth 2.0 but they aren't necessarily dependent on eachother
sessions - an abstract idea of long-lived stateful data
cookies - a way to implement sessions in web browsers
def testLists(*lists): # * makes it so that the function can take in infinite number of variables when calling it from another function
a = set()
for i in lists:
for item in i:
if item not in a:
a.add(item)
b = sorted(a)
return b
shmh too much abstraction and built in functions in python, a game for boys
Real Men program in C obviously
And the best men in raw x86
@@fahim1943 lmao, coding in C? Why don't you go fix your memory leaks instead of downplaying other valid programming languages that don't have the same problems as you do?
@@fahim1943bro if this code is abstract for you then you're cooked
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.