신입개발자인 내가 배우는 것들📖

❓ 적는 이유
솔직하게 지금 회사 다니면서 이직하고 싶다는 생각만 하고 있다.
지금 회사가 도움이 안된다고 생각하기 때문이다.
하지만 어딘가에 현 회사를 경력으로 써야한다면, 현재 회사에서 배운 점이 무엇인지 어필해야 한다.
그래서 생각날 때마다 블로그에 적기로 했다.

회사 다니면서 배우고 있는 것

1. 확실하게 알고 코드리뷰하기
   • 내가 적어도 로직과 코드를 100% 이해하고 있다면, 모르는 내용에 대한 질문이 나와도 임기응변이 가능하다. 50%만 아는 상태에서 팀장과 코드리뷰하게 되면 참사날 가능성이 많다. 팀장의 시간이 내 시간보다 더 비싸기 때문에 코드리뷰할 때는 신중하게 해야하고, 확실히 파악했다는 판단이 설 때 해야한다.
2. 끝까지 디버깅하기
   • 초반에 많이 했던 실수가 끝까지 디버깅을 안하고 어느정도 했을 때 답답한 마음에 선배 혹은 팀장에게 질문하곤 했다. 디버깅을 조금만 더 찍어보면 알 수 있는 내용이었는데 끝까지 파악을 하지 않았던 것. 뭐든 물어보기 전에 내가 할 수 있는 선에서 다 해보고 그것을 정리한 후에도 답이 없을 때 자문을 구해야 답하는 사람도 편하다.
3. 개발 내용 노션에 정리하기
   • 어떤 이슈에 대해 개발 내용을 노션에 차곡차곡 정리해 놓으면 똑같은 이슈가 발생했을 때 보다 빠르게 대처가 가능하다. 뿐만 아니라, 팀원들과 해당사항을 공유할 때 노션 페이지를 공유하면 내 개발 시간을 줄여가며 설명하지 않아도 돼서 효율적이다.
4. 무조건 긍정적으로 대답하기
   • 가장 중요할지 모른다. 개발은 정말 '하면된다'의 예시가 아닐까... 개발은 안되는게 없는 것 같다. 그런의미에서 동료가 무엇을 요청할 때, 내 기준 정말 안될 것 같아도 일단 해보겠다고 대답해야한다. 된다고 호언장담을 하라는게 아니라 긍정적인 시그널을 주는 대답을 해야한다. 그래야 안되더라도 이해한다.
5. 타부서/ 유관부서와 정확히 이야기 하기
   • 말끝을 흐리지 말자. 말끝을 흐리는 이유가 뭘까? 자신감이 없어서다. 말끝 흐린다고 내가 하는 말 내용 달라지지 않는다. 그냥 틀려도 자신있게 말하고 알려주는 거 듣자. 또, 이슈가 생겼을 때 설계자 혹은 요청자와 바로바로 소통해서 문제가 지속되지 않도록 해야한다. 혼자 고민해봤자 시간만 길어지고 납기요청 지나면 욕먹는다.
6. 이슈 파악 후 공유 빠르게 하기
   • 이슈를 파악했을 때, 이게 내 선에서 가능한 것인지 도움이 필요한지 파악하고 윗선에 공유를 해야할지 선택해야한다. 또 무슨 일인지는 알지만, 너무 비효율, 비합리적인 건이라면 윗 선에 이슈를 공유하고 도움을 요청하도록 하자. 바로 실행하기보다는 이슈를 정확히 파악하고 행동으로 옮길 수 있도록 하자.