PIGNOSE 정신

개발자로서 / 전문가로서의 자세를 말합니다.

주의사항

  1. 이 글은 피그노즈에서 이야기하는 최소한의 윤리의식입니다.
  2. 여러분은 이 글에 대해서 평가하고 고쳐나가실 수 있습니다 그리고 그것을 권장합니다.
  3. 다만, 부정의 경우 1. 커뮤니케이션 / j를 참고하시고 의견을 기재합니다.
  4. 이것은 현실과 이상의 경계에 있습니다 따라서 이것을 참고하여 변형하시는 것을 허락합니다.
  5. 개발자 스코프에 초첨을 가졌으나 사실 다른 분야에도 그대로 적용이 가능합니다.

1. 커뮤니케이션

  • a) 나의 상식이 상식이 아님을 바탕으로 커뮤니케이션을 한다.
  • b) 당신이 답을 쥐고있지 않을수도 있음에 항상 유념하라.
  • c) 상대는 당신의 경험을 모른다, 따라서 배경 설명을 명확히 하라.
  • d) 주관적 근거를 객관화 하지 않도록 한다.
  • e) 본인의 논리가 올바르지 않다면 그 즉시 정정하고 다음 얘기를 진행한다.
  • f) 어떤 커뮤니케이션이건 합리에 근거하고 합리로 끝나도록 한다.
  • g) 상대가 합리를 납득하지 못했을 때는 근거를 제시하라.
  • h) 균형을 유지하라, 지지적 피드백과 교정적 피드백을 적절히 분배하라.
  • i) 내가 상대를 납득하지 못했을 때는 근거를 요구하라.
  • j) 어떤 논리에 대한 비판일 필요한 경우 반드시 대안을 제시하라.
  • k) 합리적 비판에 감정을 섞지 말아야 한다.
  • l) 비생산적 대화로 방향이 바뀔 시 그 즉시 본론으로 회귀하라.
  • m) 커뮤니케이션의 결론이 나오면 그 결론을 요약하여 정리한다.
  • n) 미움 받을 용기를 가져라.
  • o) "현실" "한국은" 이라는 단어 사용에 유의하라 그것이 사실인지부터 확인하라.
  • p) "내가 젊을 때"라는 단어 사용에 유의하라 당신이 젊을때 상대랑 같을리 알 수 없으며, 상대 나이가 들었을 때 당신처럼 될지 알 수 없다.
  • q) 합리적 대화는 수평선 위에서 해야하는 것을 인지하라.

2. 개발

  • a) 당신은 한 분야의 전문가다, 그 분야에 대해서는 깊은 이해를 가지고 있어야 한다.
  • b) 항상 겸손해라, 당신이 아무리 많이 안들 그 위는 존재하는 법이다.
  • c) 개발 실력에 있어 나이는 무관하다는 사실을 인지하라.
  • d) "생산성"과 " 애자일" 단어 사용에 유의하라 그것은 "리사이클"과 "기술부채"를 배제한 것일 수도 있다.
  • e) 변화를 받아들여라 변화를 거부하기 시작한 순간 퇴보하기 시작한다.
  • f) 변화를 선택하여 받아들여라 설레발에 주의하라.
  • g) 내가 만들 개발 결과물을 믿지말아라, NIH에 주의하라.
  • h) 컴퓨터는 잘못이 없다, 잘못은 너가 한 것이다.
  • i) 스니펫을 복사하여 붙여넣지 말아라, 한글자 한글자 직접 보고 타이핑 하라.
  • j) 지금 당장 필요하지 않는 것을 코드상으로 구현하지 말라. (YAGNI, 오컴의 면도날).
  • k) 일정이 촉박하여 하드코딩 개발을 정당화하지 말라. 당신은 일정을 늘리기위해 노력을 하였는가?
  • l) 도그푸딩(dogfooding)하라.
  • m) TDD, BDD 적용을 항상 고려하라.
  • n) 3번이상 코드가 반복되면 코드를 추상화하라. (DRY, 코드 재사용)
  • o) 본인이 잘 모르는 기술에 대해서 무턱대고 설명하지 마라, 당신은 개발자이지 영업자가 아니다.
  • p) 본인의 코어타임을 관리하라, 업무시간보다 코어타임에 초첨을 맞춰야 한다.

3. 협업

  • a) 당신의 코드와 당신의 동료의 코드를 신뢰하지 말아라.
  • b) 사람을 신뢰하지 말아라, 사람보다는 기계가 정확하고 합리적이다.
  • c) 자신의 수명을 위해 코드는 형상관리 하도록 한다.
  • d) 코드리뷰는 앞으로 발생할 사고를 예방하기 위한 방파제이다.
  • e) 짝 프로그래밍을 고려하라, 시니어와 주니어를 같이 배치하라.
  • f) 기술 공유의 문화를 만들어라 그리고 변화를 받아들여라.
  • g) 작업은 워크플로우를 만들어 진행하라 그리고 그것또한 자동화하라.
  • h) 리팩토링은 좋은 것이 아니다, 애초에 리팩토링이 없도록 설계되어야 한다.
  • i) 절대 수퍼개발자가 되지 말아라.
  • j) 관리직에 오래 있던 직원은 기술적 결정에 관여하지 말아라.
  • k) CI/CD를 고려하라.
  • l) 문서화는 틈틈히 하라, 문서화를 안하는 것은 동료 개발자를 사지로 모는 것이다.
  • o) 스크럼 도입에는 신중해야 한다, 다시 한번 생각하라.

4. 기여

  • a) 당신이 본 하나하나의 아티클과 포스트는 누군가에게는 많은 검토와 공이 들어갔음을 인지하라.
  • b) 오픈소스에 문제가 발견되었을 경우 이슈를 리포트하라.
  • c) 오픈소스 이슈에 질문을 하기 전에 스택오버플로우 채널을 확인하라, 만약 있다면 그곳에 질문을 올려라.
  • d) 오픈소스 기여에 참여하라, 여러분의 기여는 또 누군가에게 커다란 도움이 된다.
  • e) 새로운 기술을 항상 검색으로 알아내면서 기술의 공유나 기여에 있어 퇴영적 태도를 취하지 말라.
  • h) 에코시스템과 커뮤니티에 참여하라.
  • f) 세미나와 밋업에 참여하라 그리고 그것을 전파하라.
  • g) 새로운 것을 알게되었다면 그리고 그것이 의미있다면 그것을 공유하라.
  • i) 지금 있는 것에 만족하지 말라, 지금 있는 것에서 더 발전하고자 하라.
  • j) 기여에 영리적 색을 최대한 없애라.
  • k) 남의 기여에 날선 비판은 삼가라, 적어도 그들은 자신의 시간을 기여에 투자하고 있다.