180625-180701

2018년 06월 25일 ~ 2018년 07월 01일 주간 회고


180625-180701 주간회고

Weekly Review

  • 수요일에는 갑작스럽게 일정에 없던 코드스쿼드에서 진행하는 제 5회 마스터즈 오픈 세미나에 다녀왔다.
    • 해야지만 생각하고 항상 미뤄왔던 자료구조와 알고리즘을 주제로 세미나를 진행했다.
    • 정말 유익한 세미나였고 후기를 작성해보았다.
  • 토요일에는 AWSKRUG Hands-on Lab 2018 - Serverless #1 Hands-on 을 다녀왔다.
    • Cloud 9, API Gateway, Lambda, DynamoDB 등을 사용해보면서 깊게는 아니지만 이게 Lambda구나~ 하는 감을 잡을 수 있는 좋은 경험이었다.
    • 실습자료

학습

다음 주 목표

이번 주에 읽었던 좋은 글(출퇴근지하철)

  • 스타트업에서 시니어 개발자를 구하기 어려운 이유 스타트업에 시니어 개발자를 구하기 어려운 이유를 아주 사실적으로 말해주는 글이다.
    • 인정받는 시니어 개발자를 구하기 힘들뿐더러 만약 구하더라도 그 몸값만큼 가치를 당장 만들어내지는 못할 확률이 높다.
    • 괜히 구하기도 어려운 사람, 그리고 구해도 위험 부담이 큰 사람 찾느라 애쓰지 마시고, 이미 있는 개발자를 최대한 지원하고, 함께 성장할 환경을 만들어주며 나아가는 것이 현명합니다. 함께 일하는 지금의 주니어 개발자가 그토록 바라던 시니어 개발자가 되는 것이지요.
    • 시니어 개발자의 스펙이나 조건들보다 더 중요한 게 있지 않을까?
  • 더 나은 프로그래머가 되는 10가지 방법
    1. 웅장한 버그
      • 뛰어난 프로그래머는 뛰어난 수비수이다. 갑자기 메모리가 부족해지면? 서버에 많은 사람이 몰리게 되면? 갑자기 아마존, 구글이 망하고 클라우드 서버가 정지된다면?
    2. 아름다운 주석
      • 가장 좋은 코드는 주석을 달 필요도 없는 코드이다.
    3. 평화 지킴이
      • 팀의 코드 스타일을 지키자. 혼자만 다르면 문제다.
    4. 원인없는 똥통은 없다.
      • 남이 쓴 코드는 언제나 똥통이다. 그러나 모든 똥통엔 원인이 있다.
    5. 내가 시작과 끝이노라
      • 혼자만 이해하는 코드는 혼자만 유지보수할 수 있다. 팀과 소통하는 코드를 쓰자.
    6. 적들을 포위하라!
      • 한 번에 모든 버그를 잡을 순 없다. 하나하나 구역별로 단위 테스트를 진행하자.
    7. 나는 완벽하지 않아
      • 프로그래밍 세계는 정글과 같다. 그렇기 때문에 성장을 하고자 한다면 성장할 수 있는 부분이 무한에 가깝다 할 수 있다.
      • 뛰어난 프로그래머는 다음 질문에 쉽게 답할 수 있을 것이다.
      • 현재 무엇을 배우고 있는가?
      • 5년 후를 위해서 무엇을 배우고 있는가?
      • 당신은 겸손한 프로그래머인가?
    8. 아참! 나도 뇌가 있었지!
      • 개발도중 문제를 발견했을 때 가장 먼저 하는 일이 구글 검색인가?
      • 남이 짠 코드를 이해하기 전에 복사 붙여넣기 하는가?
      • 이 루프에 빠져있다면 결코 성장할 수 없다.
    9. 이거 괜찮지 않아?
      • 좋은 소프트웨어는 괜찮은 아이디어가 아닌 최고의 아이디어가 필요하다.
    10. 소중한 내 몸
      • 당신이 위대한 코드를 쓰는 전지전능한 풀스택 개발자여도, 몸이 이러면 코드를 쓸 수 없다.
  • 스펙에 대한 집착으로 우수한 인재를 놓칠 수 있다 사람을 구하기 힘든 이유가 마땅한 지원자가 부족해서일까? 스펙이 부족한 지원자가 문제일까? 아니면 그 스펙이 문제일까?, 여러 질문에 대한 대답을 들을 수 있는 글이다.
    • 경험이 많은 개발자란, 소프트웨어의 구조와 개발 방법론, 프로그래밍 언어와 프레임워크를 포함해, 다양한 분야에 걸친 지식과 경험을 쌀아온 사람이다.
    • 컴퓨터 분야의 대학 입학생이 감소하고 있다는 사실이 쓸만한 개발자가 부족하다는 불평의 이유가 될 수도 있겠지만, 학위가 좋은 개발자의 조건이었던 적은 단 한 번도 없었다.
    • 스펙에 치중하고 자동화된 시스템으로 이력서를 검토해서는 좋은 사람을 뽑을 수 없다는 사실
    • “사람을 뽑을때, 나는 지원자가 우리의 문화와 맞는지를 봐. 성격이 밝은지, 배우려는 자세가 되어 있는지. 그게 다야. 경력이 어떻고하는 등의 이야기는 우리에게는 별로 중요하지 않아.” 이것이, 뽑을 사람이 없다고 불평하기 전에 우리가 취해야 할 자세일 것이다.
  • 소비하는 디자이너, 주장하는 디자이너 디자이너에게만 해당하는 말이 아니라고 생각한다. 개발자 역시 생각해야 하는 부분이라고 생각한다.
    • 나는 어떤가. 이 회사에서, 이 팀에서, 이 제품에서, 이 페이지에서, 이 버튼에서 디자이너로서 회사와 동료, 그리고 사용자에게 주장하는 것은 무엇인가. 지친 몸을 이끌고 회사에 출근해 늦게까지 모니터를 바라보고 있는 것은 왜 때문인가.
  • 개발자를 위한 (블로그) 글쓰기 intro
    • 좋은 글을 많이 보는 노하우 + 꾸준히 글을 작성하는 노하우에 대한 변성윤님의 발표자료이다.
    • 생산적인 글쓰기를 위한 꿀팁들이 많이 있는 글이다.
    • 그리고 강제 글쓰기 모임 (글또) 정말 괜찮아 보인다. 기회가 된다면 참여하고 싶다!
  • [정리] 프로그래머에게 필요한 피드백, 그리고 QuickAndDirty
    • 프로그래머에게 필요한 피드백은 세 가지다. 1) 내가 참여한 프로젝트가 성공했는가. 2) 내가 개발한 기능은 제대로 동작하는가. 3) 나의 개발 속도는 얼마나 빠른가.
    • 성장을 위해 가장 중요한 건 세 번째다. 물론, 여기에 성장 의지, 피드백에서 알아낸 상관 관계에서 인과 관계를 뽑아낼 분석력 등도 필요하다. 피드백은 전문가로 가는 길의 첫걸음 정도로 생각하면 된다.
    • TDD, 리팩터링 등 각종 기법의 모든 목표는 생산성, 즉 더 빨리 프로젝트를 완료하는 것이다. clean code의 극한을 추구하느라 느리게 개발하는 건 용납될 수 없다.
    • Quick And Dirty
      • 스타트업은 quick & dirty를 해야 한다. ‘아무도 쓰지 않는 훌륭한 제품’은 결국 쓰레기다. 기술 부채 만드는 것을 두려워하면 안 되지만, 그 부채는 감당할 수 있는 수준으로, 파산하지 않게 유지해야 한다. 너무 좋은 코드도 너무 나쁜 코드도 스타트업에게는 좋지 않다. 적정 기술, 적정 품질을 생각하며 일하는 엔지니어가 되자.
  • 함수형 사고 총 7개의 글로 이루어져 있는 함수형 사고에 대한 글이다. 최근에 Java Lamda를 적극적으로 쓰려고 노력하면서 고계함수를 통해 추상화 단계를 높이는 것이 많은 이점들을 가져다준다는 것에 동의하게 되었다. 패러다임의 변화, 왜 모든 고수준 언어들이 함수형으로 바뀌고 있는지 그 이유에 대해 느낄 수 있는 시리즈이다. 함수형 프로그래밍을 조금 더 깊게 공부한 후 복습 차원에서 봐도 좋을 것 같다.

  • 이규원님이 진행하는 TDD 참관 후기 이규원님이 진행하는 TDD 참관 후기 페이스북 글이다. 짧지만 핵심만을 전달하는 후기라는 생각이 들어 기록하게 되었다.
    • “테스트 케이스는 요구사항이라서, 새로운 담당자가 왔을때 ‘왜 이렇게 만들었지?’라며 소스가 이해가 안되면 테스트 코드를 보면서 이해를 하고, 새로 온 사람이 실수를 하더라도 테스트 레벨에서 탐지되게 해서 시스템 전반적인 안정성을 높인다.”
    • “테스트 코드는 요구사항과 같다.”
      • “이런 요구사항이 있는데…“라며 요구사항일 기술하는 것이 테스트 코드이고, 구현도 안한 요구사항이 성공할리 없으니 당연히 실패하고, 그 요구사항을 완성해 내는게 TDD의 과정이라는 생각이 들었다.
    • 결국 크고 아름답고 추상적이라 개발하기 싫은 요구사항을, 작고 명확하게, 그분이 오지 않은 집중력으로 할만한 크기로 나눠서 접근하는… divide and conquer를 적용한게 TDD라는 느낌이었다.
  • 백엔드 개발자를 꿈구는 학생개발자에게 D2 CAMPUS에서 백엔드 개발을 주제로 진행한 Tech meet-up.
    • 다 너무 좋은 자료라서 정리하기가 힘들다.
    • 백엔드 개발자를 생각한다면 꼭 읽어 봤으면 하는 글이다.
  • 6) 3번째 직장에 오기까지 - 6. 세번째 직장 창천향로님의 3번째 직장에 오기까지 시리즈의 마지막 글. 정말 노력하는 모습이 자극 되기도 하고 멋있고 아낌없이 공유해줘서 너무 감사하다!
    • 테스트 코드와의 만남
      • 당시에 운영 중인 프로젝트를 보면 정말 배울게 많았습니다.
      • 다만, 테스트 코드가 전혀 없었습니다.
      • 자바지기 박재성님께서 TDD, 테스트 코드, DI 프레임워크 만들기, HTTP 웹서버 만들기 등 제가 그동안 궁금했던 모든 내용을 알려주는 강의를 시작 (강추!)
    • 탈진
      • 성장 없이 소모만 되는 일을 언제까지 해야하는 건가에 대한 회의감
      • 기술적 도전 보다는 UI를 변경하는 것이 대부분
      • 더 큰일은 더이상 제 코드를 리뷰해줄 분이 없다는 것
    • 두번째 이직 준비
      • 제 공부와 만족을 위해서 시작한 블로그를 보고 계시는 것도 놀랍고, 그걸 보고 직접 이직 이야기를 해주신건 더더욱 놀라운 일이였습니다.
      • 하루 하루 남긴 기록이 얼마나 큰 효과를 주는지 깨달은 날이였습니다.
        • 확실히 6개월 혹은 1년에 한번씩은 이력서 갱신이나 면접을 다니면 좋은것 같습니다.
    • 생각해 볼 면접 질문
    • 여기와서 최신기술을 쓴다해도 결국 시간이 지나면 그 기술은 옛 기술이 될텐데, 그럼 그때도 이직할것인지?
    • 본인이 했던 도메인이 우리 회사와 어울리는게 없는데 어떻게 생각하는지 (포털 -> 커머스)
facebook share twitter share
0%