어려운 방식으로 프로그래밍을 배우는 것의 이점

### 어려운 방식으로 프로그래밍을 배우는 것의 가치
* 💻 1년 전, 제 유튜브 동영상에 달린 댓글에 **왜 상용 게임 엔진을 사용하지 않고 처음부터 게임 엔진을 만드는지 의문**을 제기하며 게임을 완성하는 데 시간이 오래 걸릴 것이라고 제안하는 사람이 있었습니다.
* 🤔 제 초기 진행 상황을 고려할 때 그 의견은 타당해 보였지만, **프로그래밍에서 더 어려운 길을 택하지 않는 일반적인 사고방식**을 강조한 것이었습니다.
* 🎮 단순히 게임을 빠르게 출시하는 것이 목표라면 **Unity나 Unreal과 같은 기존 엔진**을 사용하는 것이 가장 빠른 방법일 수 있지만, 게임 개발에 대해 깊이 있게 배우고자 한다면 **자체 엔진을 구축**하는 것이 매우 유용할 수 있습니다.
* 📈 복잡한 문제를 해결하는 과정은 불완전한 프로젝트로 이어지더라도 **완성에만 집중하기보다 학습에 집중하는 사고방식**을 길러줍니다.
* 💪 도전적인 프로그래밍 작업에 참여하면 **자신감이 생길 뿐만 아니라 해당 분야의 지식이 풍부한 권위자**로 자리매김하여 **고용 가능성과 잠재적 수입**을 높일 수 있습니다.
* 🚀 저급 프로그래밍을 통해 저는 **경력 전망을 높이고 야심 찬 프로젝트를 더 쉽게 추진할 수 있는 기술**을 갖추게 되었습니다.
* 🔍 궁극적으로 어려운 방식으로 프로그래밍하는 것은 당장의 금전적 이익보다는 **장기적인 성장과 자신감**에 관한 것이며, 이는 미래에 **더 깊고 보람 있는 일**을 할 수 있도록 준비하기 위한 것입니다.
* 💡 "힘든 일을 하면 정신이 단련된다"는 말이 있듯이, **회복탄력성과 기술로 미래의 도전에 대처할 준비**가 되어 있어야 합니다.

열심히 프로그래밍하면 자신감과 기술이 쌓여 궁극적으로 더 큰 커리어 성공과 기회로 이어질 수 있습니다.

Why should we learn programming the hard way? I want to know about a year ago I received a mildly discouraging comment on one of my YouTube videos. At the time I had been working on my indie game and game engine for about a year. I made some

progress, but it wasn't totally obvious how far along I had come. "That's a really cool game. That was a really cool game right there. I really, I, I love this. This is a really great little... Yeah, it's a, it's a slick little puzzle. No, it's not Portal.

It's a puzzle solving you. It looks like you can push things all the way to the edge. You can push things around, uh, and then you are able to push stuff out. So when you hit this little laser, it redirected it right here, so you can get

to right here. My guess is then you can put the cube here, here, and you can like step your way down and get out to here. Anyways, so the guy writing the comments seemed justified in what he was saying, at least in some way. Here's what he said:

"What's wrong with just using a commercial game engine? I have a feeling you will have great, great grandchildren before a game is ever done with this." Now, I don't mean to bag on him. I actually think he's coming from a fairly commonplace... Most of us aren't encouraged to

take the harder path, and so it's pretty normal for many to assume something is too difficult before ever trying it. And in fact, at that time my game really didn't look like much of anything. It was just kind of a white square sort of bouncing around. I actually do want to

talk for a quick second about what he just said there which is I hear this all the time you know why wouldn't you just you know you you can we can relate this easily to something with webdev right why don't you just use React plus

whatever right whatever the soup du jour is of all these things why would you ever do anything else why are you ruining your life by learning anything else just use React it's the industry standard right um you could say the same thing right Unity if you why would you use

anything but Unreal or Unity why would you use Godot why would you use anything else why would you build your own if you built your own you're just wasting your life are you really wasting your life I don't think you are the reason why I say

that is that what is the purpose of what you're doing if you care about simply and only building a game to get it released on mobile your fastest path probably is just use an effing engine right don't dick around just use an engine but if your goal is to learn how

things work maybe using an engine isn't the best idea maybe it makes no sense to do that maybe you just simply want to learn how to render stuff and move stuff around and just learn everything from the very bottom and do your own research and see how far you can get

