2013.03.18

모두가 원하는 개발자 되기 10단계

Andrew Oliver | InfoWorld
개발자가 되기 위해 프로그래밍 기술만 있으면 된다고 생각한다면, 틀렸다!
 
코드를 잘 쓰는 것도 중요하지만, 일의 능률을 높이고 더 높은 연봉을 받기 위해서는 많은 이에게 자신이 누구인지 알리는 것이 중요하다. 다시 말해, 스스로를 마케팅해야 한다. 여기에서 성공적인 셀프 마케팅 방법을 소개한다.
 
모두의 개발자 팁 No.1 : 블로그 
블로그를 개설 후 한 달에 한 번 이상 포스팅을 올려라. 블로그에 올리는 글은 꼼꼼히 리서치하고, 바보 같아 보이는 말은 하지 않는다. 
 
농담이 아니고, 개발자들도 정말 작문 실력을 높이기 위해 노력해야 한다. 학교 다닐 때 국어 선생님이 가르쳐준 것들을 활용해보자. 글을 쓰기 전 개요를 작성하고, 서술 기법을 정하고, 문법이나 맞춤법을 확인하는 것 말이다. 
 
그런 후에는 아깝더라도 필요 없는 부분은 잘라내 지나가는 사람이 한번 훑어만 보아도 무슨 이야기인지 알 수 있을 만큼 단순하게 만들어라. 필자의 글을 읽는 에디터도 마찬가지지만 인터넷에서는 대화문과 같은 '뉘앙스'를 완벽히 전달할 수 없다. 
 
모두의 개발자 팁 No.2 : 오픈 소스
오픈 소스에 대한 거짓말들을 믿지 마라. 나이가 조금 어린 개발자들은 개발자가 실업자가 될 수 있었던 시절을 기억하지 못할 지도 모르지만, 경제 불황이 아주 최악일 때도 오픈 소스 프로젝트 개발자들은 빠른 시간 안에 일자리를 구할 수 있었다. 
 
오픈 소스 코드를 만들 때 자신이 원하는 직업이 어떤 것인지를 충분히 반영하기 바란다. 필자는 가능한 한 간단한 솔루션으로 어려운 문제를 해결하려 했지만, 그간 인터뷰해 온 개발자들은, 그들의 오픈 소스 코드에서도 분명히 알 수 있었듯, 간단한 문제를 복잡하게 만들기를 원했다. 
 
믿거나 말거나지만, 이런 시장도 형성이 되어 있으며 자신이 속한 시장을 반드시 코드에 반영시키기 바란다. 
 
모두의 개발자 팁 No.3 : 한 직장에 너무 오래 머물지도, 너무 자주 이직하지도 마라 
너무 자주 이직하지 마라. 농담이 아니다. 개발자들의 취업이 어려워지는 시절은 반드시 다시 온다. 그 때가 되면, 잦은 이직만큼 자신을 끈질기게 따라다닐 꼬리표도 없을 거다. 
 
반면, 한 직장에서 10년 가까이 머물며 한 가지 일만 하는 것도 좋지 않다. 한 곳에 너무 오래 머물다 보면 그 일이 일상화 돼버린다. 자신의 가치를 높이기 위해서는 IBM에서 IBM식으로 IBM 스택 코드를 쓰는 것에 만족해서는 곤란하다. 
 
필자는 개인적으로도 IBM이나 이와 비슷한 조직에서 1, 2년 이상 머무른 사람은 고용하지 않는다. 이들은 대체로 면접에서는 아주 훌륭한 모습을 보여주지만 프로그래밍 테스트에서 떨어지고 만다. 
 
모두의 개발자 팁 No.4 : 눈으로는 새로운 것을 추구하되, 실용적인 것에서 손을 놓지 마라
나이가 어린 개발자들은 화려하고 눈에 띄는 일을 좇는 경향이 있다. 필자가 가장 좋아하는 프로그래밍 언어는 루비(Ruby)지만, 루비는 평균적으로 봤을 때 자바(Java)만큼 돈을 많이 받지도 못하고 시장도 더 좁다. 
 
그렇지만 항상 그런 것은 아니다. 스칼라(Scala)가 강세를 얻고 있는 것처럼 보이지만, 시장 규모는 속일 수 없다. 반면 한 곳에 너무 오래 머무르다가 미래의 코볼(COBOL)이나 파워빌더(PowerBuilder) 개발자가 돼버려서도 곤란하다. 
 
모두의 개발자 팁 No.5 : 읽는 사람을 배려해 문서를 작성하라 
필자는 회사 임원들이 읽고 한 번에 이해할 수 있는 문서나 프레젠테이션을 만들었다는 이유만으로 프로젝트에 참여하거나 경영진 미팅에 참여하게 된 경험이 수없이 많다. 
 
