불편함을 포용하기: 프로그래밍과 성장의 교훈

### 불편함을 포용하기: 20년간의 프로그래밍에서 얻은 교훈
* 💻 20년 가까이 다양한 언어로 전문 프로그래밍 경력을 쌓아온 저는 경력 초기에 **바꿨으면 좋았을 비판적 사고방식**을 되돌아봅니다.
* 📚 2007년부터 2009년까지 대학 시절, 저는 프로그래밍에 흥미를 느꼈지만 **Linux와 명령줄 인터페이스가 주는 어려움**을 피하고 **Windows와 NetBeans 같은 익숙한 도구**만 고집했습니다.
* 🖥 2008년에 우분투를 배우려고 시도했지만, 어렵거나 다른 것은 본질적으로 잘못되어 **개발자로서의 성장을 제한**한다는 생각에 금방 포기했습니다.
* 🤔 이러한 사고방식은 기술을 넘어 삶의 여러 측면에서 제가 옳다고 생각하는 경우가 많았고, **이는 학습을 방해하는 잘못된 자신감**을 키웠습니다.
* 🚀 인터뷰 중 간단한 명령어로 쉽게 해결할 수 있는 문제를 해결하지 못해 **명령줄에 대한 경험이 부족함**을 드러낸 결정적인 순간이 있었습니다.
* 💡 불편함을 받아들이고 익숙하지 않은 도구를 탐구하는 것이 **장기적으로 문제 해결 능력과 전반적인 엔지니어링 기술**을 향상시키는 데 도움이 된다는 것을 깨달았습니다.
* 🌱 다양한 경험이 주니어 개발자를 선배 개발자와 진정으로 차별화할 수 있는 요소이므로, **안전지대에서 벗어나 새로운 기술을 시도**하고 시야를 넓혀 더 나은 엔지니어가 되기를 바랍니다.
* ✍ "궁극적으로 문제가 해결되는 방식이 다양해질수록 **문제를 해결할 수 있는 방법도 다양**해집니다." 제 이야기를 통해 다른 사람들이 학습과 성장을 받아들이는 데 영감을 얻었으면 좋겠습니다.

프라임젠은 불편한 기술을 피하는 것을 후회하며, 도전을 수용하는 것이 성장과 더 나은 문제 해결 능력을 키운다는 사실을 깨닫습니다.

So I have been programming professionally and on the side for getting close to two decades at this point. I've spent many years writing Java, C, C++, Python, Rust, Go, JavaScript, TypeScript—you name it. If I could go back and correct one mentality of mine

from that entire time, I know exactly what it would be. So first, let me tell you a story so that way you can kind of understand where I'm coming from. In 2007-8-9, I was in college. I'm pretty excited just learning how to program, getting

pretty dang fast. You know, I did a little bit in high school. I did a little bit of it when I was like, you know, in sixth grade, but now I'm really actually doing it. And the thing is is that I've always been on a Windows machine at that point.

I just loved obviously gaming. That was my thing. You almost got me trapped. Oh, I had a lot of fun doing it. And now all of a sudden, I'm in college, and that's still the operating system that I prefer, of course. A lot of my classes and everything

require me to use CentOS or CentOS. I can't—I have no idea. The fresh maker—I have no idea how you actually say the thing, but either way, I, you know, would straddle the line, right? For labs, I used CentOS. At home, I used Windows and

NetBeans on both because come on, it's NetBeans, the greatest editor of all time. In about 2008, I decided I wanted to start a website. I called it 'Life in America is Hard.' I thought it was funny. You'd leave little notes about things.

that are hard in America such as having to wait in line for coffee, those kind of things, right? Anyways, while I was developing it, I kind of had this idea, okay, I kind of want to get good at Linux. And so in 2008, I got a partitioned machine, put Ubuntu on it, and I stuck with it for probably about a week, but I just, I kind of like avoided it, you know what I mean? Like, yes, I was using it, but I really just avoided it. I didn't actually do it, and ultimately I stopped

using it altogether. I kind of had this mentality that I was right, and when I looked at things that had some sort of friction or difficulty to them, and I could kind of perceive it, I would just assume they are wrong. And what I mean by