even if you never finish anything that's still okay I know people just make these weird hardline stances I think the problem is is that some there's a group of people that think the the only good result is the completed project whereas I don't look

at a completed project as the goal. The goal is to learn what I'm trying to learn. If I want to learn how say, uh, Kubernetes works, I don't need to complete some gigantic project to learn it. Maybe I just want to learn the Kubernetes part, and I make four

small little, you know, programs, and just I'm playing around with that, and it never goes anywhere, but I learned the thing I didn't learn. I didn't complete some gigantic project, and I think sometimes people forget those small little, you know, those small little bits, which is no like, set your goals before

you begin, and accomplish your goals. It doesn't have to mean a completed project.  If you were looking at it, you wouldn't have thought much of it. That was a cool, all you ever did was pay attention to mainstream programming articles and top page Google results. I

think you would be pushed into a similar mindset. Basically, anything that is mainstream in the programming world, you're presented by the way. This is a, this I love this is such a great idea for a video game that we're seeing here. This is super cool. It is a very cool

game. It's like a Portal-esque type game with dangers on the other side. Very cool. I love Portal-esque type games with a view, which highly emphasizes being convenient and using tools, and I feel like the opposite happened to me. I started with an engine

to get the feel of game dev as I started diving into more complex ideas. I started building plugins to do the same, the things the game engine couldn't do. That has now led me down the path of building my engine. Yeah, there's no one route. That's the thing is that I don't

think there's a singular route like if your only goal is to simply build a game you can do your own engine you can also not you can also not right like you just have to know and you have to come in with the expectations of what's the what

is the what is going to be the likely outcome if you're building completely from scratch and your own things guarantees you the likelihood of finishing goes way down the likelihood of learning goes way up and not reinventing the wheel as much as you

possibly could and this is the dominant mindset but I actually want to argue that this easy way of doing things this um always use someone else's tool mindset is actually to your own detriment and that doing the opposite of that is probably the best thing for your

career and I mean that not only in terms of the financial success that you will get which you will you will actually get more money if you do things the hard way I love this advice currently this advice is amazing but I'm not going to lie to

you this video game looks nuts okay he's literally playing two sets of pieces at the same time I'm getting distracted by the puzzle you know what I mean this is it's it's like this this game is super cool looking right you got you got like

I mean it's mixing like Mar you know like Mario Galaxy with all with all the different up and downs or was that Mario was that Mario Galaxy or Mario Odyssey with the up and downs on it all the different Mario Marios had a lot of them

and then also this Portales type thing, ah there's so many cool little things I do love this advice. This advice though, see the okay, so this advice will waste your time. Why does it waste your time? See, this is this Pro, I think this is

that that mentality that you're getting in your head which is the only way to do something is to be able to complete and build projects like another YouTube clone using React or Vue or whatever right? And that's the only thing you should be concerned about. I would

completely argue the opposite. There is no such thing as a as wasted time. If you make your goal on the outside, I spent two years building a startup that ultimately went bankrupt and I lost all my money. Two years SP building out PHP, this was 12, 13 years ago. Two years

spending 80 hours every single week working as hard as I could. What did I get out of that? Well, I went into every single interview and was one of the most qualified people to be in those interviews. I was able to consistently and constantly able to get into uh

what's it called? Every interview and be able to talk about things that they're like, oh wow, you know way more than just front end. I was able to be that full stack kind of engineer because I had all this experience before full stack was even a term we used. I was a full stack

person and I failed completely, but it got me all the way to Netflix. I don't know, but you will also be able to pursue uh more interesting creative projects and ideas that you wouldn't otherwise be able to pursue. So in the course of this talk, I just simply want to argue you

what this mindset is and I want to actually show you what you can gain by learning how to do software the hard way. After listening to this, I believe you will have a totally different outlook and you will welcome new challenges in programming that will help you grow and

advance your career. And it really doesn't matter if you're just starting out or have been in software for a long time and would consider yourself a senior engineer. I have benefited tremendously from the time I have spent in lower level programming. Not only do I

view software engineering problems from a completely different perspective, my investment in acquiring these difficult to attain skills has led to me getting paid more, which has ultimately put me in a position where I can consider pursuing independent game development full-time. I'll show you how you can

build your skills in this way and fully pursue whichever path and software most interests you. So why are we... I do like that. I like, I like this thesis. I like, I, I like this. Oh, what was the answer? Hold on. Uh, GitHub, because you won't get practical, uh

