Dev로서 내가 내리는 가장 어려운 3가지 결정 (코드와는 무관)

Source: Dev.to

Deciding Which Problem to Solve (The Product Dilemma)

불편한 진실이 있습니다. 자신의 장인 정신을 사랑하는 모든 프로그래머를 괴롭히는 진실이죠: 우리는 코드를 쓰는 것을 사랑하지만, 코드 작성이 항상 제품이 필요로 하는 것은 아닙니다.

제가 처음 배운 주요 결정은 기술적인 선택을 뒤로 미루는 것이었습니다. 처음에는 가장 기술적으로 흥미로운 문제—레거시 모듈 리팩터링, 초복잡 아키텍처 구현, 혹은 밀리초 단위로 실행되는 함수를 최적화—를 해결하고 싶어합니다. 실제 세계에서는 가장 어려운 결정이 백로그를 바라보며 스스로에게 묻는 것입니다:

“이게 지금 바로 실질적인 가치를 제공하나요?”

때로는 올바른 결정이 비즈니스 가설을 빠르게 검증하기 위해 기술적으로 “지루하고” 단순한 일을 하는 것입니다. 제품 비전이 기술적 열정을 앞서야 한다는 것을 받아들이는 것은 고통스럽지만 필수적입니다.

Lesson

코드는 목적을 달성하기 위한 수단일 뿐입니다. 완벽한 솔루션을 프로그래밍하지 않고, 필요한 솔루션을 만든다는 결정이 주니어와 시니어를 구분합니다.

An Important Distinction

“완벽하지 않은” 솔루션을 제공한다는 것이 나쁜 코드를 짜거나 복잡하고 읽기 어려운 로직을 만든다는 뜻은 아닙니다. 실제로 가장 단순한 해결책이 가장 찾기 어려운 경우가 많습니다. 장기적인 품질을 유지하면서 단순화하는 능력이 비전을 가진 개발자와 그렇지 않은 개발자를 구분합니다.

Deciding When to Ask for Help (Balancing the Ego)

이것은 매일 마주하는 위험한 결정입니다. 복잡한 작업에 막히면 시계가 당신에게 불리하게 돌아가기 시작합니다. 끈질김과 고집 사이에는 거의 보이지 않을 정도로 가는 선이 있습니다.

• 너무 일찍 요청: 충분히 시도하지 않았거나 “절박하다”는 인상을 줄 수 있습니다.
• 너무 오래 기다림: 회사의 비용을 소모하고 전달을 미루게 됩니다.

“막혔어요”라고 손을 들어 말하는 결정은 자존심을 삼켜야 합니다. 저는 이 결정을 시간 박싱(timeboxing) 기반으로 내리게 되었습니다: 문제를 해결하기 위해 정해진 시간을 스스로에게 주고, 진전이 없으면 도움을 요청합니다.

이는 무능력 때문이 아니라 효율성 때문입니다. 이미 시도한 내용과 가설을 설명하면서 올바른 방식으로 도움을 요청하는 것은 약점의 순간을 책임감의 시연으로 바꿔줍니다.

Deciding “How Long Will This Take?” (The Art of Estimation)

아마도 모든 스탠드‑업이나 계획 회의에서 가장 두려운 질문일 것입니다: “이 작업에 얼마나 걸릴까요?”

이 질문에 답하는 것은 추측이 아니라 약속에 대한 결정입니다. 처음에는 완벽한 시나리오—버그도 없고, 방해도 없는 상황—에 기반해 마감일을 잡았습니다. 스포일러: 그런 시나리오는 존재하지 않습니다. 여기서의 결정은 알려지지 않은 부분을 위한 안전 마진을 포함시켜 기대치를 관리하는 것입니다.

마감일을 정한다는 것은 실제로 주어진 시간에 제공할 수 있는 품질과 범위 수준을 결정하는 것입니다. 저는 짧은 마감일로 인상을 주려다 나중에 지연을 설명해야 하는 것보다, 더 긴 마감일을 약속하고 일찍 전달하는 것이 더 낫다는 것을 배웠습니다.

Conclusion

이것이 제가 겪은 세 가지 가장 큰 결정이었습니다. 여러분은 어떤 결정을 내리셨나요?