셩잇님의 잡동사니

[개발자의 공부법] 뭘 공부해야 되지? 뒤처지기는 무섭고 일단 Coursera와 Udemy에서 핫한 온라인 코스가 30% 세일해서 등록해야 할 것 같아서 합니다. 막상 등록하니까 흥미는 없고 도대체 어디에 써먹을 대도 없고 안 써먹어서 까먹고... 악순환의 반복이 시작됩니다. 학생 시절에는 공부할 게 산더미 같던데 막상 개발자가 되니 도대체 뭘 공부해야 할지 모르겠더라고요. 주니어 시절 했던 아주 나쁜 이 공부법을 스스로 고치면서 나름 도움 되었던 "개발자의 공부법"에 대해 이야기해봅니다. 1️⃣ 시스템 디자인 공부 시스템 디자인 공부는 어느 개발 직종에 있더라도 필수이다. 알고리즘과 달리 대학 전공 수업에서 배울 수 없고, 배운다고 해도 학생 시절에는 제대로 써먹을 곳이 없다. 따라서 업무와 경력을 통..

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법 개발 도서는 책 두께에서 일단 현타 오고, 책 읽으면서 두 번째 현타 오고, 책을 다 읽고 나면 "내가 방금 뭘 읽은 거지...?"라는 생각이 많이 들더라고요. 대학 전공 시절에는 이것 때문에 책을 5,6번 반복해서 읽었습니다. 직장인이 되고 나니 시험 보는 것도 아닌데 굳이 5,6번 반복해서 읽고 싶지 않고 그럴 시간도 없습니다. 별거 없지만 적어도 목표인 한,두 달에 최소 개발 도서 한 권씩 읽으면서 나름대로 습득한 효율적으로 확실하게 읽는 법 공유합니다. 1️⃣ 종이 책보다는 전자책으로 연초에는 나름 세웠던 새해 계획을 시작한다고 열정이 넘쳐서 종이책을 구매한 후 한 줄 한 줄 꼼꼼히 읽으면서 덤으로 노트까지 받아 적었다. 이렇게 독서하니까 한 장..

코딩 테스트 어디서부터 준비해야 할지 막막하신가요? 코딩 테스트에 완벽하게 대비하기 위해 해야 할 6가지를 소개드립니다! 💡 Part 1: 문제 풀기 전 해야 할 세 가지 코딩 테스트에 대비하기 위해서는 문제만 많이 풀어보면 된다고 생각하시는 분들이 많습니다. 그런데 어느 문제를, 무슨 프로그래밍 언어를 사용해서, 어떤 순서로 풀어야 할까요? 본격적으로 문제를 풀기 전에 아래 세 가지를 정하고 시작하시길 권장드립니다. 1️⃣ 프로그래밍 언어 선택하기 면접을 볼 프로그래밍 언어는 본인에게 가장 편하고 익숙한 언어로 선택하시는 게 좋습니다. 우리가 영어를 쓸 때보다 한국어를 쓸 때 더 수월하게 말이 나오듯이, 모국어처럼 편하게 느껴지는 프로그래밍 언어를 사용해야 긴장되는 면접 환경에서도 버벅거리지 않고 코드..

프로그래머의 두통을 유발하는 7가지 > 링크한 아티클은 제목만 참고하고 저의 의견을 덧붙였습니다. 1. 기술을 조금 알고 있어서 문제인 상사 아예 모르면 거의 간섭을 하지않지만, 조금알면 자기가 아는 것과 다르다고 훼방을 놓는 사람을 말합니다. 2. 코드 작성 다했는데, 요구사항이 변경되는 경우 이런 경우는 다들 있으실겁니다. 애자일을 사용하는 경우에도 사실 빈번합니다. 3. 태스크 시간 예측하기 소프트웨어를 작성하는 시간을 예측하는 것은 어렵습니다. 주니어건 시니어건 상관없이 말이죠. 4. 클라이언트에게 데모 보여주기 잘 동작하던 것들이 꼭 데모만 하면 크래시가 나는 경우가 여럿있습니다. 5. 문서작성 업무가 매우 많은 상황에서 코드 작성을 다하고 조금 쉬고 다음일을 해야하는데 추가적으로 문서도 작성해..

최근에 만난 한 개발자 분에게 인상적인 말을 들었습니다. “주니어 개발자라면 일단 주어진 일을 어떻게든 해내야 한다. 그 일을 더 빨리, 더 잘 해낼수록 시니어가 되는 것이다. 주니어든 시니어든, ‘끝까지 해내는 것'이 기본이다.” 이 말을 듣고 뭔가 심장이 쿵, 머리가 번쩍! 하는 느낌이었어요. 꼭 개발자에게만 해당되는 이야기는 아니고, 일하는 사람 모두의 기본인 것 같다는 생각도 들었고요. 퍼블리 멤버십에는 아직 개발 주제의 콘텐츠가 많지 않은데요. 그럼에도, 퍼블리를 꾸준히 구독해주시는 개발자 분들이 있습니다. 아마 기술 외적인 측면에서도 일을 제대로 잘 해내고 싶은 분들이 퍼블리 콘텐츠에서 도움을 받고 계신 게 아닐까 싶어요. 그래서 궁금해졌습니다. 개발자 분들이 가장 많이 읽은 퍼블리 아티클은 ..

