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

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

 

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

 

반응형

토요일이고 해서, 내가 사용하는 윈도우용 텍스트 에디터나 적어볼까 한다.

 

1.Visual Studio

c++ 코드를 작성할 때에는 VS만한 편집기가 없다. 직장인이지만, 학생인 관계로. :) Jetbrains의 Resharper for C++ 플러그인을 집 컴퓨터에서는 설치해 사용한다. IntelliSense 기능도 좋고, Refactoring 기능도 좋다. 회사에서는 관리자인 관계로 그냥 맨 VS를 사용하지만, 팀원들에게는 VisualAssistX를 설치해서 사용하도록 지원하고 있다.

 

2.Sublime Text

일반 텍스트 파일,JSON 파일과 파이썬 코드를 작성할 때 주로 사용한다. JSON은 Pretifier 플러그인이 워낙 잘 되어 있어서 애용하고 있다. 줄단위 편집 등이 편리하고, 파이썬 코드를 Ctrl=B를 통해 간단히 실행해 볼 수 있기 때문에 파이썬 스크립팅시에는 서브라임을 사용한다.

 

3.NotePad++

여러 파일(디렉터리 검색) 찾기를 한 결과를 별도 패널에서 쉽게 검색하면서 볼 수 있기 때문에 그 용도로 주로 사용한다. 예전에는 매크로 기능을 잘 사용했는데, 요즘은 매크로를 사용할 일이 별로 없다.

 

4.VisualStudio Code

그냥 가벼운 편집기를 사용해야 할 경우 사용한다. 최근에는 몇몇 Extension이 마음에 들어서 사용하고 있다. 주로 mermaid나 PlantUML을 작성할 때, Markdown 문서를 이용할 때 Preview 기능을 제공해 주기 때문에 유용하게 사용할 수 있다.

 

5.HxD

아주 가끔 이진 파일을 살펴보고 싶을 때 사용하는데, 요즘은 점점 빈도가 낮아진다.

 

6.VI

WSL에서 편집할 때는 아무래도 VI가 편하다. 물론 WSL일 경우에는 윈도우에서 편집기를 실행한 다음, WSL의 파일들에도 접근할 수 있지만, 그래도 리눅스 환경에서는 리눅스용 도구가 편하다.

 

대충 이정도만 사용하고,  다른 개발용에는 주로 JetBrains에서 나온 개발 도구를 사용하게 된다. 며칠전 Fleet이라는 새로운 텍스트 편집기를 내놓긴 했던데, 개발환경이 아닌 일반 가벼운 텍스트파일 편집기가 JVM 위에서 동작해야 하는가에 대해 부정적이라 설치도 안해봤다. 

 

반응형

+ Recent posts