[B급 프로그래머] (Quora) 나쁜 소프트웨어 엔지니어의 특성은?

Quora에 다음과 같은 질문이 올라왔다.

What are the characteristics of a bad software engineer?

한글로 번역하자면, "나쁜 소프트웨어 엔지니어의 특성은?"

인기를 끈 대답을 정리해보았다

1. StackOverflow 봇: 이 친구는 오류를 만나면 잽싸게 구글 검색을 열어 발견한 첫째 대답을 적용한다. 여기서 문제는 스택오버플로우에서 복사하는 행위가 아니다. 어떤 참조 문헌이나 매뉴얼보다 스택오버플로우에 많은 해법이 있다고 생각한다. 오해하지 말기 바란다. 스택오버플로우는 최고는 아니지만 좋은 자원이니까. 문제는 추이를 생각하지 않고 복사기처럼 행동하는 데 있다. 현재 풀려는 문제에 적용할 수 있을지 맥락을 완전히 이해하지 않은 상태에서 섣부르게 응용하면 문제가 생긴다. 종종 직접 확인한 내용이 아니라 온라인 포럼에서 본 내용을 더 신뢰하는 사람들을 목격해왔다.
2. 저는 테스터가 아닙니다: 코드를 테스트할 필요가 없으며, 이런 작업은 테스터 몫이다. 성숙한 애자일 방법론의 시대에도 이런 태도가 줄어든다고 생각하지 않는다. 여전히 코드를 테스트하는 작업에 대항하는 타성이 존재한다. 테스트 환경 설정에 무관심하거나 테스팅에 대한 논리 정연한 지식 부족 때문이라 생각한다(개발 공통체에서 테스터에게 뒤집어 씌운 오명도 일부 원인이긴 하다).
3. 문서화를 싫어합니다: 몇몇 개발자들은 코드 문서가 문학이라 믿기에 이런 기술이 부족하다고 생각하며, 따라서 자신들의 일이 아니라 여긴다. 내 의견에 따르면 이런 생각은 지속적인 소프트웨어의 주적이다. 훌륭한 소프트웨어는 백만 가지에 이르는 좋은 기능을 제공하는 데 있지 않다. 훌륭한 소프트웨어는 많은 사람들이 일관성있게 사용 가능한 몇 가지 좋은 기능을 많은 개발자들이 읽고/수정하고/갱신할 수 있어야 한다. 이런 훌륭한 소프트웨어 개발자들은 기술적인 의사소통 보다는 정확하고 상세한 문서화가 회사의 성공에 가장 큰 버팀목이 되리라 믿는다.
4. 동작하지만 보기 흉한 코드: x, flag, str, arr과 같은 변수 이름, 모든 것을 다 넣은 거대한 메소드, 코딩 관례나 스타일의 일관성 부재, 들여쓰기 부재, 전역 변수(다이아몬드 목걸이가 타이타닉 잔해에 묻혀 있다면, 어느 누구도 찾지 못하고, 깨끗하게 씻지 못하고, 착용하지 못하고, 사용하지 못할 것이다.)
5. 단기 투자가: 코드를 만들고 배포하고 다음으로 넘어간다. 문제를 배우려는 시도는 없다. 업무 영역에는 관심도 없다. 단순히 코드만 주면, 밤새 묵묵하게 일한 다음 완성해서 넘길 것이다. 소프트웨어를 수정하고 만든다. 여기서 어떤 업적도 달성하지 못한다. 종종 개발자의 이기적인 태도가 중요하지만, 마감일 뿐만 아니라 개발 과정에서 무엇을 얻을지도 신경써야 한다.
6. 시위자: "저는 이 일은 안 합니다.", "나쁘게 보이네요.", "제 문제가 아닙니다." "제 수정과 관련이 없고, 저기 누군가 실수를 했습니다.", "싫다구요!(하루에 10번 이상 반복한다)", "이 문제는 제가 수정할 수 없습니다. 만든 사람에게 시키세요."
7. 독재자: "협조하거나 꺼지거나"가 모토다. "자신들의 아이디어"와 "당신의 아이디어"만 있고 "프로젝트 아이디어"는 없다. "자신들의 해법"이거나 "당신의 해법"뿐이다. 이런 사람은 생산성에 있어 큰 병목이며, 압력하에 바스러지거나 남을 비난하기 시작할 첫 사람이다. 개발자로서 경험이 있고 좋을지는 몰라도 함께 일하는 팀에 있어 좋은 사람은 아니다.
8. 지나치게 조심하는 개발자: 파이썬 스크립트를 작성해야 한다는 사실을 알았을 때 멘붕이 온 자바 개발자가 있다. 레지스트리 변경이 필요하다는 사실을 알았을 때 공포에 질린 개발자가 있다. 데이터베이스에 뭔가를 입력해야 한다는 사실에 당혹해하는 개발자가 있다. 이런 개발자들은 안락한 영역에서 벗어나지 않기 위해 뭐든 할 것이다. 이런 개발자들에게는 시스템의 특정 영역을 건드리는 작업과 관련해 기묘한 미신이 있다. 개인적인 경험에서 보면 새로운 개발자에게 흔히 보이는 현상이며, 좋은 개발자들은 탐구 과정에서 차근차근 이런 안락한 영역으로부터 벗어나려는 경향을 보인다.
9. 부주의: 백업과 스냅샷에 신경쓰지 않으며, 코드를 여러 작업 디렉터리에 분산하며, System.out.println을 상용 코드에 남겨 둔다. 새로운 개발자에게 흔히 보이는 현상이며, 전문적인 환경을 접하면 나아진다.
10. 게으른 가짜 해커: 시스템을 동작하게 만드는 트릭에 자부심을 느낀다. 완벽한 해법을 위한 마법을 찾는다. 경험에 따르면 이는 십중 팔구 빚좋은 개살구다. 가짜 해킹은 나쁘며, 조만간 망가지며, 수습에 더 많은 비용과 시간이 든다.

자, 그렇다면 여러분들이 뽑은 나쁜 소프트웨어 엔지니어의 특성은 어떤가? 댓글로 공유하면 감사하겠다.