this, of course, is like using the CLI or Vim or any, you know, kind of like the more hardcore hacker type things. It just felt like they were kind of a thing of the past, a relic of the past, and really the future's in these IDs and that is it.

And I didn't realize how much that was going to hinder me for quite some time, uh, for many, many years. I just simply avoided all these hard things, uh, things that were different, not because they were not beneficial, but because I simply assumed they weren't beneficial. I had

this mentality where I believed I was right, and that didn't just stop with the technologies I used, it also happened to be when I was at work, how I treated people, all those kind of things, right? Because it all is one mentality. I simply believed myself to be more correct, more

often than others in all sorts of areas and yeah I was pretty smart I did the best top of my class I was obviously very good at my job excelled above other people confidence kind of you know even though it was a bad type of confidence it kept compounding in on itself and if

I could go back I really just wish I could tell myself you know it is okay to be uncomfortable it is okay to use something that is perceivably slower than what you use right now or even way more difficult to do the same thing because it's not about your

instantaneous speed up it's about that long-term dividend play if I would have known this I would not have had nearly as bad of an interview as I did for a company I had they asked me hey could you go through a directory and it has

subdirectories and all these different files have uh you know just have a bunch of HTML and all this but we've been hacked and there's a bunch of free viagra call this number throughout all these different files and we'd like to remove all of them now of course me

being the young spittin engineer with zero tolerance for the CLI and those other things what did I do I literally by hand wrote perfectly working Java code buffered writer tokenizer bam bam bam bam bam wrote the entire recursive directory walk from my heart of hearts onto the board and of course what did my

interviewer do you could have just used grep and it was kind of like in that moment I realized I should probably know more right because looking back on it it's obvious I know exactly how I would solve that now you know boom little said grep

super combo right it'd be super easy to kind of go through some stuff and just depending on like if you just want the list of files or do you want me to change them right and so I kind of feel stupid right now looking back and so I

really hope you can hear this it's not just me trying to get you to use Vim or saying the CLI is the best place but really for you to look at problems and understand that you don't know everything and that using things that seem different or strange it's okay

because ultimately it's gonna make you a better engineer and who knows it may pay some amazing dividends down the road and hopefully you don't look like such a doofus as I did during that interview so go ahead if all you ever use is VS Code

try Emacs look at this I'm not even suggesting my favorite editor Vim at this point go just try anything else go try IntelliJ go try some other things see what you can do your all you ever do is just do React and front end try Solid

try Vue expand your horizon try to understand things better because ultimately the more ways you see a problem be solved the more ways that you can solve a problem we are often limited by our experiences and that's really what separates a junior from a senior is

just experiences experiences seeing things done differently and ultimately that's going to make you a much better engineer and I really wish I could have told myself that a decade ago I hope you liked this video please subscribe and of course actually make a comment down

Below, tell me a little story about yourself. I probably will reply to you. My name is Primegen.

If I could give advice to myself when starting as a software engineer

ThePrimeagen

초기 프로그래밍 경험과 아쉬운 점

다양한 언어에 걸친 20년간의 프로그래밍 경험.

2007~2009년 Windows 및 NetBeans를 사용한 대학 경험.

실험실에서는 CentOS를 사용하고 가정에서는 NetBeans와 함께 Windows를 사용합니다.

2008년에 Linux를 배우려고 시도했지만 금방 포기했습니다.

불편하다는 인식으로 인해 어려운 도구(CLI, Vim)를 기피하는 사고방식.

도전을 회피하는 것의 부정적인 결과

이러한 기피 현상은 기술을 넘어 대인 관계로까지 확대되었습니다.

불편함과 대체 도구를 수용하지 않은 것에 대한 후회.

CLI 지식 부족으로 인한 부정적인 면접 경험.

도전과 다양한 도구 수용의 중요성

다양한 도구와 기술(Emacs, IntelliJ, Solid, Vue)을 사용해 보도록 권장합니다.

지평을 넓혀 문제 해결 접근 방식을 확장합니다.

주니어와 시니어 엔지니어를 차별화하는 데 있어 다양한 경험의 가치.