개발자의 면접은 철저한 준비가 필요한 영역입니다. 1시간 안에 실력을 증명해야 하는 면접은 평상시 업무 방식과는 다를 수밖에 없습니다. 따라서 아무리 평소 실력이 뛰어난 개발자라도 기술 면접에 대비하기 위해서는 별도의 준비가 필요합니다. 준비를 하기에 앞서서 어떤 방식으로 면접이 진행되는지 알아야겠죠. 개발자에게 출제되는 면접 유형 6가지를 공유드립니다! 1️⃣ 라이브 코딩 테스트 ‘라이브’ 코딩이라는 이름답게 면접관과 영상 통화를 하며 실시간으로 면접관이 내는 문제를 코드로 구현하는 방식입니다. 45분~1시간 정도의 시간제한이 있지만, 보통 자기소개를 하거나 직무에 관한 질문을 하는 데 5~10분 정도의 시간이 소요되기 때문에 그 점을 감안하고 문제를 푸는 것이 좋습니다. 이 시간에는 주로 단시간 안에..

가끔 일을 하다보면 "상헌님은 개발자인데 말이 잘 통하는 것 같아요" 라는 말을 듣습니다. 칭찬은 아주 감사하지만 사실 "개발자는 보통 말이 안통한다"라는 기저가 깔려있는 말입니다. 주위에 보면 그래도 일은 어떻게든 해내야 하기에, 좀 더 효율적인 커뮤니케이션을 위해 개발용어를 익히거나 심지어 개발을 배워보는 타 직군분들도 계십니다. 개발자는 대체 왜 보통 말이 안통할까요? 그 이유로 개발자나 공대생에 대한 스테레오타입이 언급될 때가 많은데, 저는 그것보다는 "나만 가지고 있는 지식과 컨텍스트를 바탕으로 설명" 해야하는 빈도가 잦고, 그것은 사람에 관계없이 원래 어렵기 때문이라고 생각합니다. 이를테면 기획자도 본인의 머리속에만 완성된 논리나 철학을 바탕으로 다른 직군을 설득해야 할 때가 있고 당연히 어려..

얼마 전 2분기 동료평가를 했습니다. 평가를 하다보니, 극단적인 상황에서도 힘이 되어주던 동료들의 말 한마디가 잊혀지지 않고 계속 생각이 나더라구요. 그 말들을 소개하려 합니다. 1. 버그가 슬픈 일인가요? 테스트 버전을 출시하고 테스트를 막 시작했을 때였어요. 저희 프로덕트는 숫자가 딱 맞아야하는데 숫자가 하나도 맞지 않았어요. 아무리 테스트 버전이라지만 맞는게 거의 없다시피하다보니 저도 모르게 너무 슬프네요 라는 말이 나와버렸어요. 그때 동료 한 분이 ‘이게 슬픈일인가요?’ 라고 물어보시는데 그때 정신이 확 들었어요. 수정할 부분을 발견했다면, 원인을 찾고 고치면 되는거지 전혀 슬퍼할 일이 아니었던 거였죠. 더군다나 운영 환경도 아니고 테스트 환경이었는데 말이죠. 그렇게 마음을 고쳐 먹으니 훨씬 즐거..

회사에서 면접관 역할을 맡게 되면서 많은 이력서를 읽어 봤습니다. 이력서를 쓰는 사람의 입장에서 읽는 사람의 입장이 되어 보니 어떤 이력서가 더 눈에 띄는지, 어떤 이력서가 별로인지가 보이기 시작했어요. 그렇게 무수히 많은 이력서를 읽고 쓰며 터득한 이력서 작성 팁을 공유합니다! 🙆🏻‍♀️ 이력서 쓸 때 해야 할 것 이력서의 기본 원칙은 간단합니다. "읽는 사람을 생각하기." 아무리 많은 내용을 담아도, 읽는 사람을 고려하지 않은 이력서는 매력이 없습니다. 이력서를 쓸 때는 ‘이걸 읽는 채용 담당자가 면접 기회를 줄만큼 매력 있는 이력서인가’를 생각해봐야 합니다. 매력적인 이력서를 쓰기 위해 꼭 해야할 것 중 많은 개발자들이 놓치는 세 가지를 선정해 보았습니다. 1️⃣ 자신이 한 일을 비즈니스 임팩트와 ..