profit unless you actually finish that game and release it. You won't get a job as a Unity or Unreal Dev with your own engine if the next guy, let's see, the next guy to you knows those engines better. Well, here's the problem with that statement. Okay, I understand what you're

saying. You're saying, 'Hey, you don't get to make money unless if you finish a project.' You don't get to have, you're, you're also saying you don't get to have, uh, what's it called? That engine job unless if there's a guy better than

You couple quick things there I think you're completely wrong, not just kind of wrong, I think you're objectively right if you only consider the most shallow case and I think you're completely wrong otherwise. Let me give you a reason why, just simple looking at it you're

absolutely right, if you don't release the game you don't make any money, but what if the point was to learn how to make games and understand the insides? You work at a job where you're doing simple game dev stuff and you're helping

people, so on the S or you're at a company and you're just, you're like an, you know, low-level game, whatever you are, I don't know what, I don't know what the game industry low-level term is called, Junior engineer of game building, uh, and

so you take all of your time and you learn all these fundamental concepts, what's going to happen? Well, it's very, very simple, when you talk to people at work they're not going to look at you nearly as Junior because you're going to start talking about these difficult

concepts. You'll show people something you've built and they're like, wow, you built every last part of that, how'd you solve this thing, how'd you do this? And now you can start talking about it in a really technical aspect and what's going

to happen at your job, sure you never released a game, you made zero dollars on your game, you are now talking in such a way that people actually consider you an authority in this case and guess what, guess who's getting more money at their job, guess who's getting more

responsibility at their job. Guess who's getting more trust and seniority at their job, all because you didn't complete a game? Totally worth it, totally worth it. And just because somebody knows game engines better than you, it's not a zero-sum game. There's not

one game engineer or one game engine dev. There's thousands, tens of thousands of them all building and doing something. So what do you do? You just need to become good enough. How do you become good enough? You have to keep on trying to make yourself better. Let's see, don't reinvent the

wheel. But but then why do I have uh 40,000 npm dependencies? Uh oh my goodness. Nice, nice sentence, TJ. It's not my fault. But yes, I see what you're saying. Don't reinvent the wheel, but also do you really want to use all

of node's packages just to get a just to do an HTTP request? Probably not. There's simple ways to do this. Um anyways, it's just something to think about, which is the goal isn't always to complete. The goal isn't to directly make money off the thing.

There are other ways that you get stuff out of something, right? It's not this this idea that that that the result is black and white. Finish, make money. Don't finish, lose money, and it's bad. No, there's a middle ground. I lost all my money, all of

it making my startup. I got a job at Netflix out of it. Was it bad? No, right? Failure is growth in some sense. Yes, I mean there's failure that's just failure, you know, realistically. There's failure that's failure, and then there's failure that's

Really great, inventing the wheel. What's wrong with software in the way that it's currently built? This is the first objection you will hear whenever you tell someone you were writing a game engine from scratch. If you're doing any kind of generic tool, like a compiler, 

anything that is perceived to be a bigger, ambitious project, this is usually the first thing you will hear. Indeed, this is the "just don't write your compiler in JavaScript, please! For the love of all things good and great and holy, stop writing tools in JavaScript." question that was asked of me. 

Why do this? Couldn't you save time by using an existing framework? And in many ways, it's difficult to argue with a statement like this because it's true. You will usually save time in the short term by using an existing tool or framework. That said, I think an argument 

like this falls flat in a few ways, and I think it's because it presupposes that you have the same goals as the person asking the question. I want to frame this question in a slightly different way. Imagine asking a professional MMA fighter a similar question: Why do this? Why do you think 

training to punch others with your bare hands is better than firing a rifle or having a drone carry out a strike? Why lift weights when you can use your car to haul things around town? Why ride your mountain bike when you can drive anywhere you want to go? Why hold on just 

one second. Hold on just one second. Okay, we're back again. Sorry, small interruption. Let's go: cook your own kns when you can just order takeout. All of these save time and accomplish what is assumed to be the goal, and that's what I 

I want to get at what is this assumed goal, which is buried inside of the question? I believe the question assumes your goal is to get something to market as quickly as possible, to spend the least possible amount of time making your game product, under certain circumstances. This goal

can make a lot of sense if you are employed by someone else and they're paying you to get something rough out on the market as soon as you possibly can. Saving time is your number one priority. You really don't have much, uh, leverage or, or, or flexibility there. But people

