행복한 개발자

조엘 스폴스키가 정립한 내용. 현재 회사의 SW 개발 수준을 측정하는 잣대가 될 수 있다. 물론 팀원으로써의 Test를 수행할 수 있는 역량을 갖추어야 함은 물론이다. 다시 한 번 찾아 읽으며 블로그에 옮긴다. 원문: http://korean.joelonsoftware.com/Articles/TheJoelTest.html The Joel Test Source Control(소스 컨트롤)을 사용하십니까?한번에 빌드를 만들어낼 수 있습니까?daily build(일별 빌드)를 만드십니까?버그 데이타베이스를 가지고 있습니까?새로운 코드를 작성하기 전에 버그들을 잡습니까?up-to-date(최신) 스케줄을 가지고 있습니까?spec(설계서)를 가지고 있습니까?프로그래머들이 조용한 작업환경을 가지고 있습니까?돈이 허..

나는 자기계발서를 거의 보지 않는 편이다. 자기계발서에 적혀 있는 내용이 저자 자신에게는 유용한 방법이었을지는 모르나, 처해 있는 환경이 다른 독자에게는 그다지 유용하지 않은 내용이 많기 때문이다. 자기계발서를 읽으면서 얻을 거라고는 저자의 성공담에 대한 대리만족 밖에 없다. 마치 "내 친구 아무개는 잘 나가" 이런 말을 누구에게 건넬 때 느끼는 감정과 비슷하다. '나는 비록 아니지만 그래도 잘 나가는 친구를 알고 있다. 그러니 날 무시하지 마라.' 아니면 지금 대화를 나누고 있는 상대에게 '너나 나나 그 잘나가는 친구에 비하면 똑같은 처지다.'라고 은연중에 건네는 말. 뭐 이런 식이다. 하지만 정작 그 말을 하고 난 자신이 초라해 지는 자신을 발견하게 된다. 이 책 제목은 다소 도발적이면서도 다른 분야..

회사 생활을 하다 보면 평소 일하던 방식이 급격히 변경될 때가 있다. 조직 개편으로 인해 다른 조직으로 발령이 나거나 새로운 업무 방식이 도입될 때가 그렇다. 이때 역시 변화에 대처하는 방법에 썼던 '회피자형', '얼리어답터형', '추종자형'이 나타난다. 자신에게 변화가 찾아올 때 '얼리어답터'는 아니더라도 '회피자'는 되지 말자고 했었다. 빠른 적응력이 요구된다. 하지만 이렇게 급격한 변화가 일어날 때에는 이야기가 다르다. 적응할지 말지 재는 행동이 오히려 독이 된다. 이 업무방식은 내게 안 맞아. 도대체 위에서는 왜 이런 결정을 내리는 거지? 보나 마나 6개월 정도 있으면 또 바뀔 거야. 이런 부정적인 생각을 빨리 버리는 게 좋다. 일은 이미 벌어졌다. 자신이 그 변화를 원래대로 바꿀 수 없는 위치에..

SW 개발 과정에는 수많은 테스트 절차가 있다. 회사마다 실시하는 종류는 다르겠지만 위키피디아에 기록된 것만 해도 무려 16가지나 된다. 요즘 읽고 있는 책에 테스트에 관한 흥미로운 견해가 있어 본문을 옮겨 본다. 테스트를 많이 할수록 품질이 좋아진다고 생각하는 사람도 있다. 정말 그랬으면 좋겠지만, 안타깝게도 그렇지가 않다. 테스트하면 결함을 찾는 데 도움이 되긴 하지만 코드 여기저기 숨어있는 결함을 테스트만으로 찾아내는 건 불가능하다. 아무리 열심히 테스트해도 상당수의 결함이 잡히지 않고 남아있을 것이고, 여기서부터 불편한 진실이 나타나기 시작한다. 테스트에서 기존 결함 중 특정 비율(예를 들어 65%)만큼을 찾아낸다고 해 보자. 그러면 테스트를 통해 찾아낸 결함이 많아질수록 찾아내지 못한 결함도 많..

서점에는 한 쪽 벽면을 당당하게 차지하고 있는, 일명 '자기 계발서'라고 불리는 책들이 있다. 언젠가 부터 이런 류의 "성공하기 방정식 A to Z"식 서적들이 넘쳐나기 시작했다. 나도 몇 권 사서 보고 따라해 보았다. 학창 시절에 "성공하는 사람들의 7가지 습관(김영사)"을 읽고 원문 제목 대로 effective한 사람이 되려고 한 적도 있었다. 그나마 사회생활 하면서 도움이 되었던 자기 계발서는 이 책 뿐이고, 그 외에 책들은 제목조차 기억에 남아 있지도 않다. 이런 자기 계발서들의 문제는 독자의 대상을 일반 대중에 맞추다 보니, 성공하기 위한 디테일한 실천법이 오히려 모든 사람들에게 끼워 맞춰지지 않는다는 것이다. 사람들은 너무나 다양한 삶의 스펙트럼을 가지고 있는데 한 권의 책으로 모든 사람을 만..