본론에 앞서 이 글은 그동안 제가 만나본 성장이 빠르다고 느낀 주니어 개발자분들의 태도와 습관을 정리해보는 글입니다. 기술이나 학습등을 거론하며 '이런것만 배우면 당신도 빠르게 성장할 수 있습니다!' 류의 글은 아니고 그분들의 이런 태도와 습관이 성장에 영향이 있지 않았을까 정도의 글이라고 생각해주시면 되겠습니다. ✅️ 질문을 잘한다. 빠르게 성장하신 분들의 질문엔 2가지 공통점이 있었다. 1. 질문의 타이밍 대부분의 신입사원이나 주니어 개발자분들은 선배 개발자에게 질문을 하기 부담스러워 한다. 그래서 혼자 몇일을 끙끙거리다가 힘겹게 질문하거나 선배 개발자가 먼저 말을 걸어서 답을 얻는 모습을 많이 본다. 만약 알고싶던 내용이 선배 개발자가 바로 대답해줄 수 있는 것이었다면 오래 끙끙거린만큼 시간을 허비..

# 코드 작성 이전에 해놔야 할 것 제가 코드 작성에 앞서 꼭 하는 것은 코드로 표현할 대상(또는 목표)을 몇 줄의 문장으로 표현하는 것입니다. 꼭 큰 규모의 코드가 아니더라도 작은 함수 개발 또는 이슈를 수정하기 위한 코드를 작성하기 전에 문장으로 표현하는 것은 큰 이점이 있습니다. 첫 번째, 표현할 대상을 명확하게 만들 수 있습니다. 글로 어떤 대상을 표현한다는 것 자체가 대상을 점차 명확한 형태로 만들어가는 과정의 일부입니다. 두 번째, 자연스럽게 테스트코드로 이어질 수 있습니다. 작성한 문장을 보면 검증할 부분들이 보이게 됩니다. 검증할 포인트가 잘 정리되었으니 쉽게 테스트 코드를 작성할 수 있습니다. “소비내역 중 카페 소비내역을 뽑아내고 소비한 총 금액을 찾야겠어”라는 문장을 적고 작업한다고 ..

10년차가 되어도 여전히 자주 하는 실수 중 하나는, 문제를 정의하는 것부터 해결하는 흐름을 코드에서만 찾는다는 것입니다. 예를 들어, 웹사이트의 속도가 느리다는 제보가 어디선가 들어옵니다. A. 웹사이트의 속도가 느리대요! B. 어 왜 느리지? 코드 살펴볼게요. B. 코드에 불필요한 코드가 너무 많았네요. 다 제거해볼게요. B. 다 제거해서 배포했습니다. A. 그래도 속도가 여전히 느린 거 같아요! B. 오 이제 최적화할 수 있는 게 없는데...? 일단 이 대화에서 몇 가지 우리가 놓친 게 있어요. 1. 웹 사이트는 지속적으로 항상 느린가? 그 순간에만 느렸는가? 2. 속도가 느리다고 말한 사람의 환경은 어땠는가? 3. 속도 측정 도구 등을 이용해 측정할 수 있는가? 4. 속도가 빠르다 느리다에 대한 ..

Q. 저는 현재 프론트엔드 쪽에서 개발을 하고 있습니다. 입사한 지는 약 8-9개월 정도 되었구요! 팀 특성상 동기가 없기도 하고, 저와 비슷한 연차의 개발자분들이 안 계셔서 질문을 올리게 되었습니다. 현재는 기존 서비스의 오류를 해결하거나 가끔 새로운 서비스를 개발하기도 하면서 업무를 보고 있는데, 1년 정도 되어가는 신입 개발자는 어느 정도의 업무를 커버할 수 있는 스킬이 필요할까요??? A. 최근에 비슷한 질문을 받아서 그 분께 답변을 드렸던 내용과 비슷하게 답변을 드려보겠습니다. 1. 회사에 배울 점이 있는 동료, 선배와 친해지세요! 기술적인 내용도 이야기 하고, 꼭 딱딱한 이야기가 아니더라도 서로 친밀한 관계를 유지하면 정말 나중에 큰 도움을 받습니다. 경험상 주니어때는 본인이 능력이 부족해서라..

"게임을 만들 때는 만들어야할 게 많습니다. 음악, 아트, 게임 디자인, 스토리, 코딩 등... 이 요소는 다 동등한 것으로 보이지만 실제로는 아닙니다." "많은 경우에 게임 디자인은 그들과 동등하지 않고 오히려 그들을 지탱하는 기반으로 기능합니다. 그래서 게임 디자인이 무너지면 다른 것도 다 무너집니다." 유튜브 채널 GMTK를 운영하는 마크 브라운이 소개한 자신의 유년시절 일화는 이러하다. 1. 게임의 스토리 컨셉과 아이디어가 떠오름. 2. 바로 포토샵을 켜서 도트를 찍고 캐릭터도 만들고 컷신도 만들고 메뉴도 다 만듦. 3. 근데 중요한 걸 깨달음 4. 게임이 노잼임 5. 그만둠. 6. "마크, 이 멍청아." 많은 개발 지망생들이 아직 만들어지지도 않은 자신의 게임의 완성된 모습이나 눈에 보이는 아트..