필자는 항상 임원진들을 위한 개요를 서두에 작성해둔다. 다시 말해, 꼭 읽어야 하는 페이지는 개요뿐이고 나머지는 개요를 잘 이해하지 못했을 때 읽으면 된다. 이 때 고려해야 할 것은 엄청나게 바쁜 일정을 소화해야 하는 사람에게 이 주제에 대해 얘기하려면 어떤 정보를 골라서 설명해 줘야 하는가다. 
 
대부분 매니저들은 '누가 일의 진척 상황에 대해 자신을 귀찮게 하지 않고 이 일을 끝까지 이끌어 갈 수 있는가'를 가장 궁금해 한다. 이 부분에 중점을 두고 보고서를 쓰길 바란다.
 
모두의 개발자 팁 No.6 : 간결성이 생명이다
경영진들을 가까이 하다 보면 바로 알 수 있는 특징 가운데 하나는, 말을 잘 하는 사람일수록 짧고 정확한 답변을 한다는 것이다. 
 
답변이 길고 복잡해진다는 건 그 사람이 주제에 대해 잘 모르거나 별로 성실하게 일을 하지 않는다는 의미다. 또, 주제의 중요도와 목소리 톤은 반비례하는 것도 사실이다. 
 
정말 나쁜 소식을 전할 땐 조용히 문을 닫고 들어와 속삭이듯 말하는 법이다. 그다지 중요한 일은 아닌데 그냥 짜증 나는 소식일 경우 격앙된 목소리로 그 문제에 대해 목소리를 높이게 된다. 
 
중요하지 않은 일에 대해 목소리를 높이는 사람이 되지 마라. 자신이 무슨 이야기를 하는지 정확히 알고, 그 이야기를 어떻게 요약할 지 고민하되 세부적 사항들을 포함시키려 노력해야 한다. 
 
그렇지만 문장 하나 하나를 전부 세부 사항들을 곁들여 설명할 필요는 없고, 하늘이 무너진 것도 아닌데 작은 일에 호들갑을 떨지 마라(단지 한동안 괜찮은 빌드(build)가 없었기에 젠킨스(Jenkins)를 살펴봐야 할 지도 모를 뿐이다).
 
말로 하는 게 정 안 되면, 비용으로 승부봐야 한다. 숫자를 신중히 선택해 차트에 기입하고, 비용적인 측면에서 이것이 다른 것보다 더 낫다는 것을 확실히 보여줘라. 
 


2013.03.18

모두가 원하는 개발자 되기 10단계

Andrew Oliver | InfoWorld
개발자가 되기 위해 프로그래밍 기술만 있으면 된다고 생각한다면, 틀렸다!
 
코드를 잘 쓰는 것도 중요하지만, 일의 능률을 높이고 더 높은 연봉을 받기 위해서는 많은 이에게 자신이 누구인지 알리는 것이 중요하다. 다시 말해, 스스로를 마케팅해야 한다. 여기에서 성공적인 셀프 마케팅 방법을 소개한다.
 
모두의 개발자 팁 No.1 : 블로그 
블로그를 개설 후 한 달에 한 번 이상 포스팅을 올려라. 블로그에 올리는 글은 꼼꼼히 리서치하고, 바보 같아 보이는 말은 하지 않는다. 
 
농담이 아니고, 개발자들도 정말 작문 실력을 높이기 위해 노력해야 한다. 학교 다닐 때 국어 선생님이 가르쳐준 것들을 활용해보자. 글을 쓰기 전 개요를 작성하고, 서술 기법을 정하고, 문법이나 맞춤법을 확인하는 것 말이다. 
 
그런 후에는 아깝더라도 필요 없는 부분은 잘라내 지나가는 사람이 한번 훑어만 보아도 무슨 이야기인지 알 수 있을 만큼 단순하게 만들어라. 필자의 글을 읽는 에디터도 마찬가지지만 인터넷에서는 대화문과 같은 '뉘앙스'를 완벽히 전달할 수 없다. 
 
모두의 개발자 팁 No.2 : 오픈 소스
오픈 소스에 대한 거짓말들을 믿지 마라. 나이가 조금 어린 개발자들은 개발자가 실업자가 될 수 있었던 시절을 기억하지 못할 지도 모르지만, 경제 불황이 아주 최악일 때도 오픈 소스 프로젝트 개발자들은 빠른 시간 안에 일자리를 구할 수 있었다. 
 
오픈 소스 코드를 만들 때 자신이 원하는 직업이 어떤 것인지를 충분히 반영하기 바란다. 필자는 가능한 한 간단한 솔루션으로 어려운 문제를 해결하려 했지만, 그간 인터뷰해 온 개발자들은, 그들의 오픈 소스 코드에서도 분명히 알 수 있었듯, 간단한 문제를 복잡하게 만들기를 원했다. 
 
