글이나 요구사항을 작성할때는

- figma 에 스티커 지저분하게 나열하기 보단

- 컨플루언스에 내 생각을 정리하기가 선호되고

- 지라에 "유저로서 에션을 하면 이렇게되길 원함" 보다는

- 손으로 화이트보드에 생각을 정리하는게 선호가되고


솔루션을 작성하거나 평가할때는

- pragmatism 이더 선호가되고

- AWS 나온 새로운 서비스/기술은 다시 보게되고

- 해결되지 않은 문제는 무조건 검색해서 나오는 솔루션으로 건너뛰기 보단

- 우리가 가지고있는 현제 솔루션과 해결하려는 문제를 다시보게되고. AWS 에 문의하면 가끔 NDA 로 "CloudFront 에 이런 기능 이제곧 나옵니다" 알려주기도하고


문제가 주어지면

- 그 문제를 일단 화이트보딩으로 해결하려는 문제를 일단 다시 생각해보고

- 무조건 "이 라이브러리로 해결 가능" 보다는

- 문제의 초석으로 부터 왜 이걸 해야되는지 부터 의심을 갖게됨

- 가끔은 문제 자채가 PM 과의 소통문제 / 그사람이 문제 자채를 이해를 못했거나 / 현존하는 프로세스에서 missed 된 문제일수도있음

- 무조건 코드로 달려드는 사람들에게 이런 문제는 그냥 "이 aws 서비스 써서 해결하면 됨" 으로 나오는데 결국 문제 초석부터 이해를 못한 행위가 80%임