아무리 바빠도 질문을 하면 안될 정도로 바쁜 사람은 없다.
너무 바쁘면 “지금 바빠서 나중에 숨 돌릴만하면 알려줄게요” 라고 말하는게 맞다.
만약 질문을 했다고 해서 버럭 화를 낸다면, 화낸 사람이 잘못이다.
그럴 땐 한귀로 흘려버리고, 기죽지 말라.
이해갈때까지 질문하라.
경력이 있는 직원이라도 처음 그 회사에 들어가면 당연히 그 회사 소스코드를 모른다.
초급 개발자는 당연히 모른다.
인터넷이 없었던 시절에는 물어보면서 배우는 일이 상식이었다.
모르니깐 질문하는거다.
질문하기 전에 인터넷 등을 찾아보는 것은 나쁘지 않다.
그렇지만, 인터넷에 뜬 구름 잡는 얘기들만 있는것 같다면,,
지체하지 말고 물어보라.
많이 물어보고 많이 성장하라.
개발하다가 문제를 만나면 대충 상황을 모면하려고 하지 말라.
대신 문제의 핵심을 파악하고 스스로 해결할 수 있는 사람이 되라.
잘 이해가 안간다면 적어보고, 그려보고, 정리해보라.
괜히 사람들이 UML 같은 그림들을 그리는 것이 아니다.
자기들도 이해가 안가니깐 그린다.
이해하지 못한 코드는 가져다 쓰지 말라.
가져다 쓰기만 한 사람은 조금만 응용해도 막혀버린다.
외우려고 하지말고 이해하라.
천천히 하나씩 전문가가 되라.
버그는 항상 있다. 개발 30년차가 되어도 마찬가지다.
그러니깐 프로젝트 계약할때 테스트 기간 따로 잡고 돈도 따로 받는다.
누가 버그있다고 핀잔주더라도 당당하라.
테스트할 시간을 주지 않은 상황이 문제고,
테스트할 사람을 뽑아주지 않은 회사가 문제다.
내가 테스트 하기로 되어 있다면 내 테스트를 개선하라.
누군가 상황에 맞지 않는, 시키지 않은 그런 엉뚱한 행동을 하고 있다면,
그건 그 사람 탓이 아니다. 의사소통 문제다.
메일을 공유해주지 않은 담당자가 문제이고,
문서를 잘 만들어주지 않은 사람이 문제이고,
궁금해도 질문을 하지 않은 사람이 문제다.
관리자가 정보도 안주고 막연하게 일을 시키거든
가서 담당자인 나를 위한 회의를 따로 하자고 하던지,,
아니면 그동안 메일을 전부 포워딩해달라고 하든지,,
당당하게 요구하라.
나의 관리자가 업무 담당자인 나보다 해당 사안에 대해 더 잘 알 것이라고 가정하지 말라.
내가 의사결정할 수 없다면, 관리자도 우리팀 누구도 할 수 없다고 생각하라.
그정도 수준에서 의사결정에 필요한 정보를 모으라.
그리고 최선의 안을 선택해보고 내 의견을 공유하라.
그리고 나서 관리자나 팀원들이 피드백을 주면 그들의 의견을 수렴하여 나의 결정에 약간의 수정을 가할수는 있기는 할 것이다. 그러나 결국 결정은 내가한다. 관리자는 필요하다면 승인해줄 뿐이다.
아직 결정에 대한 확신이 없다면 더 많이 물어보고, 더 많이 조사하고, 가능한 모든 경우의 수도 나눠서 생각해보고, 수식을 만들어 계산도 해보라.
그러면서 더 확실한 의사 결정의 근거들을 갖추라.
혼자서 책임 질 수 없고 해결할 수 없다고 판단된다면, 지체하지말고 명확하게 그 사실을 다른 사람에게 알리라. 그냥 “힘들다” 정도가 아니라 “불가능하다”라고 메일로 요청하던지, 아니면 협조를 위해 회의를 요청 하던지 명확하게 하라. 도움을 청하는 것은 부끄러운 것이 아니다. 회사에서는 미안한 마음이나 관계에 대한 염려보다는 일이되게 하는 것이 우선이고, 그것이 관리자의 생각이다. 팀은 도우라고 있는거고 관리자는 업무 배분하는게 일이다.
모든 일에 일정이 있다고 생각해두라.
잘 모르겠다면 물어보고 확인하라.
누군가 나에게 뭐라고 일을 시키거든,
언제까지 하면 되냐고 습관적으로 되물어라.
중간에 나의 역할이나 개발 요구사항이 바뀌었다면
일정도 바뀌었다고 가정하고 다시 물어보는 것이 좋다.
누가 시키지 않아도 능동적으로 일하라.
복도에 떨어진 쓰레기를 줍는 사람을 큰 회사들이 뽑는 이유가 있다.
내가 회사의 주인인것처럼 새로운 사업을 제안하라.
내가 팀장인 것처럼 프로젝트가 잘 굴러가도록 챙기라.
내가 프로그래밍 리더인 것처럼 설계에 대해 고민하라.
개발하다 보면 무슨일이 생길지 모르니 예상 일정을 잡을 때는 며칠 더 버퍼를 넣어서 말하라.
확실하지 않은 내용을 누군가 나에게 물어본다면 차라리 잘 모른다고 하라.
현상이나 누군가 한 이야기를 전달할때는 내 추측이나 판단 섞지 말고 알고 있는 그대로 하라.
문제의 원인을 경험에 비추어 추측하기 전에 로그에 찍힌 에러메시지 부터 확인하라.
최종 테스트까지 마치기 전에 다했다고 이야기하지 말라.
나는 최근 몇년간 우리회사가 개발자로서 첫직장인 분들과 일해왔다. 그중에 여럿은 좌절했고 그중에 일부는 또 다른 자기 길을 찾아 개발자의 삶을 포기했다. 그들과 부딪히며 잔소리 같이 했던 말들을 모아서 여기에 적어보았다. (일종의 잔소리 모음ㅋ) 또 비슷한 문제들을 경험할 누군지 모를 초급 개발자에게 조금더 쉽게 문제를 해쳐나갈 가이드라인 같은 도움이 되었으면 좋겠다. 혹시 모른다. 언젠가 내가 또 다른 분야에서 새로운 도전을 하게된다면, 힘내라고 다시 해보라고 그렇게 나에게 하는 말이 될수도 있을거 같다.