어제 구름 Commit에서 라쿤님이  <개발자의 성장>에 대해 나눠준 이야기를 정리해 보자.

지극히 개인적으로 이해한 내용이므로 라쿤님의 의견과는 다를 수 있다. 라쿤님 발표내용은 나중에 공유되면 그걸 참고하자. 아래는 발표를 들으면서 내가 느낀 점들을 기록한 것이다. 라쿤님이 이야기한 내용이 아닌 내 생각이 섞여있다.

 

  • 업무
    • 우선순위 기준 잘 세우기: 아이젠하워 매트릭스 활용
      • 현실에선 업무를 잘 나눠서 분할 관리하자.(결국 Divide&Conqure 전법이 현실에서 가장 잘 먹힌다.)
    • 업무는 축구처럼
      • Shoot을 넣든(목표를 완료하든지)
      • Pass를 하든(빨리 자신이 할 역할 하고 다음 담당자에게 전달하든지)
      • 이때 각 구성원들은 목표(골을 넣어야 한다)를 인식하고, 모든 액션이 목표로 Align되어야 한다.... 백패스하다가 골 먹으면 그건 안하는 것만 못한 패스. 의도적인 백패스가 아니라 무조건 패스로 인한 실패는 그냥 실패. 전략과 방향성을 가지고 시도하다가 골 먹는 것은 배울 것이 있는 실패. 성공한 실패와 그냥 실패의 차이는 교훈이 있는가 없는가의 차이.
    • 업무: 계획-> 추진-> 조정
      • 다른 멤버들에게 의존성을 주는 작업을 빨리 처리 하자. 하지만 내 일은.. 조정은 Feedback으로 들린다. Feedback(되먹임)으로 다음 액션(Plan)에 영향을 줄 수 있어야 변화가 생긴다. 
    • Alignment
      • 자기주도성은 내가 하고 싶은 일을 할거야가 아님.
      • 회사의 중단기 목표와 지속적으로 Align 맞출 것. 매니저들과 계속 communication. 이 내용은 최근 읽고 있는 <스태프 엔지니어>에서도 계속 나오는 이야기.의외로 현실에선 어려운 부분. 매니저와의 성향 차이, 바쁜 일정 등등이 이유가 되겠지만, 커뮤니케이션 안할 경우 오는 피해는 오롯이 자신의 몫이므로 적극적으로 시도해야 함. 현실은 힘들다 ㅠㅠ. 
  • 역량
    • 호기심 자극: 뉴스레터, 컨퍼런스, 커뮤니티 활용
    • 호기심 채워가기: 커뮤니티, 스터디, 세미나, 온라인 강좌, 사이드 프로젝트
      • 사이드 프로젝트: 구축해본 서비스를 넘어 운영해본 서비스까지 확장. 이걸 현업에서 경험하는 것은 운이지만, 사이드로 진행하면 내가 해볼 수 있다!
    • 협업: 응답, 기록, 동료의식
  • Done is better than perfect
    • 대충과 빨리의 차이는 중요하지 않은 일을 쳐 내는 것. 
    • 절대 저 말이 대충하자는 의미가 아님. 돈이 완벽보다 좋다
  • 성장을 넘어 성숙으로
    • 단언하지 않고(시니어가 단정하지 않고 주니어들을 질문을 통해 올바른(?) 길로 이끈 이야기.. 나같이 성질 더러운 사람은;; 
    • 우월감없이 (독성 어투 없이, 직군, 직무의 차별 없이..)
    • 유행만 쫓지 않기

 

반응형
너무 좋은 글이어서 요약과 함께 공유.
20년동안 소프트웨어로 근무한 가민사의 스탭 엔지니어분이 자신의 경험을 적었다. 100% 공감..(아 나는 왜 이런 글을 못적는것인가...) 하지만 내가 만날때마다 동료들에게 하던 이야기들이 정리되어 있어 한편으로는 흐뭇하다. 나만 그렇게 생각하는게 아니었어..
 
1. 더 많은 소프트웨어 엔지니어링 관련 문서 읽기 - 뉴미디어 말고 차분히 정제된 좋은 책 읽기.
2. 문학이나 다른 비 기술서적 많이 읽기 - 사람에 대해 이해하기
3. 맥락이 왕 - 케바케
4. 모든 것이 절충: 트레이드오프를 인식하고 프로젝트 목표에 가장 잘 맞는 최상의 솔루션 제공. 용기의 미덕은 비겁함과 무모함 사이의 중간
5. 소프트웨어 공학은 실용 인식론 - 기계가 이해하는 코드 작성이 아닌, 인간이 이해하는 코드 작성. 체계적이고 의미있는 방식으로 지식을 조직화하기
6. 소프트웨어 공학은 프로그래밍이 아님: 지식에 기반한 결정, 구조화된 접근 방식, 경험적 방법, 반복을 통한 지식 향상 . 실제 문제를 인식. 고객이 진정으로 원하는 것과 고객이 원한다고 가정하는 것을 구현하는 것의 차이
7. 일상 업무에 지식과 추론을 사용: 정보에 입각한 결정/추론
8. 설계 의도파악 - 모든 결정은 어떤 일련의 의미를 가지며, 결정할때 이런 의미를 잘 이해하자.
9. 결정 문서화 - 결정이 내려진 맥락, 고려된 대안, 다양한 대안 간의 절충 분석 및 결정의 영향을 문서화
10. 신입에게 기술 세부사항을 설명할 방법 찾기 - 중요하지 않은 세부사항은 추상화하고 중요한 측면에 집중하기
11. 다른 사람이 이해할 수 있는 시스템 설계 - 우리는 팀으로 일한다.
12. 테스트는 필수 - 우리의 가설이 틀렸다고 가정하고, 가설을 테스트하려는 노력을 기울여야 한다.
13. 코드 작성보다 문제해결에 집중하자 -
14. 알고리즘과 자료구조 학습: 충분한 사전 지식을 갖춰야 더 의사소통을 잘 할 수 있음
15. 작은 것부터 혁신하자 - 작은 프로세스 개선부터 더 큰 혁신을 끌어가자. 문화 바꾸기도 동일
16.지행일치, 행지 일치 - 엔지니어링이란 경험적인 것. 배운 것을 적용하고, 적용하면서 배우고.. 좋은 학습 방법 개발 및 건전한 경험 프로세스 적용.
17. 실수로 부터 제대로하는 법을 배우기: 실수는 발전의 열쇠. 실수의 영향력을 통제해야 함. 완전히 피할 수 없음. 주요 위험을 평가하고 추적해야 함. 실수를 통해 우리는 더 빨리 배우는 경향이 있음. 가설의 오류 가능성을 통해 새로운 것을 배워 가설 모델과 현상에 대한 이해도를 향상시킴
18. 나 자신을 포함한 모든 것에 의심을 품자. - 모든 명제가 거짓일 수 있다고 가정.
19. 자신의 편견도 관리해야 하는 문제 - 자신이 가진 편향성을 인정하자.
20. 끝없는 도전 - 배우고, 실험하고, 우리 자신을 향상시킨다.
 
 
 

Lessons Learned After 20 Years of Software Engineering

It’s good to sit back and reflect from time to time. Lucian Radu Teodorescu does just that and reports back. 15th of August 2002 – the date I started working as a professional software developer. I was still 18 at that time. I have been in this profess

accu.org

 

반응형

'2. 개발 > 2.0 개발 잡설' 카테고리의 다른 글

내가 사용하는 텍스트 에디터  (0) 2022.10.15
벌레를 어떻게 잡을 것인가?  (0) 2022.08.08
하이럼(hyrum)의 법칙  (0) 2022.07.04
WSL 정리 #1  (0) 2022.04.05
드림헤븐 JD  (0) 2022.03.05

+ Recent posts