DISCLAIMER: THIS VIDEO IS FOR A GENERAL AUDIENCE AND WILL NOT GET YOU EMPLOYED(sadly). Programming is subjective, and I'm sure I put some incorrect things in this video, so take what I say with a grain of salt. These are all just my opinions as a content creator/programmer. At the end of the day, a UA-cam video can not make you a professional programmer. but I hope it helps even one person who's beginning to learn to program/code. Also be sure to check out my inspirations for this video in the description, such as ModernIdeas and Fireship. Also, watching this back, I made the music way too loud. Sorry if it's hard to hear! Lastly, I appreciate each and every one of you for your feedback, even the negatives, as I want to give the best advice and video possible. Thank you all!
It's a very good video and well thought. If people complain, it's because they can't handle reality. I was exactly reflecting on the black box concept in these days.
@@p19shelt I agree. The video was well made and had good general advice for a programmer. The comment about bootcamp/clean code was just a dig with some truth in it, but it doesn't mean it was a bad video. The creator's self doubt in his comments makes newer developers unsure if they should trust his advice. Just ask for fair criticism and choose which ones to improve on the next video.
@@p19shelt I understand my advice is general because it's made for a broad audience, as most videos are. I believe in myself 100%, which is why I don't delete any negative comments and instead I try and learn from them. I'm pretty open minded and I understand people have different views on what makes a good programmer. So when I reply to comments like these, it's not self doubt, it's just me learning your opinion and explaining mine. but ultimately if you were looking for non-general advice on programming, you shouldn't be looking on UA-cam. At the end of the day this is just a UA-cam video, not a course.
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!
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).
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.
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.
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 👍
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.
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.
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?
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.
Nice video, has great guidelines for begginers Just the comments that can be taken in a bad way Comments may lie but the code may not. Mainly write comments for things that need to be explained beyond the code. When you rush for a quickfix because production is breaking somehow, you will have to update de code and then the comment about what the code do else the comment will lie. My general rule is, if the code has comments to be understood then it's bad or really has a good reason to be that way And having bad familiarity with the code doesn't imply the need for comments. Everybody has it and the comments saying the same thing as the code won't help. You will read the code anyway Sorry for my bad english and the long comment.
Hi Lattice, I discovered your UA-cam channel a few days ago, and I've to say I'm at first was watching a huge UA-cam creator and not a small channels because of the highquality content, and their lore is awesome. So, a HUGE thank you! After a little research (sorry, not sorry), I realized that you're not fully leveraging your Twitter, UA-cam, and personal website. With your passion, expertise, and engaging content, I believe you could build authority via these organic channels, grow your audience more, and possibly become a successful creator by the end of the year. As a ghostwriter and senior full-stack developer, I can help you repurpose the content you already have on your UA-cam channel to create engaging titles, descriptions, short and long-format posts on Twitter, threads, blogs, and much more! I would like to share my portfolio with some examples of how I would approach this and would love to know your thoughts.
I hated the "new image every millisecond" presentation. It sounded like you had some worthy knowledge to share, but I just... I just can't be hammered by these slides. Wish I had discovered this via some kind of audio format.
the coder != programmer thesis is unnecessary tbh. Agree with the video with exception of the first argument as sometimes having something up and running helps getting the first picture more than thinking and thinking about it. Refactoring is most of the time easier.
Please don’t think about abstraction before you get the first one or two prototypes out. Writing a bunch of code just for the sake of architecture may cause you a lot of pain
Duude, all the things you've mentionted are litterly THE OPPOSITE of what a good programmer do! (except if you consider a "good programmer" a half-baked "senior developer" from a web company, who have written less code in his entire life than an average gamedev or low-level programmer do in a week) 1. You should NEVER EVER treat your system as a "black-box", a good programmer has deep understanding of everything his code does, no exceptions. 2. The second point about collaboration sounds fine, but in practice, 90% of "clean code practices" you'll find in internet and in web companies is trash. 3. A good programmer doesn't rely on a large list of third-party modules, he prefers to write everything by hand, because he knows this is the only way to achieve simplicity needed to create a robust system.
Great presentation but bad advices. If you want to become a programmer you need to know how to define the problem before hitting that keyboard. Many programmers end up quitting because they didn't know what the hell they are doing.
That's what I was trying to explain with the black box method. I was trying to insinuate that you should clearly understand what your code should do(such as the inputs and outputs), and then break it down into smaller components. But I understand and appreciate your feedback. I'll take it into account for my next one, appreciate you!
lmao im getting of this thing on second 0:48 I think this is legit the first video around code practices that I chose to actively ignore. Not saying you are wrong or that its a bad video, I am sure you are far more experienced than I am but the first advice is horrible imo, good luck!
@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.
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.
![[UA] Eternal Fire проти NAVI | EPL Season 20 Malta](http://i.ytimg.com/vi/chvlsDygrZM/mqdefault.jpg)
DISCLAIMER: THIS VIDEO IS FOR A GENERAL AUDIENCE AND WILL NOT GET YOU EMPLOYED(sadly). Programming is subjective, and I'm sure I put some incorrect things in this video, so take what I say with a grain of salt. These are all just my opinions as a content creator/programmer. At the end of the day, a UA-cam video can not make you a professional programmer. but I hope it helps even one person who's beginning to learn to program/code. Also be sure to check out my inspirations for this video in the description, such as ModernIdeas and Fireship. Also, watching this back, I made the music way too loud. Sorry if it's hard to hear! Lastly, I appreciate each and every one of you for your feedback, even the negatives, as I want to give the best advice and video possible. Thank you all!
It's amazing video. And with certain abstractions in mind it can be applied to ANY field of work.
Great job!
Delete this. Ur advice applies to any video and ur comments show u don't believe in urself.
It's a very good video and well thought. If people complain, it's because they can't handle reality. I was exactly reflecting on the black box concept in these days.
@@p19shelt I agree. The video was well made and had good general advice for a programmer. The comment about bootcamp/clean code was just a dig with some truth in it, but it doesn't mean it was a bad video. The creator's self doubt in his comments makes newer developers unsure if they should trust his advice. Just ask for fair criticism and choose which ones to improve on the next video.
@@p19shelt I understand my advice is general because it's made for a broad audience, as most videos are. I believe in myself 100%, which is why I don't delete any negative comments and instead I try and learn from them. I'm pretty open minded and I understand people have different views on what makes a good programmer. So when I reply to comments like these, it's not self doubt, it's just me learning your opinion and explaining mine. but ultimately if you were looking for non-general advice on programming, you shouldn't be looking on UA-cam. At the end of the day this is just a UA-cam video, not a course.
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!!
the small channels are really built different now a days , very good production quality.
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!
Wish this sort of design thinking was taught in school… even a 1 credit seminar course would be really useful for newcomers.
No one tells you why the box is black. It’s because it works faster
💀
now this is a x10 developer
Amazing video, completely agree with the black box and using existing frameworks points
Here before this goes viral
This is how we were taught when I was in school in the late 80's.
skill issue
Yep, you're going to become popular like the likes of BigBoxSWE (I'm new to this field)
Thank you
Programmer = Coder. The upgrade of that is an Engineer
Yes, agreed 1000%. Thank you for calling this out
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'!
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).
that last point really hit
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
I think an extended version of this video with the concepts explained or with good and bad examples would be really itneresting.
love the aesthetic, its gonna pull views. I reckon a behind-the-scenes of ur video editing workflow would be popular too.
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.
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.
Thanks for the video, lots of junior that don't really understand what programming is
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.
the quality of your video as new a youtuber is amazing!!
Thank you so much!!
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!
Loved this... I often get stuck because I overthink all of the ways to do it
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.
Omg how do you not 100k already
Beside the materials you presented whether its true or wrong here, I like how you deliver information for your audience, keep going !
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.
here before this video and channel blows up, great content!
Appreciate it!
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
Modern Ideas type video in coding niche, I like it
Thanks, I'm glad you enjoyed!
The best video I saw ever about programming. Cheers to more such content from you
Thanks!
Outstanding video! Can't wait to see more of your content
Good advice to help me write better code.Keep up the good work
"...create test cases" I definitely have a long way to go then as I've never written a test in my life
Awesome vid man. After a sentence is done, take a tiny break, seems rushed :D Ur gonna be big ✌🏼
Will do! and thanks
lol i was sure its a huge channel, nice vid
Thanks
Here before you get big!
i still dont belive that its just a 6 min video
feels like my world has changed
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.
here b4 this blows up
Love your style and content quality
Great advice!
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
Nice video, has great guidelines for begginers
Just the comments that can be taken in a bad way
Comments may lie but the code may not.
Mainly write comments for things that need to be explained beyond the code.
When you rush for a quickfix because production is breaking somehow, you will have to update de code and then the comment about what the code do else the comment will lie.
My general rule is, if the code has comments to be understood then it's bad or really has a good reason to be that way
And having bad familiarity with the code doesn't imply the need for comments. Everybody has it and the comments saying the same thing as the code won't help. You will read the code anyway
Sorry for my bad english and the long comment.
Hi Lattice,
I discovered your UA-cam channel a few days ago, and I've to say I'm at first was watching a huge UA-cam creator and not a small channels because of the highquality content, and their lore is awesome. So, a HUGE thank you!
After a little research (sorry, not sorry), I realized that you're not fully leveraging your Twitter, UA-cam, and personal website. With your passion, expertise, and engaging content, I believe you could build authority via these organic channels, grow your audience more, and possibly become a successful creator by the end of the year.
As a ghostwriter and senior full-stack developer, I can help you repurpose the content you already have on your UA-cam channel to create engaging titles, descriptions, short and long-format posts on Twitter, threads, blogs, and much more! I would like to share my portfolio with some examples of how I would approach this and would love to know your thoughts.
I hated the "new image every millisecond" presentation.
It sounded like you had some worthy knowledge to share, but I just... I just can't be hammered by these slides.
Wish I had discovered this via some kind of audio format.
First tip is the bomb 👍
I'm half way there :)
Nice insights. Really got me thinking.
good video man
Thank you for the helpful content. Keep up the great work! 😃
My pleasure!
wow nice video! now i gotta finish my crud.
Great video! You earned yourself a sub.
Thanks!
you sound like frankie from meditations for anxious mind
the coder != programmer thesis is unnecessary tbh. Agree with the video with exception of the first argument as sometimes having something up and running helps getting the first picture more than thinking and thinking about it. Refactoring is most of the time easier.
listening this make me feel that I will just be a average worker lol.
I was here before this starts to blow up
Thanks, it means a lot!
Please don’t think about abstraction before you get the first one or two prototypes out.
Writing a bunch of code just for the sake of architecture may cause you a lot of pain
Finally some true and original advice. In between the gazillion tutorials that make you a coder, you speak of very valuable skills. Thank you
Glad it was helpful!
Boss: *storms in* "DID YOU DELETE THE FUCKING DATABASE!?"
Programmer: "Ah see, it's fine. It's just feedback so I can le.."
Boss: "YOU'RE FIRED!"
Muito bom o seu vídeo, sucesso!
muito obrigado!
I think you misnamed it, it's called Clean Code and Test Driven Development
good thing i already think like this, but I am not a programmer in the traditional sense.
Black box is more about encapsulation and modularisation?
I'm inspired.
bro when did maximise start a coding channel? D:
Thank you
Big sicp vibes
Commenting this when you have a break
I appreciate it!
I don’t get the comments praising or criticism?
How do you only have 200 subs
Period. 💅
ayo sup with the subscriber count? it's missing a K at the end.
one day lol
More videos pls 😊
bro this some quality shit!!!
Appreciate it
this will go viral
Appreciate it!
This concept of editing is similar to modern ideas (a yt channel)
I took a lot of inspiration from him and @this.science
But does the list get joined or not?
Step one: Be a genius.
idky but became more and more confused at the end of the video....can anyone please jot down everything from the video and make it easy to understand?
nice video
thanks!
thanks
did somebody say chatgpt?
wait this is similar to cs50
bro i think you read too any books before actually starting programming
don''t use JWT btw, it's vulnerable af
then?
@@kishankumar2272 just use any other thing than JWT.
JWT is not only footgun, but it RELIES ON THE CLIENT-SENT HEADER FOR THE ENCRYPTION METHOD
Duude, all the things you've mentionted are litterly THE OPPOSITE of what a good programmer do! (except if you consider a "good programmer" a half-baked "senior developer" from a web company, who have written less code in his entire life than an average gamedev or low-level programmer do in a week)
1. You should NEVER EVER treat your system as a "black-box", a good programmer has deep understanding of everything his code does, no exceptions.
2. The second point about collaboration sounds fine, but in practice, 90% of "clean code practices" you'll find in internet and in web companies is trash.
3. A good programmer doesn't rely on a large list of third-party modules, he prefers to write everything by hand, because he knows this is the only way to achieve simplicity needed to create a robust system.
Great presentation but bad advices. If you want to become a programmer you need to know how to define the problem before hitting that keyboard. Many programmers end up quitting because they didn't know what the hell they are doing.
That's what I was trying to explain with the black box method. I was trying to insinuate that you should clearly understand what your code should do(such as the inputs and outputs), and then break it down into smaller components. But I understand and appreciate your feedback. I'll take it into account for my next one, appreciate you!
Rush to keyboard = guaranteed shit code.
this makes you not good enought
I hate this format
👎
lmao im getting of this thing on second 0:48 I think this is legit the first video around code practices that I chose to actively ignore. Not saying you are wrong or that its a bad video, I am sure you are far more experienced than I am but the first advice is horrible imo, good luck!
thank GOD, im not a GENIUS Programmer
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.
for example, Regev Algorithm(2023) is an improvement over Shor Algorithm(1994)
@21stchill18 In which case a new algorithm was invented. That's not what their professors quote was about.
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)