변화를 거부하고 도전을 싫어하는 개발자
변화를 거부하거나 도전을 싫어하는 사람은 물론 있다. 많을 것이다. 이런 사람들의 태도가 무조건 잘못된 것이라고 평가하는 것은 좋지 못 하지만, 이런 사람들을 위해 하고 싶은 말이 참 많기도 하다.
나 조차도 변화나 도전은 좀 겁을 내는 경향이 있다. 하지만 어느 순간 약간씩 도전해 보면서 얻기도 하고 성취하기도 하고 보람을 느끼기도 하고 실패하기도 한다.
별 의미는 없겠지만 이런 저런 불평불만을 글로 한번 남겨볼까 한다.
팀 내에서 멋대로 형상관리(Issue Tracker)시스템을 도입하고 이를 팀원들에게 강요했던 적이 있다. 이 시스템은 프로젝트의 설계나 디자인에서 부터 문제점이나 개선 사항을 관리 할 수 있게 해 주는 요긴한 툴이다. 당연히 있으면 좋다고 생각될 것이다.
하지만 팀원들의 반응은 싸늘했다. 대기업 하청을 통해 시스템의 불합리성(?)과 귀찮음(?)을 경험한 개발자라면 어느 정도 이해를 한다. 하지만, 그 합리성을 모르는 신입 개발자들 또한 귀찮다는 이유로 거부하는 것을 보게 되었을 때 내가 틀렸나 라는 생각만 들었다.
이럴 때 이슈 트래커에 이슈를 등록해 놓고 관리해 왔다면 이런 문제가 발생 할 여지는 크게 줄어든다. 그런데 왜 이걸 이용하지 않으려 하는 걸까? 그러면서도 여전히 싸움을 벌이고 있다. 이제는 강요도 지친다.
이로 인해 생기는 또다른 문제가 있다면 내가 형상관리를 도입해 놓고도 사용하지 않게 된다는 점이다. 나 혼자 사용해 봤자 아무도 안보니까 결국 쓸 필요가 없는 것이다.
역시 이런 시스템은 모두에게 강제해야 쓰게 될 것 같다.
프로그래머에게 있어 프로그래밍 언어는 지식이자 힘이자 능력이자 도구이다. 그렇기 때문에 언어의 변화를 거부하는 개발자도 제법 되는 듯 하다.
프로젝트의 언어를 바꿀 것을 요구하는 것은 세심하게 해야 할 부분이다. 언어가 바뀌면 사람에 따라 능률과 결과가 완전히 달라질 수 있고 심하면 프로젝트 진행이 처참해 질 수 있다.
하지만 언어를 바꿈으로써 얻게 되는 점도 물론 존재한다. 프로젝트의 성공적인 진행과 무관하지도 않다. 언어는 언어 마다의 특징이 있고 잘 어울리는 분야가 있을 수 있다. 또한 각 언어의 특징과 장점을 잘 이해하면 다른 언어의 이해도도 높아지는 부수적인 효과도 누릴 수 있다. 개인으로 봐서는 능력이 향상되는 효과가 있는 셈이다.
하지만 일부 (신입?) 개발자들은 여전히 보수적으로 행동한다. 다른 언어를 한번 써 보자고 이야기 하면 바로 거부한다. 나만 새로운 언어를 공부한다는 것에 부담이 덜한 것일까?
프로그래머의 중요한 도구 중 하나는 버전 관리 시스템이다. CVS든 SVN이든 GIT이든 목적은 비슷하다. 버전 별로 소스를 관리하고 통합 관리를 해 주고 팀 작업을 수월하게 해 준다.
그런데, 가끔 이런 것을 부정하는 개발자 들이 있다. 이들의 논지는 간단하다.
하지만, 왜 어째써 이런 버전 관리 시스템을 사용하면 얻을 수 있게 되는 잇점을 얻으려 하지 않는 걸까? 왜 도전하지 않으려 하는 걸까?
한 때 약간 혼을 내주기 위해 이들에게 특정 버전의 소스 코드를 요청한 적이 있다. 쩔쩔멜거라고 예상하며 실실거리고 있는 나에게 (내가 S였다니!) 그들은 놀랍게도 1시간 만에 소스코드를 보내왔다. 생각보다 빨랐다. 내가 뭔가 잘못 생각하고 있는 걸까?
하지만 릴리즈 하지 않은 버전을 요구하자 단번에 '없다'라는 답변이 돌아온다. 그래 바로 이거지. 후후후... -_-;;
더 쓰고 싶은 불평불만도 많지만 여지까지만 정리한다.
여기서 중요한 단어는 역시 '귀찮음'이다. 귀차니즘은 위대하다. 귀차니즘은 사람의 삶을 결정하기도 한다.
그런데, 만약 이런 식으로 행동하거나 생각하는 신입 개발자를 면접에서 보고있다면 과연 어떤 결과를 내리게 될 것인가?
나 조차도 변화나 도전은 좀 겁을 내는 경향이 있다. 하지만 어느 순간 약간씩 도전해 보면서 얻기도 하고 성취하기도 하고 보람을 느끼기도 하고 실패하기도 한다.
별 의미는 없겠지만 이런 저런 불평불만을 글로 한번 남겨볼까 한다.
이 글의 주제는 '무적의 귀차니즘' 이다
...
팀 내에서 멋대로 형상관리(Issue Tracker)시스템을 도입하고 이를 팀원들에게 강요했던 적이 있다. 이 시스템은 프로젝트의 설계나 디자인에서 부터 문제점이나 개선 사항을 관리 할 수 있게 해 주는 요긴한 툴이다. 당연히 있으면 좋다고 생각될 것이다.
하지만 팀원들의 반응은 싸늘했다. 대기업 하청을 통해 시스템의 불합리성(?)과 귀찮음(?)을 경험한 개발자라면 어느 정도 이해를 한다. 하지만, 그 합리성을 모르는 신입 개발자들 또한 귀찮다는 이유로 거부하는 것을 보게 되었을 때 내가 틀렸나 라는 생각만 들었다.
대기업 하청 이야기에 대한 보조 설명: 하청을 통해 업무를 하게 될 때는 아마도 필히 형상관리 시스템을 통해 자신들의 업무를 관리해야 한다. 그래야 갑이 알 수 있으니까. 하지만 문제는 이게 책임소재가 된다는 점이다. 글자 하나 잘못 썼다가 엄청 투박 당하고 다른 사람들의 트래킹에 무한정 대기하게 되는 불합리한 업무 진행을 받게 된다면 아마도 이런 시스템에 질릴 것이다. "커밋 승인 받기 전 까지 대기" 라는 말을 들어봤는가? "오늘 내로 등록된 모든 버그 확인하고 잡아" 라는 말을 들어봤는가? 형상관리 시스템이 아니라 이로 인해서 다른 스트레스를 받게 되기 때문에 형상관리 시스템이 싫어지는 현상이다.하지만 문제는 여기저기서 터졌고 터지고 있고 터질 것이다. 대표적인게 서로 누구의 말이 맞느냐를 따질 때의 싸움 같다. 누군가 무엇을 어떻게 수정하라고 했는데 다른 사람은 다르게 수정했다. 이 두 사람 중 누구의 말이 맞을까?
이럴 때 이슈 트래커에 이슈를 등록해 놓고 관리해 왔다면 이런 문제가 발생 할 여지는 크게 줄어든다. 그런데 왜 이걸 이용하지 않으려 하는 걸까? 그러면서도 여전히 싸움을 벌이고 있다. 이제는 강요도 지친다.
이로 인해 생기는 또다른 문제가 있다면 내가 형상관리를 도입해 놓고도 사용하지 않게 된다는 점이다. 나 혼자 사용해 봤자 아무도 안보니까 결국 쓸 필요가 없는 것이다.
역시 이런 시스템은 모두에게 강제해야 쓰게 될 것 같다.
...
프로그래머에게 있어 프로그래밍 언어는 지식이자 힘이자 능력이자 도구이다. 그렇기 때문에 언어의 변화를 거부하는 개발자도 제법 되는 듯 하다.
프로젝트의 언어를 바꿀 것을 요구하는 것은 세심하게 해야 할 부분이다. 언어가 바뀌면 사람에 따라 능률과 결과가 완전히 달라질 수 있고 심하면 프로젝트 진행이 처참해 질 수 있다.
하지만 언어를 바꿈으로써 얻게 되는 점도 물론 존재한다. 프로젝트의 성공적인 진행과 무관하지도 않다. 언어는 언어 마다의 특징이 있고 잘 어울리는 분야가 있을 수 있다. 또한 각 언어의 특징과 장점을 잘 이해하면 다른 언어의 이해도도 높아지는 부수적인 효과도 누릴 수 있다. 개인으로 봐서는 능력이 향상되는 효과가 있는 셈이다.
하지만 일부 (신입?) 개발자들은 여전히 보수적으로 행동한다. 다른 언어를 한번 써 보자고 이야기 하면 바로 거부한다. 나만 새로운 언어를 공부한다는 것에 부담이 덜한 것일까?
...
프로그래머의 중요한 도구 중 하나는 버전 관리 시스템이다. CVS든 SVN이든 GIT이든 목적은 비슷하다. 버전 별로 소스를 관리하고 통합 관리를 해 주고 팀 작업을 수월하게 해 준다.
그런데, 가끔 이런 것을 부정하는 개발자 들이 있다. 이들의 논지는 간단하다.
- 귀찮다.
- 시간이 든다.
- 공부할 시간도 필요하다.
- 코드 공유는 메일이나 네트워크 공유 같은게 있다.
- 백업도 그냥 복사해 두면 된다.
하지만, 왜 어째써 이런 버전 관리 시스템을 사용하면 얻을 수 있게 되는 잇점을 얻으려 하지 않는 걸까? 왜 도전하지 않으려 하는 걸까?
한 때 약간 혼을 내주기 위해 이들에게 특정 버전의 소스 코드를 요청한 적이 있다. 쩔쩔멜거라고 예상하며 실실거리고 있는 나에게 (내가 S였다니!) 그들은 놀랍게도 1시간 만에 소스코드를 보내왔다. 생각보다 빨랐다. 내가 뭔가 잘못 생각하고 있는 걸까?
하지만 릴리즈 하지 않은 버전을 요구하자 단번에 '없다'라는 답변이 돌아온다. 그래 바로 이거지. 후후후... -_-;;
...
더 쓰고 싶은 불평불만도 많지만 여지까지만 정리한다.
여기서 중요한 단어는 역시 '귀찮음'이다. 귀차니즘은 위대하다. 귀차니즘은 사람의 삶을 결정하기도 한다.
그런데, 만약 이런 식으로 행동하거나 생각하는 신입 개발자를 면접에서 보고있다면 과연 어떤 결과를 내리게 될 것인가?
댓글