"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한 강연 발표 자료.
•
3 likes•956 views
2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한 강연 발표 자료. 아래와 같은 내용이 있음. • 백발의 개발자 • 행복 • 성장 • 학습 • 동기부여 • 일 잘하는 개발자 / 개발 리더
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to "행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한 강연 발표 자료.
Similar to "행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한 강연 발표 자료. (20)
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한 강연 발표 자료.
- 1. 2024.03.06 Ktown4u 백명석 행복한 백발의 개발자 1
- 2. 소개 주요 이력 • (주)케이타운포유, 2022.06~ • CTO(개발본부장). 이커머스/물류 서비스 개선 및 운영, 신규 서비스 구축, MSA 분리, 개발 문화 개선 • SKPlanet / 11번가(주), 2016.11-2022.05 • TechInfra 본부장. Portal개발그룹장. 개발 문화 개선, Spring Cloud 기반 MSA 적용, EDA 기반 비동기 결제, Public Cloud를 활용한 이벤트 트래픽(쿠폰 다운로드) 개선 • Daum / Kakao, 2006.03-2016.10 • 개발리더. 카페, 검색, 소프트웨어품질, 클라우드, 회원, 게시판 조직에서 개발 및 조직 리딩. 아고라, 미즈넷 등을 포함한 20여개 섹션에 사용되는 전사 게시판(GAIA) 개발. TDD, 클린코드 강의 • (주)트랜스넷, 2002.1 – 2006.03: VoIP • O1 Inc, 1999.09 – 2001.12: 인터넷 투자은행 • LG-CNS, 1996.10 – 1999.08: 미들웨어 2 2.1 살아남는 놈이 강한 놈이다
- 3. 소개 관심사 • 지속 가능한 소프트웨어 시스템 개발(OOP) / 개발자 역량 증대1 • Java, TDD, Design Patterns, Refactoring, DDD • Clean Code / Architecture, Code Review, Agile(Lean) Development • 개발 조직 구축 및 개발 문화 개선 • 개발자 성장, 코칭 3
- 4. 목차 • 백발의 개발자 • 행복 • 성장 • 학습 • 동기부여 • 일 잘하는 개발자 / 개발 리더 • Q & A 4
- 5. 케이타운포유(Ktown4u) • K-POP 글로벌 온오프라인 통합 플랫폼 • 243 개국, 700만 가입자, 7,000팬클럽 • 2017 → 2022 B2C 전환. 16배 성장 • 이커머스 플랫픔, 글로벌 배송 물류센터 • 해외 배송 최적화 배송 솔루션 구축 • 총 200여명, 개발자 18명 5
- 6. 시작하기 전에 • 규율(Discipline) • 본질적인 부분(Essential) • 규율의 존재 이유 • 규율에 권위 부여 • 임의적인 부분(Arbitrary) • 규율에 형태/실체 부여 • 이 부분 없이는 규율 존재 불가 6
- 7. 백발의 개발자 7
- 8. 백발의 개발자 • 면담. 꿈 • 나이 먹어도 개발자 • 한국에선 관리자 • 15~20년 후의 자신 • 그를 위해 앞으로 5년, 1년, 지금은 ? 개발자들의 꿈 8
- 9. 백발의 개발자 • Robert C. Martin: 1952년생 • Kent Beck: 1961년생 • 9살(1970년). 실리콘밸리. 개발자 아버지의 책 • Martin Fowler: 1963년 생 • 1999년의 나, 2024년의 나 • 제안서, BMT, 관리 • 코드리뷰, 리팩터링, 지식과 경험의 공유, 코칭, 개발 문화 개선 개발자들의 꿈 9
- 10. 행복 10
- 11. 행복 • “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do" • "당신의 일은 당신의 삶의 큰 부분을 차지할 것이고, 진정으로 만족하기 위한 유일한 방법은 당신이 위대한 일이라고 믿는 것을 하는 것입니다. 그리고 위대한 일을 하는 유일한 방법은 당 신이 하는 일을 사랑하는 것입니다" • 스티브잡스, 2005년 스탠퍼드 대학교 졸업식 연설 워라밸 11
- 12. 행복 • 내가 제어할 수 있는 것에 집중 • 과정: 내가 성장하고 잘 하는 것 • 결과: 평가, 보상, 정량적 성공 등 - 부산물 • 운칠기삼(運七技三) • 결과 = (열심히 + 잘) * 기회 • 행복은 양보다 빈도 • 매일 매일이 즐거워야 • 내가 매일 하는 일(과정)을 좋아해야 행복하기 위해 12
- 13. 행복 • 크리스마스 트리 출력, 구구단 • 내가 만든 코드가 동작하는 즐거움 • “그게 재미있어요?” • 피드백(게임, 도박) • 새로운 것을 공부, 경험, 성장하는 즐거움 • “왜 이면지를 공부해요?” 왜 개발이 재미있나 ? 13
- 14. 행복 • 회사와 구성원들에게 선한 영향력 행사 • 문제 해결을 통한 기여의 즐거움(AOP, Lex / Yacc, Agora) • 개발 조직과 구성원 성장에 기여(도파민) • 업무 수행을 통해 쌓은 지식과 경험의 공유를 통한 선한 영향력 행사 • 주변에 좋은 사람이 많은 것 개발자로서의 여정 & 즐거움 14
- 15. 성장 15
- 16. 성장 • 매슬로의 욕구 단계설 • 결핍 욕구 • 한 번 충족되면 더는 동기로서 작용하지 않음 • 더 강한 자극 필요 • 비교 / 집착 - 성적, 급여 • 성장 욕구 • 충족이 될수록 그 욕구가 더욱 증대 왜 성장해야 하나 ? 16
- 17. 성장 • 하는 일을 좋아하려면 • 잘 해야 함 • 어제보다 잘하면 일과 삶이 즐거워짐 • 잘하면 • 하고 싶은 일을 할 가능성 높아짐 • 부산물이 생기기도 • 공학, 장인 정신 • 학교에서 배운 지식으로 부족 • 지속해서 지식과 경험을 통해 성장해야 왜 성장해야 하나 ? 17
- 18. 성장 • 역량: 성장의 목표 • 하드 스킬 • 소프트 스킬 • 업무에 기여하며 쌓은 지식과 경험 • RDD 금지 • 균형이 중요(기술, 비즈니스) • “당신이 그것이 필요하다는 것을 모른다고 해도, 우리는 당신에게 필요한 것을 제공하겠다” • 비즈니스 이유만으로 결정된 납기와 기능의 범위는 팀의 무결성(Integrity)를 유지하지 못함 어떤 역량을 쌓아야 하나 18
- 19. 성장 • 계획 • “계획 → 실행 → 추적 → 보정”의 루프 • 악천후: 잘 못된 방향으로 • 맑은 날: 바른 방향으로 • 실행이 완료되었을 때 완성 북극성 19
- 20. 학습 20
- 21. 학습 • 지속적으로 변화하는 기술 • 지속적으로 새로운 기술이 나옴 • 심지어 오래된 기술도 변화함 • SW Eng. • 89년 IBM PC • 95년 WWW • 99년 Client / Server Unix • 2000년대 Web Programming • 2007년 1월 iPhone (2009년 11월) • 2017~ VUCA, 2023 ChatGPT SW 개발 업의 속성 21
- 22. 학습 • 각종 기술의 생명주기 • MS-DOS, OS2, Windows, Solaris, HP-UX, IBM-AIX, NextStep, Linux, MacOS • Basic, Cobol, Fortran, Pascal, Assembly, C, C++, Pro*C, Power Builder, Delphi, Java, Scala, Kotlin, Swift, Javascript • Internet, Client / Server, WWW, Mobile, NoSql, BigData, Deep Learning, Cloud, SOA, SOAP, MSA • Tcp/Ip, Archie, Gopher, Usenet • Oracle, MySql, PostgreSQL, MongoDB, Memcached, Redis, Cassandra, CouchDB, … • IE, RUP, UML, CBD, Agile … • Layered, Hexagonal, Vertical Slicing SW 개발업의 속성 22
- 23. 학습 • “Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning”, Modern Software Engineering • 스스로 새로운 것을 배울 수 있는 역량을 키우는 학습을 해야 • 유명 강의: 상위 20~30% 타겟. 80% 정도의 지식 • 당장은 쓸모 없는 미적분 무엇을 공부해야 하나 23
- 24. 학습 • 지식 배가 곡선 • 지금 무엇을 알고 있나 ? • 얼마나 잘 배울 수 있나 ? 무엇을 공부해야 하나 https://www.learningguild.com/articles/2468/marc-my-words-the-coming-knowledge-tsunami/ 24
- 25. 학습 • RSS, News Letter, SNS, Youtube 강연 • Feedly, Pocket, DEVONthink • 제목만 / 소개까지 / 전체 / 따라해 보기 / 책 • 자신 만의 루틴 • 근시일 내 할 일에 깊게 투자 • 망각, 변화 루틴 25
- 26. 학습 • 특정 기술에 대한 서적 • 업무를 위해 Fw, 언어, SW 사용법 등을 급하게 알아야 할 때 • 당장의 업무에 유용, 가치는 오래가지 않음 • ex. Java, Hbemae, Node.Js, Cloure • 특정 개념에 대한 서적 • 커리어를 진전시킬 때 필요한 기초를 쌓을 수 있는 책 • 새로운 개념, 패러다임, 실행 관례 등 • 당장 활용하기 어렵고, 제대로 이해하고 습득하는데 긴 시간이 필요함 • 특정 기술을 익히는 것에 비해 훨씬 힘듦 • ex. DDD, OOP, Functional Programming, NoSQL, DB 모델링 등 학습 방법 26
- 27. 학습 • 행동 양식에 대한 서적 • 효율적으로 팀에서 일할 수 있게 안내하거나 일반적인 상황에서 더 나은 프로페셔널이 될 수 있도록 조언 • 코드와 관련 없는 나머지 것들에 대해서 어떻게 다뤄야 하는지 배워야 • 개발과 관련된 인간적 측면, 프로페셔널리즘 등을 다루는 책 • ex. 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영 등 • 혁명적 서적(또는 고전) • 일하는 방식이나 개인의 가치관을 바꾸는 책 • 실용주의 프로그래머, The Mythical Man-Month, Design Pattern(GoF), TDD(Kent Beck), Extreme Programming, Clean Coder, Software Crafimanship(피트 맥브린), Refactoring 학습 방법 27
- 28. 학습 • 일, 놀이, 수련의 구분 • 같은 코드를 정해진 시간 동안 할 수 있는 데까지 매일 리팩토링 해보기 • 같은 장난감 문제를 여러 번 풀기 • 고수와 하수를 가르는 가장 효과적인 인자는 의도적 수련의 양 • 업무만 열심히 해서는 고수가 될 수 없음 의도적 수련 28
- 29. 학습 • Shadow Coding • 상황을 정해 놓고 만족스러운 답을 추구 • 1만 시간의 법칙, 의도적 수련 • 실전 태권도 • 아는 것, 할 수 있는 것, 하는 것 • https://bit.ly/3usVOuX • 일과 후 책 Study ??? • 토이 프로젝트 • Study vs 학습(學習) 의도적 수련 29
- 30. 학습 • 연습은 연습장에서 • 부분 동작 → 느리게 연속 동작 → 실전 • 경기장에선 경기에 집중 의도적 수련 30
- 31. 학습 • 쉬운 문제로 • 한번 푼 문제를 TDD로 풀면서 TDD를 익히는 방법 어려운 기술을 배우는 방법 31
- 32. 학습 • "if it hurts, do it more often”, Continuous Delivery 어려운 기술을 배우는 방법 32
- 33. 학습 • 유의사항: 계단 성장 - 고통의 계곡 어려운 기술을 배우는 방법 33
- 34. 학습 • Chance Meeting의 중요성 • Why I Quit a $450k Engineering Job at Netflix • 급여 + 배움 → 급여 • 훌륭한 동료와 협업 • 복붙: MSA, AB Test, 메일 연동 등 재택 vs 대면 https://medium.com/@_michaellin/why-i-quit-a-450k-engineering-job-at-netflix-874454397885 34
- 36. 동기부여 • How do you inspire your team to adopt … ? • 좌절 준비 • 자신만 제어 가능(힘듦). 타인은 제어 불가 • 영감은 부산물 • 모범이 되라 - “나를 보고 따라하고 싶어야” • 단축키, 툴, 테마 등에서 시작 어떻게 하면 타인에게 영감을 불어 넣을 수 있나 ? ȩˑˑʩˁ㍙㍸㍸̫̫̫㍗̸ʃ˦ˑ˦ǂǧ㍗Njʃɭ㍸̫ƞˑNjȩ㍞̦㚋ƞɋʩƞ㋎)±±ʩˑȗ 36
- 37. 동기부여 • 회사 / 업무를 위한 결정 vs 개발자의 경력을 위한 결정 • 예. 리텐션 • 다양한 신기술을 도입한 레거시 운영툴 • 과한 기술 도입(REST vs ETL) • 떠날까 봐 승인 → 경력 추가 → 이직 → 운영의 어려움 동기 부여를 위해 하지 말아야 할 결정을 ... ȩˑˑʩˁ㍙㍸㍸̫̫̫㍗̸ʃ˦ˑ˦ǂǧ㍗Njʃɭ㍸̫ƞˑNjȩ㍞̦㚋ƞɋʩƞ㋎)±±ʩˑȗ 37
- 38. 동기부여 • 외적동기 부여 • 매슬로의 욕구단계설에서 처럼 지속 가능성이 없음 • 원래 천만원 오르는 것 아냐 ? • 내적동기 부여가 필요 - 스스로 하는 것 • 잘한다고 여기는 사람을 만나보고 그가 어떻게 생활하나를 보라 • 그처럼 되고 싶은가 ? 그럼 그는 어떤 노력을 했는지 살펴보라 • 커피챗 등을 요청해 보라. 찾아보고, 찾아가라 • 훌륭한 개발자이면서 집필 등 공유 활동을 많이 하는 • 그가 얼마나 노력하는지 알아보고 부러워하라 • 그 노력없이 그렇게 되고자 하는 것은 단순한 욕심임 동기 부여의 지속 가능성 38
- 39. 동기부여 • 나의 비전을 누군가가 만들어 준 적은 없음 • 어떤 상황이여도 나는 잘 되어야 함 • 그러니 내가 스스로 동기부여를 해야 함 • 잘하는 사람을 보면 잘하고 싶어짐 • 짝코딩, 코드리뷰 등 공유가 늘면 성장, 공유에 대한 열정이 생김 • 잘하는 사람을 찾아보는 노력 필요 • 내 마음대로 못하는 것 = 부산물 • 남에게 동기부여 • 내 평가, 보상, 연봉 누가 동기부여를 해 주나 ? 39
- 40. 일 잘하는 개발자 / 개발 리더 40
- 41. 일 잘하는 개발자 / 개발 리더 • 신뢰할 수 있는 • “아”라고 하면 “아” • 누가 검증하지 않아도 되는 • 구현, 의견 등 • 요청하지 않아도 필요하면 • 공유 / 문의 • 위임 / 에스컬레이션 하는 • 모범이 되는 • 구성원들이 보고 배울게 있고, 따라하고 싶어지는 먹고 떨어지는 41
- 42. 일 잘하는 개발자 / 개발 리더 • 특정 행동이나 특정 기술을 채택하도록 하려면 모범이 되어야 • 기술을 마스터, 지각하지 말라, 업무에 기여하라, 긍정적으로 임해라, 사람들을 잘 대하라 • 기술적 훈련(Technical Discipline)에 대해 언급하려면 고도로 숙달되어야 • 코딩을 할 때 사람들이 경악을 하도록 해라 • 도구(기술) 잘 사용, 개발을 잘하는, 공유를 잘하는 • 당신이 엄청난 모습을 보여주면 • 구성원들도 잘 하고 싶을 것 • “코드리뷰를 통해 잘하는 다른 팀 개발자들을 보게 되니 잘하고 싶어지더라” 따라 하고 싶은 개발자 42
- 43. 일 잘하는 개발자 / 개발 리더 • 일이 발생한 후에 공유 • 놀람 → 화 • 사전에 이슈가 될 만한 일을 공유 • 대안도 미리 공유 • 이슈가 발생해도 안정적으로 대응 • 예. 서비스 오픈 스케쥴 놀래키지 않아야 43
- 44. 일 잘하는 개발자 / 개발 리더 • 복잡한 문제 • → 작은 문제로 분리 • 일반적은 수준의 기술로 처리할 수 있도록 • 예측 가능성 ↑, 실패의 영향 ↓ • [본래 문제를 그대로 해결 - 견습공] << [작은 문제로 나눠서 해결 + 통합 - 장인] • 모듈화 • 추정 • 0.5 ~ 2일 수준의 타스크로 나눠야 복잡한 일을 잘하기 44
- 45. 일 잘하는 개발자 / 개발 리더 • 잘하는 것, 빠르게 하는 것이 중요한게 아님 • 잘하는 것처럼 보이는 것, 빠르게 하는 것처럼 보이는 것이 중요 • 일의 크기, 순서만 바꿔도 빨라 보이고, 잘하는 것처럼 보임 • 작게 나눠서 자주 피드백 • 롤백 비용이 낮음(혁신적 시도의 90%) • 어느 수준에서 배포를 해도 충분할 수도 • WIP 제한 • 주간업무 공유의 목적은 중요한 일이 잘되고 있는가 • 중요한 일이 먼저 완료되도록(10개 70%, 10개 중 5개 배포) • 아사(餓死) 기반 프로세스 빠르게 잘하기 45 [중요한 일 먼저하기](https://brunch.co.kr/@cleancode/73)
- 46. 일 잘하는 개발자 / 개발 리더 • 성능, 최적화, 추상화를 고려한 개발 - Premature Optimization • 제대로 동작하지 않아도 된다면… • 일단 동작만 하도록 • Duct Tape 프로그래밍(스택오버플로우, GPT) • 문제 이해, 예상치 못한 이슈 조기 파악 • 테스트가 있다면 지속적 개선 가능 • 인수조건을 가지고 • 단계: 가독성 → 유지보수성 → 중복 제거 → 악취 제거 → 디자인 패턴 적용 등 Make It Work, Make It Wright, Make It Fast 46 https://wiki.c2.com/?PrematureOptimization
- 47. 일 잘하는 개발자 / 개발 리더 • VUCA / 애자일 • 불확실성의 시대, 다양성이 중요 • 미 서부 스타트업 발전 • 옳고 그름이 아니라 일이 되게 만드는 것이 중요 • 네가 할 것이 아니면 부족해도 인정해라 • 개발자에게 가장 필요한 역량 ? • 블라인드 코딩 테스트 만점 • 어떤 개발자와 일하고 싶은가 ? 협업 47
- 48. 일 잘하는 개발자 / 개발 리더 • 국민소득 3만불 → 임금 상승 → 혁신이 필요 • 규모와 복잡성 ↑ • 똑똑한 소수가 전체를 감당하는 것 불가(소품종 대량 생산) • 구성원의 다양성과 전문성을 존중해야(다품종 소량 생산) • 누가 맞는지가 중요한 세상이 아님 • 어떻게 하면 잘할지가 중요 • 일이 되는 방향으로 일하는게 중요한 세상 옳고 그름 vs 혁신 48
- 49. 일 잘하는 개발자 / 개발 리더 • 혁신을 위한 도전은 90%가 실패 • 하지만 500% 이상의 성장도 가능 • 작게, 그리고 실패할 만한 도전을 초기에 • 어차피 할 실패라면 최대한 빨리(fail fast) • 작게, 반복적, 점진적 옳고 그름 vs 혁신 49
- 50. 일 잘하는 개발자 / 개발 리더 • 가동률 100%면 안됨 • 자신의 업무, CS • 대기 발생 → 팀의 속도 ↓ • 초기 방향성 수립 • 생명주기 후반의 변경 비용 ↓ • 초안 리뷰 → 코드리뷰 우리팀 에이스는 무엇을 하나 ? 50
- 51. 일 잘하는 개발자 / 개발 리더 • 협업(짝 프로그래밍) • 온보딩(위키 ?) • 에이스의 속도 ↓ • But 협업하는 개발자들는 남은 인생에 걸쳐 속도 ↑ • 팀의 속도 ↑ • 몹프로그래밍 • 팀장님. 팀원들의 역량을 빨리 끌어 올리더라 • 여러 사람들이 성과를 낼 수 있게 도와야 우리팀 에이스는 무엇을 하나 ? 51
- 52. 일 잘하는 개발자 / 개발 리더 • 나, 우리팀의 일 ? Vs 우리 회사의 일(KPI) • 2단계 높은 직책에서 의사 결정 성과 vs 기여 52 㑁᳞ℾೢ፶᪪ᆊ⅖ᬯ۳῎ᾲྐྵڊῪ⾆ખₒ㍞㐰 લᎪᏇ࠶ٵൖᏆⅲ⩪ቚᮊ⼂Ⲷ፺ⅺ℺⪦⽖ખ⅖⚞⽗
- 53. 일 잘하는 개발자 / 개발 리더 • 중요도, 긴급성에 따른 수단 사용(대면, 전화, 메신저, 메일 등) • 최대한 인터럽트가 적도록 • 응답은 신속 But 해결은 시간을 가지고(수신 → 바로 회신(응답) → 해결책 회신) • 모든 것이 소비자 중심(생산자 X): 쓰레드 요약 • 맥락으로 인한 속도 차에 유의 • 아무리 글로 잘 적어도 말이 더 우월 • “다 이유가 있겠죠” • 문제를 해결하기 보다 (납득) 기존 시스템 이해가 먼저 • 이후 해결은 함께 • 그렇지 않으면 신뢰 X 의사 소통(Communication) 53
- 54. 일 잘하는 개발자 / 개발 리더 • 대개 문제를 만나면 사람들은 바로 해결 모드로 뛰어듬 • 야구 배트와 공이 합쳐서 1,100원. 배트는 공보다 1,000원이 비쌈. 공은 얼마인가 ? • 사람들은 문제를 해결하고 싶어함 • 우연에 의한 프로그래밍(Programming by Coincidence)” • 문제를 해결하기 위해 이전에 유사한 문제에 효과가 있었던 주술을 시도 • 서비스 리스타트, 컴퓨터 리부팅, 권한을 추가하여 툴 실행, 코드의 작은 변경, 잘 못 이해된 루틴 호 출 등 과학적 접근법 54
- 55. 일 잘하는 개발자 / 개발 리더 • 왜 문제가 발생했나를 이해하는 것 • 문제를 만났을 때 제일 먼저 할 일 • 진짜 아무런 아이디어가 없다면 도움을 요청해야 • 그렇지 않고 문제에 대한 단서가 있다면 과학적 접근법을 취하라 과학적 접근법 55
- 56. 일 잘하는 개발자 / 개발 리더 • 가설(Hypothesize)을 세워서 예측(Prediction) • 코드 실행 전 결과 예측, 코드 수정 전 무엇이 잘못되었는지 정확히 설명 • 실험(Experiment) • 실험 결과의 예측을 비교 • 문제를 이해할 때까지 이를 반복 과학적 접근법 56
- 57. 일 잘하는 개발자 / 개발 리더 • 반증가능한 가정(falsifiable hypothesis)” 수립으로 시작 • 컴퓨터를 재부팅하면 문제가 사라진다.” • ”이 함수를 호출하면 반환값이 42가 될 것이다.” • 등 단순한 예측 • “우연에 의한 프로그래밍”과의 차이점 • 목표: 문제를 해결하는 것 → 목표는 문제를 이해하는 것 • ex. 실패할 것이라는 가설이 있는 단위 테스트 과학적 접근법 57
- 58. 일 잘하는 개발자 / 개발 리더 • 머리가 좋아서 • 기억력에 의존 • 생각을 못하게 됨 • 추적 가능성이 중요 • 보잉: 30년 생산, 30년 사용 • github, jira, wiki • 작성 → 검색 확인 • 빈도가 낮을 수록 상세히(동영상 등) 기록해야 사람/기억력에 의존하지 말아야 58
- 59. 일 잘하는 개발자 / 개발 리더 • 장애 대응 • 메신저 로그 • 위키 정리 • 전지전능한 운영툴 • 사람에 의존하고, 조심해서 사용해야만 함 • SW가 방지해 줘야 • 자동화가 어려운 업무 • 명령어 → 스크립트 • 체크리스트(복명복창) 사람/기억력에 의존하지 말아야 59
- 60. 일 잘하는 개발자 / 개발 리더 • 일에 사람을 할당 or 사람에 일을 할당 • n가지 일에 n명 할당 • 공유가 안됨 • 대기 발생. 병목 • 우리가 왜 같은 팀인가 ? 일을 할당하는 방법 60
- 61. 일 잘하는 개발자 / 개발 리더 • 일에 사람을 할당 or 사람에 일을 할당 일을 할당하는 방법 61 㐯⳾ખఞᬚ⽞ᆖ㍞㐰 㑁∂ڮ᪪ᘖₒ㍗ ೢؗⅲ₮ೢೢ⽲ᬚ⛎લಒᏙⅲↆᾲὺ⋞㐰㍘ ᅺᏆ㠭⾇᪪㠭
- 62. 일 잘하는 개발자 / 개발 리더 • 일에 사람을 할당 or 사람에 일을 할당 • n명에게 일을 할당 • n개를 한번에 하나씩(중요한 일 먼저) • 지식 공유: 팀에 전문성/지식 축적 • 팀웤: 인간은 사회적 동물 • 몰입의 즐거움 • 대기 제거 일을 할당하는 방법 62
- 63. 일 잘하는 개발자 / 개발 리더 • 신입 면접 • 포트폴리오, 프로젝트 / 전공 선택 • 영어 시간에 수학 공부하고, 수학 시간에 국어 공부하고… • 지금 내게 주어진 기회(강연, 수업 등)가 다시 올 수 있나 ? • 다시 올 수 없다면 거기에 집중해야 지금 해야 할 것에 집중하라 63
- 64. 일 잘하는 개발자 / 개발 리더 • 조직 / 직책자 변경 • 구성원들은 혼란스러워 함 • …안 하려고 했는데…어쩌다 보니… • 혼란 증폭 • 자신감과 준비되어 있음을 보여야 • 그래 보여야(빨라 보여야) • 발령과 동시에 메일로 인사 • 타운홀. 자신의 이력, 비전 등에 대한 소개 • TO-BE 실행보다 AS-IS 이해 먼저(과학적 접근법) 새로운 직책을 맡았을 때 64
- 65. 일 잘하는 개발자 / 개발 리더 • 3가지 • 현재의 일을 잘하기 위해 필요한 지원 • 행복을 위해 필요한 지원 • 경력 계발을 위해 필요한 지원 • 구성원이 리더를 활용해서 성과를 창출할 수 있도록 1on1 65
- 66. QA • 패캠 강의 • The RED : 백발의 개발자를 꿈꾸며 : 코드리뷰, 레거시와 TDD • https://fastcampus.co.kr/dev_red_bcr • 개발자는 왜 성장해야 하나 ? / 코드리뷰 체크 리스트 / 레거시 코드 다루기 / 리팩터링 / TDD • sudo : CTO's Tech Talk 2022 컨퍼런스 • Java/Spring 기반 리팩토링 Co-Learning for 클린코드 • #TDD #리팩토링 #객체지향프로그래밍 • https://fastcampus.co.kr/dev_innercircle_bms • https://www.youtube.com/user/codetemplate/videos • https://linktr.ee/codetemplate 66