후반부의 “PR을 작은 단위로 유지하라”는 대체로 좋은 포인트 같아요. 다만 전반부의 “컨텍스트 스위치 코스트 때문에 다 외부와의 소통은 제쳐둔다”는 솔직히 공감되지 않네요. 개인적으로 저 또한 컨텍스트 스위치에 능하지 않은 사람이라 전 이걸 제 단점으로 인지하고 있는데요. 실제로 컨텍스트 스위치를 잘하는 동료들을 보면 집중해서 작업도 잘하고 그때 그때 인터럽트도 잘 해결하고 컴케면에서도 빠르게 응답해주는 경우가 많았습니다. 엔지니어의 업무 특성 상 컨텍스트 스위치 시 효율이 떨어질 수 있다는 맞지만 ‘그러니까 나는 종종 개인적으로 외부 요청 거의 차단하고 집중한다^^’는 협업 측면에서도 아닌 것 같아요. 1. 컨텍스트 스위치를 잘 하는 것도 능력이다. 2. 필요한 경우, 조직 차원에서 시스템적으로 집중할 수 있는 시간을 제공한다
시청해주셔서 감사합니다! 저도 말씀하시는 것처럼 "컨텍스트 스위치 코스트 때문에 다 외부와의 소통은 제쳐둔다"라는 애티튜드는 협업에 좋은 자세는 아니라고 생각합니다! 한결님도 항상 그러는 것은 아니시고요. 저는 "이런 극단적인 애티튜드를 갖을 때도 있다!" 라고 이해했습니다. 복잡하고 중요한 문제를 해결할때, 문제를 쪼개는 작업이 진행되는 초반 기간때만 소통을 좀 줄이고, 체크포인팅이 완성이 되서 복잡한 문제를 간단한 to-do list를 만들었다는 느낌이 들면 다시 팀원들을 위해 커뮤니케이션을 더 하시는 것 같습니다. 그리고 말씀하신 것처럼 이런 소통이 막히는 순간들이 필요하면 팀원들에게 이유와 예상되는 시간을 공유해야한다는 생각도 너무 공감합니다 :)
저도 스타트업에서 주니어지만 프론트엔드 1인으로 작업하는 입장에서, 큰 그림을 계속 보고 있으니 컨벤션은 개나줘버린 외주 코드, 케이스 제대로 고려 안하는 기획, 아토믹하지 않은 컴포넌트 남발하는 디자인으로 스트레스가 너무 많았는데 이 영상보고 같은 생각이 들었네요 감사합니다ㅠ
정말 좋은 영상감사합니다!!! 나는 왜 이렇게 개발속도가 느린걸까라고 한탄했었는데 영상을 보고 이유를 알게 됐어요. 머리로만 생각해서 코드를 치다보니 마지막엔 항상 처음에 생각했던 디테일을 놓치게되고, 그럼 수정을하면서 또 메인 흐름을 놓치고 그러면서 개발속도가 나지 않았던것 같아요. 클린코딩 책을 보면서 함수는 가능한 작은 단위로 나눠야 한다는걸 알고 있다 생각했는데 말씀해주신 걸 듣다보니까 제대로 이해하고 실무에 적용하고 있진 못했다는걸 깨달았어요. 앞으로는 기능 하나를 만들때도 어떻게 구현할지 단계별로 기록해놓고 순차적으로 만들면서 기능단위 체크포인팅을 만들 수 있게 해야겠습니다. 너무 좋은 인사이트 감사합니다!
몰로코만큼 큰회사는 딜레이가 가능할거같은데 개발자 한두명인 중소회사는 여기서 처리해달라 저기서 처리해달라 p2p로 난리치니깐 그 문제부터 빨리 처리해줘야할수밖에없음. 팀장한테 이거먼저하고 할게요했는데 안좋은표정짓는거보고 좀 놀랬음 회사사람들은 다 자기 일처리만 생각함 그게 문제임 난 정신과약먹고 많이 좋아졌음
아무래도 큰 회사일수록 어떤 업무 진행박식이 엔지니어들에게 더 효율적인지를 이해하고, 기다려주는 것 같습니다. 작은 회사들은 해야할 일들이 너무 많고 급박한 경우들이 많으니까요ㅠㅠ 조금 더 여유를 갖고, 각자의 입장을 이해해보면 좋을텐데, 그게 참 쉽지 않은 것 같습니다.
ㅋㅋㅋ 다들 역시 컨텍스트 스위칭이 고민이군요...ㅋㅋ, 저의 경우에는 TODO 리스트를 코드 주석에 적어 놓고, 중간에 다른걸 해야 한다면, 현 시점의 컨텍스트의 앞뒤를 주석에 달아 놓는 방식으로 하거나, 도식화를 해놓거나, 그래프로 해놓고 합니다. 그럼 좀 덜 소모적이더라고요. PR를 순서대로 해놓는 부분은 저도 좀 연습해야 겠네요. 알지만, 잘 안되는 ㅋㅋ
복잡한 문제를 해결해야 하는데, 팀워크도 그만큼 중요한 필드이기에 다들 제일 고민하는 부분이 아닌가 싶습니다ㅎㅎ 제시하신 방법도 너무 유용할 것 같습니다. 정말 급한 일이라 빨리 가야하는 일이라면, 간단하게 코드 주석에 정리라도 해놓고 간 것들이 나중에 큰 도움이 될 것 같네요!
PR 말씀 주시는게 커밋 단위가 아니라 PR 단위를 말씀하시는걸까요? 매시브한 PR에서 세부적으로 나누고 거기서 또 커밋을 또 세부적으로 나눠라.. 커밋은 최대한 잘게 작성하려 노력했는데 PR 자체가 하나의 일을 하는 데 너무 변경이 많거나 피쳐를 추가하는 경우에, 한 피쳐에 대한 뭉퉁 그려진 PR보다는 세부적인 PR을 모아 하나의 피쳐를 완성하라는 말씀이실까요?
확실한 답변드리기 위해서 한결님께 연락드려 봤습니다. ==== 답변 ==== 다양한 회사들이 있고, 회사들 마다 쓰는 리뷰 툴과, 버전 컨트롤이 달라서 정답은 없다고 생각합니다. 하지만, 일반적인 github을 사용한다 생각했을때, 저는 개인적으로 PR 단위로 쪼개줘야한다고 생각합니다. 리뷰를 부탁하는 사람, 리뷰를 하는 사람 다 빠른 시간안에, 확신을 갖고 움직일 수 있죠. 간단한 feature면 굳이 여러개의 pr을 사용할 필요는 없다고 생각하지만, 복잡한 feature라는 가정하에 하나의 예시를 제시하자면, 각 PR을 “[1/x][전체 목적][이 PR에 들어간 changes 요약]”으로 제목을 짓고, 마무리 PR은 [x/x]식으로 짓는게 하나의 방법이 될 수 도 있겠죠. 여기서 더 들어가서 “[1/x][전체 목적][세부 큰기능][이 PR에 들어간 changes 요약]” 같은 식으로 들어가도되고요. 이렇게 정리를 한다는건 나 보기도 쉽고 남보기도 쉽고, 결국엔 나중에 보는 overhead 가 줄어든다는게 큰 장점이라고 생각됩니다. 예를 들어 제가 pr 을 리뷰 해달라고 보냈는데 2일있다가 리뷰해서 돌아오면 제가 바꾼 내용 뭔지 기억 안나는경우가 꽤 생기죠. 사실 github에서 이런 어프로치는 좀 불편한 감이 있긴합니다. PR을 스태킹할때 브랜치 단위로 해야 하니까요. 사실 그래서 페이스북(메타)에서는 phabricator, 구글에서는 Critique 이라는걸 씁니다. 이 툴들은 기준이 한 컴밋당 한 PR이 올라가게 되어있어서 이런 형식의 코딩이 자연스럽죠. 결론적으로, 우칸많사님의 팀원 분들과 대화를 나눠보는게 좋을것 같습니다. 리뷰를 하는 사람 입장에서 갑자기 팀원 한명이 올리는 방식을 바꾸면 당황스러울 테니까요. 가장 중요한것은 자기 자신과, 팀 한테 맞는 스타일을 찾는 것이라고 생각합니다. 기존 방식을 의심하고, 더 발전할 수 있는, 더 효율적인 방식이 있을까 고민하는 것은, 언제나 좋고, 필요하다고 생각됩니다. 저는 제가 생각하는 방식을 얘기한 것 뿐이고요 :)
![[#유퀴즈온더블럭] G글 16년 다니다가 해고 통보 받았을 때 느낀 우울과 배신감💔 이 위기를 극복할 수 있었던 로이스의 긍정적 사고💪](http://i.ytimg.com/vi/3mRUakBl9QU/mqdefault.jpg)
후반부의 “PR을 작은 단위로 유지하라”는 대체로 좋은 포인트 같아요.
다만 전반부의 “컨텍스트 스위치 코스트 때문에 다 외부와의 소통은 제쳐둔다”는 솔직히 공감되지 않네요. 개인적으로 저 또한 컨텍스트 스위치에 능하지 않은 사람이라 전 이걸 제 단점으로 인지하고 있는데요. 실제로 컨텍스트 스위치를 잘하는 동료들을 보면 집중해서 작업도 잘하고 그때 그때 인터럽트도 잘 해결하고 컴케면에서도 빠르게 응답해주는 경우가 많았습니다.
엔지니어의 업무 특성 상 컨텍스트 스위치 시 효율이 떨어질 수 있다는 맞지만 ‘그러니까 나는 종종 개인적으로 외부 요청 거의 차단하고 집중한다^^’는 협업 측면에서도 아닌 것 같아요.
1. 컨텍스트 스위치를 잘 하는 것도 능력이다.
2. 필요한 경우, 조직 차원에서 시스템적으로 집중할 수 있는 시간을 제공한다
PR 잘게 쪼개놨는데 리뷰어가 자기 집중해야한다고 반나절 넘게 잠수타게 되는 것도 꽤나 비효율적일 것 같습니다.
시청해주셔서 감사합니다!
저도 말씀하시는 것처럼 "컨텍스트 스위치 코스트 때문에 다 외부와의 소통은 제쳐둔다"라는 애티튜드는 협업에 좋은 자세는 아니라고 생각합니다! 한결님도 항상 그러는 것은 아니시고요.
저는 "이런 극단적인 애티튜드를 갖을 때도 있다!" 라고 이해했습니다. 복잡하고 중요한 문제를 해결할때, 문제를 쪼개는 작업이 진행되는 초반 기간때만 소통을 좀 줄이고, 체크포인팅이 완성이 되서 복잡한 문제를 간단한 to-do list를 만들었다는 느낌이 들면 다시 팀원들을 위해 커뮤니케이션을 더 하시는 것 같습니다.
그리고 말씀하신 것처럼 이런 소통이 막히는 순간들이 필요하면 팀원들에게 이유와 예상되는 시간을 공유해야한다는 생각도 너무 공감합니다 :)
@@inside-out-with-joo-clips 열린 소통 감사드립니다! 덕분에 혼자서는 갸우뚱했던 부분들이 많이 해소된 것 같습니다 ㅎㅎ
@@dev-playing-gt 덕분에 영상에 다 담기지 못한 이야기들은 전달한 것 같아서 좋습니다. 이런 질문해주셔서 감사합니다 😄
협업도 중요하지만, 긴 호흡으로만 해결되는 문제도 있기에 저는 필요하다고 봅니다. 물론 포지션과 맡은 일의 무게감에 따라 달라지겠죠
이거 ㄹㅇ로 도움많이됏다 계속 큰그림을 보면서 일해서 ㅈㄴ게 스트레스 받았던듯 잘게 쪼개서 해보겟습니다 감사힝
저도 스타트업에서 주니어지만 프론트엔드 1인으로 작업하는 입장에서, 큰 그림을 계속 보고 있으니 컨벤션은 개나줘버린 외주 코드, 케이스 제대로 고려 안하는 기획, 아토믹하지 않은 컴포넌트 남발하는 디자인으로 스트레스가 너무 많았는데 이 영상보고 같은 생각이 들었네요 감사합니다ㅠ
두 분의 진행이 너무 매끄럽네요. 도움되는 좋은 내용 감사합니다.
감사합니다. 더 좋은 이야기들 담아보겠습니다!
좋은 인사이트 감사합니다!! 한결님의 방법대로 태스크 관리를 해봐야겠습니다😊👍
저도 요즘 일하면서 적용중입니다ㅎㅎ 시청해주셔서 감사합니다!
저도 스타트 업 다니는데 프로젝트 하나라고 했는데 사실은 6개의 다른 프로젝트를 동시에 했음. 콘텍스트 스위칭 조차 불가능. 나중에 심리 상담 받았습니다
너무 힘드셨겠네요… 생각만 해도 엄두가 안 나네요…
ㅋㅋㅋㅋㅋ 헬게이트 오픈!!
그런 회사는 퇴사 솔루션 외에는 답이 없습니다
1000줄짜리 코드 리젝하는건 정말 동감합니다. 잘게 쪼개서 PR하는게 리뷰 하기 쉽고 버그나 로직상 문제 될만한 부분을 쉽게 잡을 수 있죠. 결국은 코드부채에 대한 문제가 해결될걸로 보입니다
맞습니다!ㅎㅎ 개인적인 시간과 리뷰하는 사람 시간 배려도 되지만, 궁극적으로 코드부채가 해결되는게 가장 좋은 결과가 아닐까 싶네요! 나중에 문제가 생겨도 고치게 되는 사람 시간도 아껴질테고요! 시청해주셔서 감사합니다 😄
뭐야 지 고퀄의 팟캐스트는...바로구독!
좋은 말씀 감사합니다! 꾸준히 좋은 이야기들 많이 담아보겠습니다 :)
업무자동화 코드만들어서 만드는 비개발자입니다
본능적으로 느꼈던 집중하기까지 필요한 시간이 있다고 생각했는데
감정적인스텝부분 격하게 공감합니다
2천줄에 가까운코드를 짜며 수정하고 코드뜯어고치고 하는과정에 고민한부분의 내용이 나와서 좋았습니다
좋은영상 잘보고갑니다
적극적으로 공부하시는 모습이 멋있습니다! 시청해주셔서 감사합니다
만년 저급코더는 각주달기, 백업하기, 변동사항 기록하기 .... 모두 기록과 백업을 열심히!~
정말 좋은 영상이네요. 감사합니다 ㅎㅎ
시청해주셔서 감사합니다!
제 습관을 돌아보게 되네요. 좋은 영상 감사합니다 :)
저도 한결님과 대화 나누면서 저 자신을 많이 돌아보게 됐습니다. 시청해주셔서 감사합니다!
팟캐스트 진짜 맛있게 잘하시네요. 구성도 알차고.. 아쉬운듯한 길이도 그렇고 ! 아주 좋습니다.
좋은 말씀 너무 감사합니다. 힘이 되네요ㅎㅎ 아직 미숙하지만 꾸준히 좋은 이야기들 많이 올려보겠습니다!
구독했습니다. 정말 유익한 내용이라 생각합니다. 감사합니다!
도움이 되셨다니 좋습니다. 시청해주셔서 감사합니다😄
정말 좋은 영상이네요. 초보엔지니어로서 지향해야할 부분들인것같아요 감사합니다
시청해주셔서 감사합니다. 저도 정말 배웠습니다!
좋은 영상 감사합니다~
시청해주셔서 감사합니다!
정말 좋은 영상감사합니다!!! 나는 왜 이렇게 개발속도가 느린걸까라고 한탄했었는데 영상을 보고 이유를 알게 됐어요. 머리로만 생각해서 코드를 치다보니 마지막엔 항상 처음에 생각했던 디테일을 놓치게되고, 그럼 수정을하면서 또 메인 흐름을 놓치고 그러면서 개발속도가 나지 않았던것 같아요. 클린코딩 책을 보면서 함수는 가능한 작은 단위로 나눠야 한다는걸 알고 있다 생각했는데 말씀해주신 걸 듣다보니까 제대로 이해하고 실무에 적용하고 있진 못했다는걸 깨달았어요. 앞으로는 기능 하나를 만들때도 어떻게 구현할지 단계별로 기록해놓고 순차적으로 만들면서 기능단위 체크포인팅을 만들 수 있게 해야겠습니다. 너무 좋은 인사이트 감사합니다!
도움이 되셨다니 너무 좋네요ㅎㅎ 책을 읽으면서 배운것들 이어도, 이렇게 이야기로 직접 들으면 또 다르게 다가오는 것 같습니다. 시청해주셔서 감사합니다!
도움받고 갑니다 감사합니다.
도움이 됐다니 너무 좋네요. 시청해주셔서 감사합니다!
체크포인트! 쪼개기! 감사합니다
도움이 되셨다니 너무 좋네요!
저도 한결님이랑 대화 나누면서 너무 많이 배웠습니다 :)
인상깊어요
시청해주셔서 감사합니다!
몰로코만큼 큰회사는 딜레이가 가능할거같은데 개발자 한두명인 중소회사는 여기서 처리해달라 저기서 처리해달라 p2p로 난리치니깐 그 문제부터 빨리 처리해줘야할수밖에없음. 팀장한테 이거먼저하고 할게요했는데 안좋은표정짓는거보고 좀 놀랬음
회사사람들은 다 자기 일처리만 생각함 그게 문제임 난 정신과약먹고 많이 좋아졌음
아무래도 큰 회사일수록 어떤 업무 진행박식이 엔지니어들에게 더 효율적인지를 이해하고, 기다려주는 것 같습니다. 작은 회사들은 해야할 일들이 너무 많고 급박한 경우들이 많으니까요ㅠㅠ 조금 더 여유를 갖고, 각자의 입장을 이해해보면 좋을텐데, 그게 참 쉽지 않은 것 같습니다.
5:50
저는 이런 경우 인터페이스를 투두에 맞춰 만들어두는게 편하더라구요
좋은 방법일것 같습니다!
800줄짜리 하나 끝내고
다시 800줄 짜리 진행중인데
진도가 안나감..
🎉
ㅋㅋㅋ 다들 역시 컨텍스트 스위칭이 고민이군요...ㅋㅋ, 저의 경우에는 TODO 리스트를 코드 주석에 적어 놓고, 중간에 다른걸 해야 한다면, 현 시점의 컨텍스트의 앞뒤를 주석에 달아 놓는 방식으로 하거나, 도식화를 해놓거나, 그래프로 해놓고 합니다. 그럼 좀 덜 소모적이더라고요.
PR를 순서대로 해놓는 부분은 저도 좀 연습해야 겠네요. 알지만, 잘 안되는 ㅋㅋ
복잡한 문제를 해결해야 하는데, 팀워크도 그만큼 중요한 필드이기에 다들 제일 고민하는 부분이 아닌가 싶습니다ㅎㅎ 제시하신 방법도 너무 유용할 것 같습니다. 정말 급한 일이라 빨리 가야하는 일이라면, 간단하게 코드 주석에 정리라도 해놓고 간 것들이 나중에 큰 도움이 될 것 같네요!
좋은 영상 감사합니다. 혹시 실례가 되지 않는다면 두 분의 링크드인 아이디를 알 수 있을까요?
이한결 님: www.linkedin.com/in/hanlee0707/
장주영: www.linkedin.com/in/jooyoung-jang-52557311a/
입니다!
PR 말씀 주시는게 커밋 단위가 아니라 PR 단위를 말씀하시는걸까요?
매시브한 PR에서 세부적으로 나누고 거기서 또 커밋을 또 세부적으로 나눠라..
커밋은 최대한 잘게 작성하려 노력했는데 PR 자체가 하나의 일을 하는 데 너무 변경이 많거나 피쳐를 추가하는 경우에,
한 피쳐에 대한 뭉퉁 그려진 PR보다는 세부적인 PR을 모아 하나의 피쳐를 완성하라는 말씀이실까요?
확실한 답변드리기 위해서 한결님께 연락드려 봤습니다.
==== 답변 ====
다양한 회사들이 있고, 회사들 마다 쓰는 리뷰 툴과, 버전 컨트롤이 달라서 정답은 없다고 생각합니다. 하지만, 일반적인 github을 사용한다 생각했을때, 저는 개인적으로 PR 단위로 쪼개줘야한다고 생각합니다. 리뷰를 부탁하는 사람, 리뷰를 하는 사람 다 빠른 시간안에, 확신을 갖고 움직일 수 있죠. 간단한 feature면 굳이 여러개의 pr을 사용할 필요는 없다고 생각하지만, 복잡한 feature라는 가정하에 하나의 예시를 제시하자면,
각 PR을 “[1/x][전체 목적][이 PR에 들어간 changes 요약]”으로 제목을 짓고, 마무리 PR은 [x/x]식으로 짓는게 하나의 방법이 될 수 도 있겠죠. 여기서 더 들어가서 “[1/x][전체 목적][세부 큰기능][이 PR에 들어간 changes 요약]” 같은 식으로 들어가도되고요.
이렇게 정리를 한다는건 나 보기도 쉽고 남보기도 쉽고, 결국엔 나중에 보는 overhead 가 줄어든다는게 큰 장점이라고 생각됩니다. 예를 들어 제가 pr 을 리뷰 해달라고 보냈는데 2일있다가 리뷰해서 돌아오면 제가 바꾼 내용 뭔지 기억 안나는경우가 꽤 생기죠.
사실 github에서 이런 어프로치는 좀 불편한 감이 있긴합니다. PR을 스태킹할때 브랜치 단위로 해야 하니까요. 사실 그래서 페이스북(메타)에서는 phabricator, 구글에서는 Critique 이라는걸 씁니다. 이 툴들은 기준이 한 컴밋당 한 PR이 올라가게 되어있어서 이런 형식의 코딩이 자연스럽죠.
결론적으로, 우칸많사님의 팀원 분들과 대화를 나눠보는게 좋을것 같습니다. 리뷰를 하는 사람 입장에서 갑자기 팀원 한명이 올리는 방식을 바꾸면 당황스러울 테니까요. 가장 중요한것은 자기 자신과, 팀 한테 맞는 스타일을 찾는 것이라고 생각합니다. 기존 방식을 의심하고, 더 발전할 수 있는, 더 효율적인 방식이 있을까 고민하는 것은, 언제나 좋고, 필요하다고 생각됩니다. 저는 제가 생각하는 방식을 얘기한 것 뿐이고요 :)
분할정복!
구독자 400? 앞으로 기대가 됩니다
감사합니다! 꾸준히 좋은 이야기들 많이 담아보겠습니다!
이게 그 유명한 판교어구나..
ㄹㅇㅋㅋ
인트로에 비추박습니다. 머지?
큰 뭉터기의 1000줄 이상의 코드 체인지는 좋지 않다는 걸 얘기하시는 것 같습니다. 다른 엔지니어들이 더 쉽게 이해할 수 있게 더 작은 단위로 로직을 쪼개서 보내면 좋을 것 같습니다!
뭐 영업 마케팅한테 일정 시간단위로 쪼이면 저런소리 못하지....