마감에 맞춰 코드 품질을 떨어뜨려 승진하게 되면 이력서에 뭐라고 말해야 할까요?
저는 몇 주 전 회사 경영진이 제안해 정규직으로 키우기 전까지 12개월 계약(신입 개발자들에게는 이런 일이 흔치 않은 나라에 살고 있습니다)을 하고 있었습니다. 저는 이력서를 항상 최신 상태로 유지하는 것을 좋아하기 때문에(특히 COVID가 있는 경우), 이력서에 기재하는 것을 검색했습니다.
제가 찾은 조언은 일반적으로 고용을 촉진한 것이 어떤 업적이었는지 나열해야 한다는 것이었습니다. 그럴 만도대체로.
문제는 이 성과는 항상 클라이언트의 납기에 맞춰져 있었다는 것입니다.솔직히 저는 (경영진이 동의한) 대상 케이스에서는 엔지니어링의 우수성이 떨어질 수 있다고 판단하고 이 작업을 수행했습니다.
저는 6명의 개발자로 구성된 팀에서 비교적 후배입니다. 그러나, 저는 그것을 전달하고 거기에 도달하기 위한 상대적인 트레이드 오프를 그들에게 계속 알려주겠다고 말할 때, 개발 관리직이 가장 많이 신뢰하는 사람 중 한 명이 되었습니다. 제가 이곳에 온 지 얼마 안 된 시간 동안, 저는 발송할 수 있다고 하면 항상 무언가를 발송할 수 있었습니다.
저는 이런 경우가 몇 번 있었지만, 정규직 제안을 받기 직전에 한 일입니다. 저희 제품 중 하나는 1일 1회 클라이언트에 의해 호출되는 배치 API입니다. 이메일로 실패한 엔트리의 CSV를 제외하고 아무것도 반환할 필요가 없습니다. 그들은 새로운 기능을 추가하기를 원했고, 영업사원은 계약상 이달 말까지 그 기능을 제공하기로 합의했습니다. 여러 가지 이유로, 그 기능 요청은 그 달의 마지막 주 월요일까지 저희에게 전달되지 않았습니다.
선임 개발자는 매니저에게 개발이 제대로 되지 않는다며 고객에게 불가능하다고 말하라고 했다. 스프린트 기획회의에서는 선임병들을 반박하지는 않지만 선배와 반대한다는 것은 분명했을 것이다. 동의하지 않는 건 아니지만, 특정한 트레이드오프와 함께 선택권이 존재했어요. 다른 개발자들 또한 상당히 소극적이어서 아무도 그를 반박하지 않았다. 매니저는 우리가 약속했을 때 배달하지 않은 것에 대해 고객이 이미 화가 났기 때문에 이 일에 대해 달가워하지 않았습니다. 그리고 나서 매니저는 미팅이 끝난 후 나를 그의 사무실로 불러 다른 대안이 있는지 물었다. 나는 그에게 뭔가 일을 할 수 있다고 말했지만, 나는 특별한 SQL 스킬이 없기 때문에 API 처리 시간이 2배(4분 추가)가 될 것이다. 매니저도 동의했고 고객도 눈치채지 못한 것 같았다.
납기를 놓치면 어떤 결과가 초래될지 모르겠지만, 1000명 회사의 대표이사가 저에게 감사 메일을 보낼 정도로 매우 가팔랐습니다.
또 다른 케이스는 그다지 주목을 끌지 못했지만 데이터베이스 상에서 실행해야 할 프로세스가 있었습니다. 올바른 방법은 우리가 사용하는 메가 Java 시스템에 적절한 배치 프로세스를 작성하여 모든 일반 QA 프로세스를 통해 전송하고 2주 후에 종료되도록 하는 것입니다. 매니저에게 Python 스크립트를 제공했습니다.이 스크립트는 수동으로 실행해야 하고, 매우 비효율적입니다(밤새에 실행해야 합니다).하지만 한 달에 한 번 트리거되면 영구적인 수정이 도착할 때까지 문제를 회피할 수 있습니다. 이것은 생산상의 문제이기 때문에 그는 임시방편으로 그것에 동의했습니다. 이것은 기본적으로 특정 유형의 오류 데이터를 행에 체크하고 다시 포맷하는 루프에 대한 비용 절감에 불과했습니다.
선배를 깎아내리는 해킹 프로그래머처럼 보이지 않는 이런 것들을 이력서에 적는 방법은 없을까. 제 솔루션이 기술적으로 타당하지 않다는 것은 인정하지만, 그 당시 비즈니스 요구에 적합한 솔루션이었고, 비효율적인 균형은 대부분의 경우 무관했습니다.
과도한 엔지니어링을 하지 않고 문제를 해결할 수 있는 몇 가지 효과적인(효율적이지 않은) 방법을 발견했습니다.완성이 완벽보다 낫다"
충분히 좋은 솔루션을 찾는 것은 엔지니어에게 중요한 능력입니다.그렇지 않으면 최적화할 가치가 없는 것을 최적화하는 데 많은 시간을 소비하게 되기 때문입니다. 자주 사용하지 않으면 최적화할 가치가 없는 경우가 많습니다. XKCD-Comic 1에는 투자 시간을 나타내는 표가 있습니다.
솔루션은 사용(또는 사용할 수 있는) 경우에만 가치가 있습니다.따라서 해킹을 통해 고객은 솔루션을 얻을 때까지 작업을 계속할 수 있었습니다.
상사와 의견이 다르다고 아무에게도 말할 이유가 없습니다. 그냥 " 같은 걸로 해.시간적 압박 속에서 효과적인 솔루션을 생성할 수 있습니다."
당신은 한 가지 일을 했습니다. "그 일을 해결할 수 있는 시간 내에 실행 가능한 솔루션을 찾아보세요" 그리고 그게 바로 네가 한 일이야
속담에도 있듯이 "완벽은 좋은 것의 적입니다.비즈니스 요구를 만족시키기 위해 기술적인 타협을 하는 것은 매우 어려운 일입니다. 좋은 개발자/프로그래머/엔지니어는 가능한 적합한 트레이드오프를 식별할 수 있는 사람입니다.
API의 예에서 고객은 정상적으로 동작하고 제시간에 배송된 것에 대해 처리 지연을 4분 정도 받아들이는 경향이 분명히 있었습니다.
이러한 타협을 할 때는 기술적인 부채를 최소화하는 것이 이상적이지만, 장기적으로 시간을 절약하기 위해 시간을 단축할 수 있는 부분과 시간을 단축할 필요가 있는 시간을 아는 것이 가장 중요합니다.
CV를 참조하면 솔루션의 세부 사항을 설명할 필요가 없습니다.시간상 중요한 프로젝트의 납기를 잘 지켰다고만 하면 됩니다.실제 구현에 대한 자세한 내용은 기재하지 않고 예를 들 수 있습니다.
당신이 하는 일은 "해킹"이 아니라 "해결책 찾기"입니다.
저는 20년 전부터 개발자와 컨설턴트로 일하고 있습니다.***는 고용주가 원하는 기술입니다. 이력서에서 빼놓지 말고, 정확히 다음과 같이 강조하십시오. 당신은 그것이 "비정상"의 길을 간다는 것을 의미하더라도 해결책을 찾으려 한다.
상급 개발자의 뒤에서 그렇게 한다고 쓰지 말고, 경험이 많은 사람이 동의하지 않거나 불가능하다고 해도 해결책을 요구받을 때마다 그렇게 한다고 써주세요.
알버트 아인슈타인의 말을 인용하면 당신의 상황을 정확히 알 수 있습니다.
저는 많은 개발자들과 함께 일했습니다. 그리고 저는 이것의 모든 측면을 알고 있습니다.
Stackoverflow에서 상위 1%의 JavaScript 전문가에 속하는 개발자와 함께 작업했습니다. 그는 천재이고 나는 그가 쓰는 코드 한 줄 한 줄에 정말 감탄한다. 그러나 그는 종종 그의 프로젝트를 끝내지 못했다. 그는 코드의 아름다움에 만족하지 못할 때 끝내느니 차라리 끝내지 않으려 했다.
또한 매우 효율적인 개발자와 함께 작업했지만, 솔루션을 거의 유지할 수 없는 지름길(하드코드화된 경로, 매직넘버 등)을 많이 사용했습니다.
그리고 저는 항상 "done""""보다 "done"을 선호했고, 결국 제 고객들도 그러했습니다. 그들은 마감일이 다가오면 아무 것도 없겠지만 앞으로 더 아름다워질 것이다.
단 한 가지: 회피책 / 바로가기 / "hacks"는 이해하기 쉽고 문서화되어 유지보수가 가능해야 합니다.그러면 귀사와 같은 솔루션에는 아무런 문제가 없습니다.