신입사원이 처음 팀에 투입되면 방치되는 경우가 종종 있다. 맡게 되는 업무라고 해 봐야 팀내 자산조사와 같이 그다지 가치를 느끼지 못하는 일이 대부분이다. 당장 급한 업무를 신입에게 맡기기에는 못 미더울 뿐더러 업무를 일일이 가르치면서 진행하기에는 시간이 너무 오래 걸린다. 하지만 당신은 이 시기를 허비해 버리면 안된다. 당신은 앞으로 회사생활을 하면서 이 시기만큼 마음대로 공부할 시간을 얻지 못할 수도 있다. 평소 항상 좋은 책들을 찾아 읽어라. 무슨 책을 읽어야 할 지 모른다면 선배에게 자문을 구해보라. 필요한 지식을 얻기 위해 노력하는 후배를 위해 기꺼이 시간을 내 줄 것이다. 사내에 멘토링 제도가 있다면 멘토를 적극 이용해라. 멘토는 멘티의 실력을 키워서 한 명의 어엿한 팀원으로 키워내야 할 의무..

신입사원일 때 한 선배에게 빌드할 때 Warning 메시지가 많이 뜨는데 고쳐야 되지 않냐고 물은 적이 있다. 돌아온 대답은 그럼 네가 한 번 고쳐봐라는 말이었다. 문맥상으로는 본인은 다른 일도 많고 동작하는 데에 별 문제도 없으니 시간이 많은 신입 너가 한 번 고쳐봐란 뜻이었다. 그런데 그는 과연 컴파일러가 친절히 시간을 들여가며 화면에 뱉어 준 경고를 무시할 정도로 바빴는지, 과연 그 경고 메시지들은 무시할 정도로 사소했는 지는 지금까지도 의문이다. 당신이 훌륭한 SW엔지니어가 되고 싶다면 "청소하는 습관"을 몸에 익혀라. 여기서 말하는 청소는 단순히 책상 위를 깨끗이 정돈하고 먼지를 닦아내라는 뜻이 아니다. 실력 있는 개발자도 책상 위가 지저분한 사람들이 많다. 어제 야근 중에 먹고 반쯤 남겨놓은 ..

흔히 '개발자'라고 하는 SW엔지니어가 직업으로서 어느 정도 매력이 있는 지 생각해 보자. 사람들이 생각하는 좋은 직업이 갖추어야 할 조건을 나열하면 다음과 같은 것들이 있다. 1. 고액의 연봉2. 전문 지식이 필요함 (진입장벽이 높음)3. 근무시간이 규칙적이거나 자기 마음대로 조절이 가능함4. 업무 진행을 주관적으로 할 수 있음5. 적은 스트레스6. (무언가 더 나은 세상을 만들기 위해 노력한다는) 주위의 인정 개발자라는 직업이 위에서 열거한 것들에 몇 가지나 만족할 지 생각해 보면 2번외에 없는 것 같다. 그나마 2번 역시 닷컴 버블을 거치면서 직업훈련원과 학원에서 대량 양산된 인력들로 인해 장벽이 많이 낮아진 상태다. 개발자는 과연 좋은 직업일까. 어떤 아기의 돌잔치에서 돌잡이 쟁반 위의 마우스를 ..

먼저 내 소개부터 해야겠다. 나는 우리나라 사람이라면 누구나 아는 모 대기업의 휴대폰 사업부에서 근무하고 있다. 입사 전에는 학부에서 기계공학을 전공했고 관련 업계에서 병역 특례로 군복무를 대신했다. 학사 병역특례가 대게 그렇듯 (물론 그렇지 않은 좋은 업체도 많은 것으로 안다) 열악한 근무환경에서 일을 하다 보니, 공부할 때에는 그나마 재미있었던 전공이 앞으로 내가 먹고 살아야 할 업(業)으로 삼기에 적합한 것인가 하는 의문이 들었다. 3년 정도야 군대에서 고생하는 셈치고 참고 견딜 수 있었지만 평생을 이 업계에서 몸담을 자신이 없었다. 그래서 전공을 멀티미디어 공학으로 바꾸고 대학원으로 진학했다. 그 후 지금까지 IT업계에서 그것도 최전선이라고 할 수 있는 개발자의 삶을 살고 있다. IT 기술은 미쳐..

얼마 전에 공무원이라는 영화를 봤다.일상에 변화가 없다는 게 가장 큰 장점이라고 생각하는 7급 공무원이 그 주인공이다. 하지만 공무원이라고 업무에서 가정에서 그리고 자신의 인생에서 변화가 생기지 않을까? 회사 업무를 하다 보면 주위에 모든 것이 변한다. 조직개편이 되서 몸담고 있던 조직이 이동되기도 한다. 신입사원이 들어오고, 주위에 누가 퇴사했더라 하는 소식이 들려온다. 조직개편 되서 조직책임자가 바뀌면 무언가 이전에 있던 프로세스가 사라지고 새로운 프로세스가 생기기도 한다. 그런데 이게 그분이 처음에 의도했던 데로 항상 좋은 방향으로만 흐르지 않는 게 문제이긴 하다. 이건 다음 기회에 다시 이야기 하기로 하고 오늘 주제로 다시 돌아가자. 소프트웨어 개발 업무 중에도 역시 많은 것이 변경된다. -. 고..