don't lift weights, go mountain biking, or train in martial arts because they're just trying to save time. People do these things because they are valuable in and of themselves, and because people enjoy pushing their own limits. People challenge themselves because they like to get smarter, faster, and stronger. If

your only goal in software is to make money, I think you'll end up feeling pretty hollow after a while. You'll eventually, I do agree with this statement, I do completely agree with the statement is that if you only have a singular goal, it is very like a singular

goal of just making money, even though there is definitely a, uh, there is definitely completely, completely reasonable goal of making money, right? But there's also a, you know, if the only goal is that, it can be, you know, it can be extremely unfulfilling. It can be extremely

unfulfilling. A small, obviously everybody wants, you know, everybody wants a good life, everyone wants to be able to make money, but you know, there comes a point where making more money doesn't make as big of a difference in your life. And if your, if your hope and your

goal is like oh once I just get to this level I can finally be happy and then you get to that level and then you're like oh maybe it's actually this level that finally makes me happy you will you're going to soon very soon enter

into the worst place in the world which is the cul-de-sac of stupidity right like we all we've all been in the cul-de-sac of stupidity from time to time right uh the cul-de-sac of being of course where you think that the thing that's going to

make you happy and you finally achieve it and you're not happy so your your thought is well I just simply need more of that thing and then I'll be happy that's the cul-de-sac of stupidity right once you hit there you're like dang

it I'm not happy maybe more will make it happy you know what I mean and it's just not more money mo problems uh but I mean at the end of the day there's people that aren't making any money and making money is most certainly a good first

step into just achieving some general goodness right um let's say you feel you feel nothing when you install that TV and you know it is it no expectations no disappointment you should have some expectations in life come on arrive at a place where you don't

feel like you are challenging yourself properly like there's no forward momentum in your life even though you're making gobs of money challenge makes life interesting and worthwhile we thrive when we go past our limits and learn new things doing things the hard

way makes you realize what's possible for you it opens up new horizons after challenging myself with the prospect of building a game engine I'm surprisingly not against using libraries or third-party code the only thing that has changed is the way I view using

those libraries I have a better idea of what I am looking for in a library and I know which sorts of libraries will make me less productive it's valuable to program the hard way because it's the only way you can truly learn and grow it's supposed to take lots of time

because that's how learning feels you aren't doing it for a quick win in the present you're doing it to become a more skillful person for the long run of your entire career I feel like that's kind of you know that's the similar

piece of advice that I give when it comes to if you want to be in a different position than you are in now you train for the position where you want to be in you don't train for the position that you're currently in so if you are a React engineer as some people

call themselves they say the stupidest phrase in the universe I learned React before I learned JavaScript um if you're that person now and you want to be somewhere else train for that position somewhere else do your day job in whatever you do your day job in and train for where you want

to be not where you're at many times have you felt totally stuck in some programming problem you're trying to solve often times the character of building an app or a game is such that you go through one big obstacle after another when you're stuck in the thick

of solving a difficult programming problem, it can oftentimes feel like everything hinges on your ability to get past it. Indeed, this has happened throughout the development of my own game. I got stuck figuring out how to use the GPU to draw colored squares onto the screen. This week I got stuck working on

an audio mixer based on a 2-second circular audio buffer on the Mac platform. When you're stuck, it seems like everything is going to take so much more time than it really does, but once you're past the obstacle, it's surprising how quickly the various remaining pieces

snap together. This certainly happened to me recently. I hired an artist to do an aesthetic overhaul of my game's world, and boy oh boy did he deliver! He gave me this huge 200-tile spreadsheet, and I had to somehow incorporate all of this

new art into my game. Interestingly, the hardest part of all of it was writing an algorithm to load the PNG file and to sample into the various tile and player character textures. Once I wrote that code, the rest was smooth sailing, and I had new graphics in the game after about

2 weeks of work. The hard way is only hard at the very outset. Once you get past those initial obstacles, you will be surprised with how productive you can become. Because I know my game engine inside and out, it was very easy to integrate the new graphics into it once

I had them loaded into memory. I didn't have to fight with that. That is fair, that is fair. Even, even if you're, even if what you build is less complete than anything else, the full knowledge of its insides and outsides does give you some sort of

competitive advantage that is different than simply just having some understanding of just like little bits of the outside. I'm not saying it's always better, I'm not saying it's the way to go, I'm not saying that it scales right, it certainly does not scale

