All-round programmer

요즘 협업을 하면서, 팀을 리드하면서 디자인 리뷰를 하면서 많이 생각하게 되곤 합니다. 내가 생각하고 있는 것이 맞는 정답일까, 이 사람이 만들어놓은 디자인은 맞는 정답일까? 그런데 프로젝트를 여러 번 하다 보니 내리게 된 결론은 다음과 같습니다. 시스템 디자인에 정답은 없습니다. 요즘 다시 고용 시장이 조금 회복되면서 다시 인터뷰도 많이 하고 있습니다. 저는 자주 시스템 디자인 세션을 맡곤 하는데, 한 시간의 인터뷰 세션 안에서 자기소개하고 인터뷰이 소개하고 기본적인 질문들을 하다 보면 15분 정도 쉽게 지나가고 마지막 5분은 질답 시간으로 남겨두려면 결국 남는 건 40분 밖에 되지 않습니다. 40분 안에 물어보는 시스템 요구사항에 대한 최적의 디자인을 만들기란 당연히 턱 없이 부족합니다. 인터뷰어로서..

코드리뷰를 하다보면 정말 좋지 않은 코드를 많이 보곤 하죠. 이럴 때 '이것 제대로 고쳐주세요', 라고 이야기하면 가끔씩 들려오는 이야기가 "급하니까 나중에 고칠께요." "일단 배포하고 수정할께요." 비슷한 부류로 이러한 케이스도 있죠. "일단 배포하고 테스트 쓸께요." 이러한 상황이 많다면 근본적으로 다시 어떻게 일을 하고 있는지 검토가 필요할 겁니다. 아니면 혹시 주위에 이러한 개발자가 보인다면, 이러한 개발자는 온 몸에 시한폭탄을 두르고 다니는 개발자이기 때문에 좋은 길로 잘 인도해주거나 좀 거리를 두는 것이 좋을 것입니다. 그러면 이러한 개발자를 어떠한식으로 올바르게 성장 시킬 수 있을까요? 먼저 어떠한 개발자들이 이러한 이야기를 많이하는지 대충 살펴보면: (1) 정말 급한 요청을 처리하는 개발자..

제목을 다소 과하게 잡기는 했는데 이 부분에 대해서 제가 스트레스를 받은 적이 많아서 꼭 이야기하고 싶었던 내용 중 하나입니다. 사실 제목과 다르게 남의 문제를 지적하는 건 사실 괜찮습니다. 이거 보여주고 싶어서 어그로 끌어보았습니다. 제가 여기서 집중하고자 하는 부분은 '남의 문제를 지적'하는 행위 자체가 아니라 '어떻게 지적하느냐'에 대해서 조금 더 이야기해보고 싶었습니다. 제가 최근에 몇 년 새에 겪었던 두 가지 케이스를 이야기해드리고자 합니다. 1. 이상주의 개발자 D와의 협업 가끔 보면 개발자 중에 이상주의자들이 많습니다. 이상주의자란 무엇이냐 하면 항상 이상적인 세계를 꿈꾸듯, 이상주의 개발자는 항상 이상적인 코드와 이상적인 인프라를 상상하는 개발자들입니다. 이러한 이상적인 것을 추구하는 것이..

정말 이거 하소연하고 싶어서 미쳐버릴 것 같네요. 여러 오래된 서비스를 제공하고 있는 팀들과 협업하다보면 이러한 이야기를 자주 듣곤 합니다. "너무 옛날 시스템이라서요" "문서화가 전혀 안 되어있어서요" "개발 했던 개발자가 팀을 떠나서요" "옛날에 다른팀에서 지원해줬던 개발자가 개발한거라서요" 하.. 이런 핑계들 좀 안 하면 안 될까요. 이러한 소리 들으면 정말 답답하고 한숨만 납니다. 물론 저도 개발자인지라 가끔 특정한 기준 아래에 이러한 핑계를 대기는 합니다. "처음 서비스를 인수인계 받고 담당하게 되는 세 달 동안만 이런 핑계 허용" 세달은 프리패스로 책임 회피가 가능한 마법의 문장들이죠. 물론 세달 동안 서비스의 구석구석 100% 전부다 이해할 수는 없지만, 최소한 메인 플로우, 문제가 있다면 ..

개발자로 일하다보면 정말 답답하게 행동하는 사람들이 너무나 많은데 그냥 갑자기 하소연이 하고 싶어지네요. 사실 트위터 정도의 짧은 글로 써도 되는 시리즈이기는 하지만, 트위터는 쉽게 쓰고 쉽게 지워져버리니 블로그에 짧게나마 짧게 짧게 쓰려고 합니다. 어떠한 주제로 글을 쓸거냐면: "제발 개발자라면 이런것 좀 하지 말아라" 입니다. 그래서 개발자 안티패턴으로 쓰려고 합니다. 절대 제 주위에 답답하고 짜증나게 하는 개발자들만 많아서 이런거 쓰는건 이니지만(..), 그냥 오며가며 여러 개발자들과 동업하다보면 특정한 행동이 답답한 경우가 많아서 그러한 경험들을 돌이켜보며 하소연하려고 합니다. 참고로 저는 상대가 답답하게 하면 그 행동이 고쳐질 때까지 지적하고 귀찮게 합니다. 그래서 제 주위에 그런 사람이 많지는..

