💡 내가 생각하는 “잘 하는” 개발자란?
1. 개발 스펙에 대한 일정을 현실적으로 척척 잘 계획하는 개발자
- 너무 무리하지 않을 일정이면서 테스트까지 다 끝내서 커피 한 잔의 여유..를 즐길 수 있을 정도..
- 개인적으로 일하면서 기간 산정이 제일 어려웠습니다 🥲
- 사수님은 예상한 것보다 2~3일은 더 붙여서 정하는게 좋다고 하셨는데, 기간이 너무 길어지면 제가 실력없는 개발자라고 평가 받을 것 같아서 저 스스로를 갈아서 어떻게든 해냈던 것 같아요 😓
2. 요구사항을 보면 바로 설계도를 그릴 수 있는 개발자
- 이건 1번이랑 연관되는 것 같은데 구현해본적 없는 스펙은 일정을 어떻게 잡아야 할지 어렵더라구요
- 잘 하는 개발자가 되었다면 이미 많은 것들을 구현해본 상태일테니 설계도가 그려지면 자연스레 일정 산정도 잘할 수 있지 않을까 싶습니다 ..ㅎㅎㅎ
3. 어려운 문제를 해결하기 위해 다른 직군과 소통할 수 있는 개발자
- 기업 공고문에 나올 것 같은 멘트지만 정말 필요한 역량인 것 같아요
- 가령 백엔드에서 데이터 구조를 조금만 바꿔주거나 디자인이나 기획을 살짝만 변경하면 쉽게 해결되는 문제들이 많더라구요
- 여기서 문제는 그들을 어떻게 설득할 수 있을지가 관건인 것 같습니다!!
- 그래서 기술적인 문제를 다른 직군도 이해할 수 있도록 쉽게 풀어내는 능력 + 서로 기분이 상하지 않을 정도의 전달 능력, 요 두 가지 능력을 갖춘다면 저도 소통을 잘 하는 개발자가 되었다고 생각해볼 수 있을 것 같아요.
📒 202x년의 박수현의 일기…..
출근하자마자 커피 3샷을 내렸다.
학생 때는 왜 개발자들이 커피를 좋아하는지 몰랐는데
이젠 카페인이 없으면 하루를 시작할 수가 없는 몸이 되었다… 하지만 이런 내 모습도 나쁘진 않다.. 😌
커피를 홀짝이면서 오늘 있을 회의를 준비한다.
이번에는 큰 스펙이라고 하셨으니까 여러 직군들이 다 모이겠군!
먼저 기획 내용을 듣는데 꽤나 구성이 복잡해보인다.
하지만 다시보니 주니어 때 개발했던 작업들을 응용해보면 되는 내용이다.
2023년에는 내가 정말 열심히 했었는데… 그때 공부했던 것들이 다 도움이 되는구나 (ㅎㅎㅎ 😏)
이정도면 개발은 5일 잡고 QA는 2일 정도로 잡아서 일주일 주기로 배포하면 되겠구만!
하나 문제가 있다면 데이터 구조가 복잡해서
백엔드가 제시한 내용대로 하면 프론트에서 처리하느라 일정을 이틀은 더 잡아야 할 것 같다.
백엔드에서 !@!%하게 처리하면 API를 한 번만 쏴도 되고 상태관리도 더 안정적으로 처리할 수 있을텐데!
자료를 정리해서 백엔드 개발자에게 제안 슬랙을 쐈다.
하지만 돌아온건 DB가 꼬여서 어려울 것 같다는 답변이었다…
아차 내가 백엔드 지식은 없어서 수긍할 수 밖에 없을 것 같다..
아니..? 갑자기 머리속에 2023년에 공부했던 데이터 구조와 백엔드 지식들이 스쳐지나갔다.
그때의 기억을 살려서 새로운 데이터 구조를 제안했고 결국 데이터를 더 편하게 다룰 수 있게 되었다!! 😎
덕분에 여유롭게 작업할 수 있게 되어서 개발을 하루 일찍 끝낼 수 있었다.
남는 시간에는 후배들과 간단한 커피챗을 잡아서 어려운 점이 없는지 물어보고 문제 사항을 파악하려고 했다.
대부분의 고민들이 내가 주니어 시절에 겪었던 고민과 같아서 더 도와주고 싶었다.
2023년에 메모했던 내용들을 꺼내서 후배들에게 공유해주었고
다른 직군과 얘기해야하는 내용이 있다면 내가 대신 정리해서 협의하기도 하면서 선배미..✌️를 보여주었다.
쓰다보니까 과몰입하느라 일기가 엄청 길어졌다.. 🤭
일기를 쓰면서 느꼈던 점은 주니어 시절에 고민했던 내용들은 나만 하는 고민인 것 같아도
사실은 주변 모두가 하고 있는 고민이고 그것을 직접 해결해나가는 과정에서 배우는 점이 참 많은 것 같다.
위에 적은 내용들도 실화를 기반으로 작성되었지만.. 한 번 경험하고나니 다음부터는 어떻게 대처하고 해결하면 좋을지 알게 된 것 같다.
그러니 계속해서 치열하게 고민하고 공부하면서 하루하루 보내다보면
어느새 인지하지도 못한 순간에 이 일기에 등장하는 잘 하는 개발자가 되어있지 않을까..?
긴 글 읽어주셔서 감사합니다 ㅎㅎ 🙇♀️