because then when you hire somebody they have to learn your version of the thing, right? And so it's not always the best way to go, but there is definitely something to that that is very true. Luckily, the game by the way in the background keeps repeating itself so

I've lo I I no longer feel uh I I can now listen to him much much better. I can't wait for the prime gen to write about 25% of the game engine on stream. Oh dude, it's going to be the best 25%

you've ever seen with any third party libraries with closed source code. I can't read. Often times in life you will struggle early on in order to reap rewards later. That is the philosophy of programming the hard way: struggle now so you can build the skills necessary to do

great work and become even more productive later on. So at this point you're probably following along and thinking, okay Ted, that's great and all, but I don't ever get any time to do any of this sort of stuff in my job. Why would this be valuable to me in a career

where we never touch any of this lower level stuff? Yes, and I have one word for you, please. That word is confidence. An uncanny thing happens when you come back for air after tangling with a sea monster or any difficult problem: you become more confident in your own

Abilities, things which used to seem scary to you, no longer do, and this is reflected in so many aspects of the way you carry yourself in the world. I'll draw an analogy from snowboarding, one of my favorite pursuits. Before I got into snowboarding, I didn't quite carry myself

with the same degree of confidence. It's kind of difficult to describe, but it's like I was less physical in some way. I wouldn't have been willing to engage in a fight, or even know what to do if I got into a situation like that. Now I'm not

saying I want to get into a fight, or in any way interested in that, but before snowboarding, I didn't have a way to understand how I might interact in a seriously dangerous situation. And then for several years, I did nothing but snowboarding, and I intentionally put

myself into some pretty hairy situations. I've crashed on all parts of my body, sustained some minor concussions, witnessed my blood filling with adrenaline, and my heart racing. I faced my fears and walked away from it. I've done a few noteworthy things, but mostly

had a good time and made some lifelong friends. I can say without hesitation that snowboarding has made me a more confident person. It changed me in a deep and irreversible way. Because of snowboarding, I'm more situationally aware. I have a sharper sense of how

things work physically. I carry myself differently. I have experienced a similar thing with lower-level programming. After wrestling with writing a custom audio mixer, I can more confidently speak about audio in apps and games. This confidence immediately comes across when I'm

talking to other people pre-at clearly pre-at that's what I'm talking about right like that's literally what I'm talking about is by doing your own thing when you talk to other people it makes an incredible difference difference right cuz you're

just able to talk about things that only people who have done it there's like this special ring that you got to get a step into and you'll you'll notice that when you do this is that as you do these things on your own and you're talking to

somebody else who's also done it you get this the Inner Circle effect you're like oh you're a part of the inner circle come on in let's talk about this thing we're doing right and all of a sudden people are bouncing ideas off of you you

want to guess who's getting that next position when it opens up on the team the person that they talk to with problems and all that or some new person off the street guarantee it won't be you if they never talk to you guarantee it will be you if you're always talking to

them if you're always able to be a part of stuff it's like so simple to do how do you think I'm on the team I'm on pre-at often times it's like I'm having a totally different conversation about the topic because I now view it from a

deeper level you can't fake confidence like this the only way to get it is to wrestle some sea monsters and there's another one wonderful thing about I love being a seaan doing some sea monster wrestling it is a predictor of long-term

financial success. If you are confident in the way you speak about your domain of expertise, people will want to hire you. They will pay you more because they know you've got a greater chance of getting them to where they want to go. I have no doubt that my experience in

lower-level game engine programming is a reason I was able to keep one of my more lucrative software contracting gigs longer than many of the other people on that team, even though it didn't seem like it at the time. Wrestling that beast

has made me more wealthy by making me more confident in my abilities. Confident people make more money. Tackling hard problems makes you more confident. Therefore, programming the hard way makes you rich, even if it doesn't seem like it at first. So okay, I can't make that last

guarantee like I totally, I, I, I get where he's going with that situation, but I cannot make that last statement 100% true. Uh, but hey, TJ, TJ, you started out in college contributing to NeoVim not knowing what to do. You didn't even know

Why You Should Learn To Program the HARD WAY

This is a place for all the things that are awesome on stream. 

ThePrimeTime

발표자는 인디 게임 개발에 대해 실망스러운 의견을 받았습니다.

댓글 작성자는 처음부터 게임 엔진을 개발하는 대신 상용 게임 엔진을 사용할 것을 제안했습니다.

당시 스피커의 게임은 흰색 사각형이 이리저리 튕기는 단순해 보였습니다.