이번에 회사 내에서 컨퍼런스 발표를 하려고 간단하게 자료 조금 준비했던게 있어서 블로그에 간단하게 공유하려고 합니다. 최근의 경험들을 바탕으로 어떠한식으로 서비스 개발이 이루어지고 있는지에 대한 개발 프로세스를 소개하려고 합니다. 앞으로 글을 대략 5개 정도로 나눠서 Trunk based development 방법론에 대해서 다루려고 합니다. 개인적으로는 기존의 깃플로우나 깃헙플로우와 비교했을 때 보다 월등하게 좋아서 관련 경험들과 노하우들을 공유하려고 합니다. 개발 방법론에 대한 이야기라 글이 많지는 않겠지만, 대략적으로 아래의 5개 정도가 될 것 같고 두주에 글 하나 정도씩 업데이트를 목표로 하겠습니다. - [1] Trunk based development 소개 - [2] Trunk based dev..

거의 반년만에 근황 글을 쓰게 되네요. 반년간 너무나 많은 일들이 있었고, 많은 일들 덕분에 너무나 바쁘고 정신없이 지내고 있습니다. 며칠전 장모님이 미국을 방문하게 되어 오랜만에 조금 여유가 생기게 되었네요. 요즘들어서 드는 생각은 확실히 육아는 최소 3명이 해야 좀 더 개인의 삶이 존재한다는 것이네요. 아무튼 최근 근황을 요약하자면 아래와 같습니다. * 재택근무아내와 저도 서로 육아가 힘들다보니 최근에 재택근무를 참 많이 하게 된 것 같네요. 재택근무를 하면 좋은 점도 있지만 나쁜 점도 참 많은 것 같습니다. 일단 좋은 점은 집에서 그냥 일하면 되니까 출퇴근에 대한 시간 제약없이 그냥 짬짬이 생기는 시간을 활용하면 된다는 것이고, 안 좋은 점 또한 시간 제약이 없다는 점인 것 같습니다. 딱 정해진 출..

* 열심히 하겠다는 그 다짐 = 3일지난번에 근황글을 쓰고 며칠 정말 열심히 글을 썼습니다. 저도 공부가 필요했던 부분도 있었고, 쓰다가 제대로 마무리 못했던 글을 몇 달간은 붙잡고 있는 것이 싫어서 후다닥 썼는데 역시나 딱 작심삼일이었던 것 같네요. 또 다시 정체기가 왔네요. 이제 이번주에 가족들이 한국에서 오기 때문에 그 동안 자유 방임 상태로 놔두었던 집을 청소해야 하고 노총각(아재?) 냄새가 조금이라도 사라질 수 있게 이불들도 빨고 할게 많습니다. 세금보고도 아직 마무리 못해서 얼른 해야 하는데 집에 오면 저도 모르게 티비를 틀어버리는 것이 습관이 되어버린 것 같습니다. 오늘 다시 한번 다짐을 해서 가족이 오는 금요일 전까지 글 몇개라도 더 쓰고자 합니다. 지금 다짐하면 또 3일 뒤는 딱 금요일이..

APC 입국 수속을 처음으로 경험했던 것이 시애틀 공항이어서 처음에는 시애틀 공항이 특이한가 생각했지만, APC에 대해서 찾아보니 미국 내 조금 큰 공항들은 이미 많이 하고 있는 것 같네요. 다른 공항들은 지금 어떤지 모르겠지만, 처음으로 겪어봤던 시애틀 공항의 입국 수속 절차는 '최악'이었습니다. 그래서 몇 번 시애틀 공항으로 입국을 해보니 이제 조금 파악이 되는 것 같아 글을 써봅니다. * 일반적인 공항의 입국 순서일단 먼저 다른 공항의 기본적인 해외에서 입국 절차는 아래에서 크게 벗어나지 않습니다. 비행기 도착입국 수속짐 찾기세관 신고공항으로 나가기 여기서 (2) 입국 수속과 (3) 짐 찾기 사이에 영주권 등의 비자로 입국을 하게 되면 별도의 프로세스를 거치게 되는 경우도 있고, (4) 세관 신고를..

회사 내의 위키를 보다가 문득 가끔씩 봤지만 뭔지 모르는 약어인지 태그인지 정체 불명의 단어(?)를 보게 되었습니다. TL; DR사실 오늘 처음 본게 아니라 지금까지 은근히 이 요상한 단어(?)를 많이 봤던 것 같습니다. 그냥 얼핏 보기에는 뭔가 태그 등과 같이 HTML 태그를 잘못 쳐서 오타가 생긴건가하는 생각을 하고 지금까지는 그냥 무시했습니다. 그런데 오늘 보고는 그래도 시간적 여유가 좀 있어서 도대체 이게 뜻이 뭔지 검색해보았습니다. TL; DR = Too Long; Didn't Read = 너무 길어서 안 읽음 ...... 이게 뭐지 크크크 뭔가 심오한 뜻이 있나 했네요.... 이게 뭔가를 나타내는 뜻일거라고는 생각을 했지만 전혀 예상치 못한 뜻이었네요 크크크 그냥 인터넷 신조어로 너무 길어서 ..