믿거나 말거나지만, 이런 시장도 형성이 되어 있으며 자신이 속한 시장을 반드시 코드에 반영시키기 바란다. 
 
모두의 개발자 팁 No.3 : 한 직장에 너무 오래 머물지도, 너무 자주 이직하지도 마라 
너무 자주 이직하지 마라. 농담이 아니다. 개발자들의 취업이 어려워지는 시절은 반드시 다시 온다. 그 때가 되면, 잦은 이직만큼 자신을 끈질기게 따라다닐 꼬리표도 없을 거다. 
 
반면, 한 직장에서 10년 가까이 머물며 한 가지 일만 하는 것도 좋지 않다. 한 곳에 너무 오래 머물다 보면 그 일이 일상화 돼버린다. 자신의 가치를 높이기 위해서는 IBM에서 IBM식으로 IBM 스택 코드를 쓰는 것에 만족해서는 곤란하다. 
 
필자는 개인적으로도 IBM이나 이와 비슷한 조직에서 1, 2년 이상 머무른 사람은 고용하지 않는다. 이들은 대체로 면접에서는 아주 훌륭한 모습을 보여주지만 프로그래밍 테스트에서 떨어지고 만다. 
 
모두의 개발자 팁 No.4 : 눈으로는 새로운 것을 추구하되, 실용적인 것에서 손을 놓지 마라
나이가 어린 개발자들은 화려하고 눈에 띄는 일을 좇는 경향이 있다. 필자가 가장 좋아하는 프로그래밍 언어는 루비(Ruby)지만, 루비는 평균적으로 봤을 때 자바(Java)만큼 돈을 많이 받지도 못하고 시장도 더 좁다. 
 
그렇지만 항상 그런 것은 아니다. 스칼라(Scala)가 강세를 얻고 있는 것처럼 보이지만, 시장 규모는 속일 수 없다. 반면 한 곳에 너무 오래 머무르다가 미래의 코볼(COBOL)이나 파워빌더(PowerBuilder) 개발자가 돼버려서도 곤란하다. 
 
모두의 개발자 팁 No.5 : 읽는 사람을 배려해 문서를 작성하라 
필자는 회사 임원들이 읽고 한 번에 이해할 수 있는 문서나 프레젠테이션을 만들었다는 이유만으로 프로젝트에 참여하거나 경영진 미팅에 참여하게 된 경험이 수없이 많다. 
 
필자는 항상 임원진들을 위한 개요를 서두에 작성해둔다. 다시 말해, 꼭 읽어야 하는 페이지는 개요뿐이고 나머지는 개요를 잘 이해하지 못했을 때 읽으면 된다. 이 때 고려해야 할 것은 엄청나게 바쁜 일정을 소화해야 하는 사람에게 이 주제에 대해 얘기하려면 어떤 정보를 골라서 설명해 줘야 하는가다. 
 
대부분 매니저들은 '누가 일의 진척 상황에 대해 자신을 귀찮게 하지 않고 이 일을 끝까지 이끌어 갈 수 있는가'를 가장 궁금해 한다. 이 부분에 중점을 두고 보고서를 쓰길 바란다.
 
모두의 개발자 팁 No.6 : 간결성이 생명이다
경영진들을 가까이 하다 보면 바로 알 수 있는 특징 가운데 하나는, 말을 잘 하는 사람일수록 짧고 정확한 답변을 한다는 것이다. 
 
답변이 길고 복잡해진다는 건 그 사람이 주제에 대해 잘 모르거나 별로 성실하게 일을 하지 않는다는 의미다. 또, 주제의 중요도와 목소리 톤은 반비례하는 것도 사실이다. 
 
정말 나쁜 소식을 전할 땐 조용히 문을 닫고 들어와 속삭이듯 말하는 법이다. 그다지 중요한 일은 아닌데 그냥 짜증 나는 소식일 경우 격앙된 목소리로 그 문제에 대해 목소리를 높이게 된다. 
 
중요하지 않은 일에 대해 목소리를 높이는 사람이 되지 마라. 자신이 무슨 이야기를 하는지 정확히 알고, 그 이야기를 어떻게 요약할 지 고민하되 세부적 사항들을 포함시키려 노력해야 한다. 
 
그렇지만 문장 하나 하나를 전부 세부 사항들을 곁들여 설명할 필요는 없고, 하늘이 무너진 것도 아닌데 작은 일에 호들갑을 떨지 마라(단지 한동안 괜찮은 빌드(build)가 없었기에 젠킨스(Jenkins)를 살펴봐야 할 지도 모를 뿐이다).
 
말로 하는 게 정 안 되면, 비용으로 승부봐야 한다. 숫자를 신중히 선택해 차트에 기입하고, 비용적인 측면에서 이것이 다른 것보다 더 낫다는 것을 확실히 보여줘라. 
 


X