발표자는 이를 웹 개발과 연관시켜 사람들이 왜 React와 같은 기존 프레임워크를 사용하지 않는지 의문을 제기합니다.

발표자는 게임을 빠르게 출시하는 것이 목표라면 기존 엔진을 사용하는 것이 가장 빠른 길이라고 주장합니다.

연사는 단순히 프로젝트를 완료하는 것이 아니라 어떻게 작동하는지 배우는 것을 주요 목표로 삼을 것을 강조합니다.

연사는 완성된 프로젝트에 초점을 맞추는 것과 특정 기술을 배우는 것의 중요성을 대조합니다.

연사는 대규모 프로젝트가 아닌 소규모 프로그램을 통해 Kubernetes를 학습하는 예를 사용합니다.

처음부터 만들면 완성할 가능성은 낮아지지만 학습할 가능성은 높아집니다.

연사는 항상 다른 사람의 도구를 사용하는 것은 장기적으로 해롭다고 주장합니다.

발표자는 실패한 스타트업 구축 경험을 예로 들며 시간 낭비라는 생각을 반박합니다.

스타트업의 실패에도 불구하고 연사는 귀중한 풀스택 경험을 쌓아 넷플릭스에 입사하게 되었습니다.

이 연사는 경력 발전을 위한 소프트웨어 학습의 이점을 보여주기 위해 노력합니다.

이 연사는 초보자와 숙련된 엔지니어 모두를 위한 이점을 강조합니다.

발표자는 열심히 노력한 결과 임금 상승에 대해 언급합니다.

연사는 게임을 완성하고 출시하지 않으면 수익이 나지 않는다는 주장에 대해 설명합니다.

연사는 수익이 아니라 학습이 목표일 수 있다고 반박합니다.

기본 개념을 익히면 프로젝트가 출시되지 않더라도 더 가치 있는 직원이 될 수 있습니다.

연사는 제로섬 게임이 아니며 많은 게임 개발자가 참여할 수 있는 여지가 있다고 강조합니다.

연사는 항상 프로젝트를 완료하거나 직접 돈을 버는 것이 목표가 아니라는 점을 강조합니다.

바퀴의 재창조와 MMA 파이터 비유

연사는 처음부터 도구를 구축하는 것에 대한 일반적인 반대에 대해 설명합니다.

발표자는 이 이의 제기가 모든 사람에게 동일한 목표를 전제로 한다는 점을 지적합니다.

연사는 종합격투기 선수와 다른 활동의 비유를 통해 자기 계발의 가치를 설명합니다.

발표자는 무언가를 빠르게 시장에 출시하는 것이 목표라는 기본 가정을 확인합니다.

연사는 자기계발과 한계에 도전하는 것은 그 자체로 가치가 있다고 주장합니다.

연사는 어려운 방법으로 기술을 구축하면 라이브러리와 도구에 대해 더 깊이 이해할 수 있다고 설명합니다.

스피커는 현재 자세가 아닌 원하는 자세에 대한 트레이닝을 조언합니다.

연사가 어려운 프로그래밍 문제에 부딪혔던 개인적인 경험을 공유합니다.

연사는 처음에는 힘들지만 나중에는 생산성이 높아진다는 점을 강조합니다.

발표자는 이러한 접근 방식이 팀 환경에서 항상 잘 확장되는 것은 아니라는 점을 인정합니다.

연사는 어려움을 극복하면 자신감이 생긴다고 강조합니다.

연사는 어려움을 극복하여 자신감을 키우는 데 스노보드를 비유로 사용합니다.

이 스피커는 낮은 수준의 프로그래밍을 통해 얻은 자신감을 향상된 커뮤니케이션으로 연결합니다.

연사가 '이너 서클' 효과와 자신감이 어떻게 더 나은 기회로 이어지는지에 대해 설명합니다.

자신감은 더 높은 급여와 고용 안정으로 연결됩니다.

연사는 완전히 이해되지 않은 주제를 골라 더 깊이 파고들 것을 조언합니다.

발표자는 라이브러리를 사용하지 않고 무언가를 다시 만들 것을 제안합니다.

연사는 저레벨 게임 엔진 디자인을 배울 수 있는 리소스의 예로 핸드메이드 히어로를 언급했습니다.

연사는 명령줄에서 Git을 배우는 것을 더 작고 달성 가능한 목표로 제안합니다.

발표자는 어려운 방식으로 프로그래밍할 때의 이점을 요약하며 마무리합니다.