티스토리 뷰

728x90

프로페셔널리즘

개발 조직 전체에 대한

팀 또는 조직에 도움이 될만한 이야기

계획, 전략, 태도, 원칙 등을 여러 가지 관점에서 조언했다.

 

테스트 주도 개발(TDD) 진행 방법

빠듯한 일정에 대응하는 방법

채용 공고 작성법 & 개발자 채용 인터뷰

동료나 관리자와의 협업 방법

 

멘토

커리어 방향과 개발자로서 스스로의 역량과 태도를 되돌아볼 수 있는 거울이 되리라 확신한다.

해법과 단초를 찾을 수 있을 거라 믿는다.

 

세 시간짜리 기술 시험

흥미로운 일들을

코딩이 직업인 사람이 동작하는 코드를 만드는 건 기본이에요.

코드를 같이 볼 거니까 가까이 오세요.

여기서 메모리 할당/해제를 하면 무슨 일이 일어나는지 알고 있나요?

이런 코드는 잠재적으로 메모리 릭을 일으켜요.

좀더 생각해보면 이 여덟 줄은 두줄로 줄일 수 있어요.

try/catch 블록이 이렇게 크면 어떤 일이 일어날 수 있는지 알고 있나요?

이 변수와 메서드의 이름은 적절해요?

원래 의도한 의미가 뭐죠?

다른 동료가 이 코드를 수정할 일이 생기면 어떻게 될까요?

전후 정보가 아무것도 없는 상태에서 당신이 이 코드를 유지보수해야 한다면 어떻겠습니까?

여기에 하드 코딩된 비트들은 뭐죠?

이 값들은 수정할 때마다 소스 코드를 열어서 수정하고 다시 컴파일 하고 전체 애플리케이션을 재배포해야만 하나요?

여기저기 똑같은 코드들이 있죠?

작게 만들고 동작 내용에 맞춰서 네이밍을 하면 어떨까요?

 

이 코드가 얼마나 무례한지 알고 있습니까?

난해한 코드를 만들면 코드를 이해하기가 얼마나 어려워질지 생각해봤나요?

내가 한 말들을 다 이해했나요? 모두 동의합니까?

이 코드들을 더 나은 쪽으로 바꿀 수 있겠어요?

오늘 이야기한 것들을 앞으로도 계속 적용할 수 있겠지요?

좋습니다. 아직 3일이나 남았으니 다시 해보세요.

일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다.

 

내게 시간을 들여 좋은 코드를 만드는 방법을 보여 주는 사람을 찾았다는 사실을 깨달았다.

다른 사람들이 성장할 수 있도록 진심으로 도와주는, 

나보다 더 나은, 훨씬 다양한 경험이 있는 누군가를 찾았다.

더 훌륭하고, 더 높은 품질의 소프트웨어를 만드는 데 가치를 두는 사람을 찾았다.

나를 가르치는 데 기꺼이 시간을 투자하는 사람을 만났다.

무엇보다도 나의 첫 번째 멘토를 찾았다.

 

나 자신이 그렇게 잘난 사람이 아니라는 것과 배워야 할 게 아직 많음을 알았다.

그리고 겸손해져야 한다는 것도..

나의 동료와 클라이언트를 존중하고, 형편없는 코드를 남겨서는 안 된다는 것을 알았다.

 

자신의 일을 대하는 태도

일을 어떻게 했느냐는 일을 해낸 것만큼이나 중요하다.

그 말은 나를 더 나은 프로페셔널로, 더나은 인간으로 만들어 주었다.

 

좋은 개발자를 채용하는 방법도

익스트림 프로그래밍(XP)

애자일, 린(lean) 원칙들과 시너지를 일으켜 소프트웨어 업계를 한 단계 도약시킬 수 있다.

 

최선을 지향하는 습관

당위성

우정 & 조언

지원 & 격려

노력하면 꿈을 실현할 수 있음을 보여준 그분께 깊은 감사를 드린다.

 

영어실력을 키우는 것

테스트 주도 개발 방법론(Test-Driven Development: TDD)

도메인 기반 디자인(Domain-Driven Design: DDD)

애자일

XP

정치

실용주의

프로페셔널리즘에 대해서도 여러 가지 알려 주었다.

 

===========================================================================

 

네 종류의 개발 언어

난해한 코드

이해하지 못한다면 아직 숙련이 덜 된 거

아무도 이해할 수 없는 코드를 짤 수 있다면 즉시 고급 개발로 인정받을 수 있었다.

`코더`가 아닌 `소프트웨어 아키텍트`가 되고 싶었다.

 

얼마 후 승진을 하면서 아키텍처 팀

개발자들이 따라야만 하는 디자인 패턴 북

GoF(Gang of Four, Design Patterns)

UML

오버 엔지니어링

 

그 당시에는 아키텍트의 혜안

개인 시간을 들여서라도 어떻게든 부족함을 메워야 했다.

나는 다시 개발팀으로 돌아갔고 코딩의 즐거움도 되찾았다.

 

장기적인 예측과 계획은 시간 앞에 허망하게 빗나갈 때가 많았다.

매일 코드를 작성하는 일은 행복

아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.

코딩에서 손을 뗀 기간이 길면 길수록 다시 손에 익히기가 어려워진다.

 

정리하면 커리어 패스를 정할 때는 내가 열정이 있는 것

진정 즐겁게 할 수 있는 것을 따라야 한다는 것이다.

아키텍트든, 개발자든, 테스터든, 비즈니스 분석가든, 관리자든 상관없다.

모든 역할이 필요하고 중요하다.

 

5년 정도 일했다고 해서 고참 배지가 주어지지 않는다.

상대적이라는 이유는 어떤 기술, 어떤 맥락에서, 누구와 비교해야 하는지 알아야만

고참인지 여부를 결정할 수 있기 때문이다.

 

코딩은 개발자가 해야 하는 많은 일들 중에 하나일 뿐이다.

코딩을 잘 하거나 특정 언어나 프레임워크에 매우 익숙하다고 해서 고참 개발자가 되는 것은 아니다.

 

고객과 대화하기

테스트/배포 자동화하기

비즈니스에 영향을 미칠 기술 선정하기

협업하기

고객을 도와 필요한 작업을 정의하기

우선순위 선정

진척상황 보고

변경사항과 기대일정 관리

변경상황과 기대일정 관리

제품 소개

사전 영업활동 지원

개발일정 & 비용산출

채용면접

아키텍쳐 설계

사업 목표 이해

최적의 결정

새로운 기술

더 나은 업무 방식

가치있는 상품이 전달되고 있는지 고민

 

기업들은 더 작아지고 기민해지며 조직 계층 구조도 평탄해지고 있다.

여러 방면에 조예가 있는 사람들로 바뀌고 있다.

 

피드백 루프를 신속하게 수행하는 린 스타트업(Lean StartUp) 모델이 경쟁 방식을 완전히 바꾸어 놓았다.

배포된 애플리케이션에 버그가 있으면 기업 이미지에 큰 타격을 주거나 기업의 존폐를 위협할 수도 있다.

소프트웨어 개발자의 권한 영역이 더 넓어지고, 책임은 더 무거워지고 있다.

자부심 & 원동력 & 재평가

 

소프트웨어 업계에 영향력이 있는 17명

익스트림 프로그래밍(eXtreme Programming: XP)

동적 시스템 개발 모델(Dynamic System Development Model: DSDM)

적응형 소프트웨어 개발

크리스탈

피처-드리븐 개발(FDD)

실용주의 프로그래밍과 같은 방법론과 테크닉들이 발표되었다.

 

애자일(Agile)

회의방식

구성원 각각의 역할

요구사항 파악 방법

작업 진척 속도 파악 방법

점진적/반복적으로 일할 때 취하는 방식

올바른 목표를 향해 진행 중

 

테스트 주도 개발(TDD)

페어 프로그래밍

지속적인 통합

단순한 디자인 원칙

목표를 올바르게 실행하고 있는지

 

민첩(Agile) 애자일을 실행하고 있는 것은 아니다.

빠르고 짧은 피드백 루프에 대한 것이다.

특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다.

 

섣부른 과잉 설계(Big Design Up-Front: BDUF)

우선순위를 매긴 작업 백로그(해야 할 업무 목록)

누가, 어떻게, 어떤 일정으로 수행할지를 정한다.

점진적, 반복적인 절차로 팀 구성원 모두에게 피드백이 가는 환경

 

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.

 

애자일 매니페스토

1. 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선

2. 막바지 단계이더라도 고객의 요구사항 변경을 환영한다.

3. 자주 전달한다. 가능한 한 전달주기를 짧게 한다.

4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.

5. 동기 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.

6. 얼굴을 마주보고 대화

7. 동작하는 소프트웨어

8. 속도를 계속 수용할 수 있어야 한다.

9. 기숙적인 탁월함과 좋은 설꼐에 대한 지속적인 관심은 기민함을 높인다.

10. 단순함

11. 최선의 아기텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. (고민 & 고민)

12. 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

 

스토리를 정의/분할하고,

작업 일정을 추산하고,

우선 순위 결정에 참여하고,

구현된 기능을 시연

 

팀 구성원이 단합하고 공동의 목표를 갖도록 한다.

문제를 드러나게 하는 것뿐만 아니라,

피드백 루프 매커니즘을 제공

 

애자일 전환

번-다운 차트

백로그

릴리즈 백로그

 

설계도 잘못되었고 복잡한 데다가 버그도 많다.

정체된 개발자 역량,

낮은 수준의 동기부여,

잔뜩 쌓여 잇는 기술적 부채,

기술적 전문성 부족,

신뢰할 수 없는 릴리즈 절차,

불안정한 시스템,

늦은 버그 발견,

신뢰할 수 없는 데다가 비싼 테스트,

비효율적인 개발/디버깅/배포 주기

 

기술적인 훈련에는 관심을 크게 두지 않는다.

즉 개발자의 역량을 키우는 데는 도움이 안 된다.

개발자들은 이미 훌륭하고 절차만 개선하면 된다.

코딩은 쉽다.

코딩은 그냥 지엽적인 세부 사항일 분이다.

우리는 더 나은 절차만 있으면 된다.

불행하게도 결코 그렇지 않다.

 

애자일의 배경이 되는 기본 원칙이 잊혀졌다.

기술적 탁월함보다 절차가 더 중요해졌다.

품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.

 

피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고 뭔가 잘못되고 있거나

더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다.

 

애자일 선언의 진정한 의미를 이해한 애자일 코치는 절차뿐만 아니라 기술적 탁월함도 강조한다.

반면에 수준 이하의 애자일 코치는 스스로의 기술적 역량이 부족하여 절차적인 면만 강조하고

기술적 측면을 전혀 언급하지 않아 고객을 잘못된 방향으로 이끌기 쉽상이다.

 

교육이 필요하다.

새로운 기술과 실행 관례를 배우는 데 열정적이고 마음이 열린 개발자를 채용하는 것을 고려해야 한다.

다이어그램과 문서를 작성하는(코딩을 안하는) 테크니컬 리더

어떤 역량이 있는지도 모르는 개발자들한테 맡기고서는 모든 요구사항을 충족하는 소프퉤어가 짠 하고 나타날 거라고 정말로 믿는 것인가?

 

애자일 절차를 포함해서 모든 소프트웨어 절차들은 기술적 탁월함을 기본 배경으로 가정하고 있다.

짧은 피드백 루프는 기업이 기민해지기 위한 핵심 요소다.

피드백에 빠르게 반응함으로써 진정으로 민첩해질 수 있다.

최고의 개발자들이 있더라도 그들이 제대로 일할 수 있는 절차가 없다면 마찬가지로 소프트웨어 프로젝트가 성공할 수 없다.

 

일을 이해하고, 우선순위를 정하고, 낭비를 줄이고

권한이양과 동기부여를 하고, 피드백 루프를 만들어 준다.

이것은 기업의 반응속도를 높이고 기민하게 하며, 기업이 올바른 일을 하도록 돕는 것이다.

프로페셔널리즘, 일을 더 잘하기 위해

여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에

코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다.

일을 올바르게 수행하도록 돕는다.

 

기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

프로페셔널 소프트웨어 개발자들이 필요하다.

기술적 실행 관례

기술적 전문성

관련 도구들을 마스터

높은 품질을 유지

완벽하게 테스트되고 쉽게 변경할 수 있는 소프트웨어를 개발할 수 있어야 한다.

 

===========================================================================

 

소프트웨어 장인

 

소프트웨어 개발

도제(연습생)는 숙련된 대장장이 밑에서 일하면서 일을 배운다.

개발자가 스스로 선택한 커리어에 책임감을 가지고

지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다.

책임감, 프로페셔널리즘, 실용주의, 자부심

 

일에 주인의식을 가지고 프로페셔널하게 행동하고,

고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는다.

다른 개발자들에게 배우고 자신의 지식을 나누며,

경험이 부족한 개발자들을 멘토링하는 것

 

스스로의 기술을 연마하고,

다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다.

정교하고 솜씨 있게 만들어진 작품

계속해서 가치

프로페셔널 커뮤니티

생산적인 동반자 관계

 

개발의 수준을 높인다.

경험이 많고 재능있는 개발자들이 겪는 어려움, 추구하는 가치, 열망

부실한 관리, 잘못 정의도니 절차 그리고 형편없는 코드 때문에 프로젝트가 실패하는 일은 없어야 한다.

개발자 스스로가 자신이 하는 일 자체에 얼마나 책임감과 열정이 있는지 보이려는 것이다.

 

정교하며 솜씨 있게 만들어진 작품

클래스와 메서드는 수백 라인, 최악의 경우 수천 라인의 코드로 되어 있다.

 

두려움

잘못된 수정에 대해서는 책임을 져야 하기 때문이다.

 

동작하는 소프트웨어

쉽게 이해할 수 있어야

부작용도 알려져 있어야 하고 관리가 가능해야 한다.

테스트가 가능해야 하고

단순한 디자인 & 비즈니스 용어

비슷한 수준의 개발 공수로 완료

 

소스 코드는 예측가능하고 유지보수될 수 있는 상태

어떤 일이 일어날지

수정 자체가 두려운 상황에 처하지 않도록 해야 한다.

변경사항이 있더라도 그 영향이 해당 기능 모듈에만 국소적으로 제한

자동화 테스트

 

테스트 주도 개발

단순한 디자인

비즈니스 용어로 표현된 코드

코드를 건강하고 잘 만들어진 상태로 유지하는 최선의 방법이다.

 

계속해서 가치를 더하는 것을

목적을 달성시키기 위해 우리가 일하고 있음을 늘 인식

코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고,

테스트 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함한다.

 

보이스카웃에는 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라. (품질)

같은 일을 반복하면서 다른 결과를 기대하는 것은 미친 짓이다. - 앨버트 아인슈타인

오류를 반복 & 악순환을 끊고

 

프로페셔널 커뮤니티

업계를 발전시키는 가장 좋은 방법은

새롭게 참여하는 개발자들에게 영감을 주고 멘토링함으로써 우리가 배운 바를 공유하는 것이다.

 

상대에게 배우는 것은 더 나아지기 위한 최선의 방법이다.

블로그에 글을 올리고, 오픈 소스 프로젝트에 기여하고, 작성한 코드를 공개하고,

 

훌륭한 개발자는 더 뛰어난 개발자와 일하고 싶어 한다.

뛰어난 기업에서 일하기를 갈망한다.

서로를 더 성장시킬 만한 사람들과 함께 일하고 지식을 나누며 상대에게 배우는 것,

서로에게 영감을 주는 프로페셔널이자 친구

 

적극적으로 프로젝트의 성공에 기여해야 한다.

요구사항에 질문하고, 비즈니스를 이해하고, 개선사항을 제안하며,

동기 부여 수준이 높은 팀은 프로젝트를 성공으로 이끌 확률이 상당히 높다.

열정적이고 재능있는 사람들은 성공을 원하고 항상 문제와 관룍주의를 극복할 방법을 찾아낸다.

 

업무절차

선택지를 제공

불필요한 관료주의

도메인

우선순위를 정하고 계획하는 것

스스로의 평판을 닦고 커리어를 완성해 나가는 데는 고객을 선별하는 능력이 뒷받침되어야 한다.

 

유능한 프로페셔널이 좋은 평판으로 이어짐을 이해하고,

프로젝트를 성공적으로 꾸준히 이끌어내 고객을 만족시킨다.

소프트웨어를 장인의 작품으로 여기며 자신의 기술을 마스터하기 위해 모든 노력을 기울인다.

 

===========================================================================

 

소프트웨어 장인의 태도

 

오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면,

그것은 그동안 배운 것이 없다는 뜻이다...

 

스스로가 만든 것에 애정과 자부심

지식을 나누는 것 또한 우리의 직업 윤리적 의무다.

 

네 커리어와 프로페셔널로서의 미래는 누구의 책임인가?

고객을 만족시키기 위한 투자는 스스로 해야한다.

돈 & 시간을 들인다.

그러한 투자를 하지 않으면 고객을 만족시키지 못해 평판이 나빠지고 시장에서 퇴출되는 수순을 밟는다.

 

고객은 프로에게 좋은 서비스 및 최선의 방법으로 문제가 해결되기를 기대하며 대가를 지불한다.

그의 지식과 기술에 대한 돈을 지불하는 것이다.

명확한 해결책이나 좋은 대안을 제시하면 이는 좋은 평판

스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다!

 

고용주의 책임이나 의무라고 생각해서는 안 된다.

기회가 주어진다면 보너스나 상호이득이 되는 배려로 받아들여야 한다.

열정적인 개발자라면 항상 그러한 배려를 제공하는 기업을 일자리로 선택할 것이다.

계속해서 역량을 증진시키는 것은 성공적인 커리어를 위한 열쇠다.

 

여러 업무 중에서도 비즈니스에 기여하고,

해결책에 옵션을 제공하고, 우리가 개발하는 소프트웨어의 기술, 품질, 구현에 최상의 서비스를 제공해야 한다.

 

종이 책이든 전자 책이든 나만의 서재를 갖는 일은 중요하다.

생산되는 정보가 너무나 많은 산업 분야라 어떤 책을 읽어야 할지 선택하기가 상당히 힘들다.

 

기술 & 개념 & 행동양식 & 혁명

특정 주제나 기술을 깊이 이해해야 할 때는 책만한 것이 없다.

실제 경험, 개인적인 발견, 의견, 성공담, 실패담들이 짧게 담겨 있기 때문에

소프트웨어 장이정신이나 애자일 모델에 태생적으로 궁합이 잘 맞다.

 

깊이가 없는 글

단순히 문제 상황만을 글로 남길 수도 있다.

모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다.

경험과 발견을 공유함으로써 훌륭한 프로페셔널 커뮤니티

우리의 배움과 자기계발에 대한 기록의 장

초심자 입장에서 쓰여진 설익은 기록이 그들에게 큰 도움이 될 수도 있다.

개발자들은 무료로 공유한 다른 개발자들의 관점과 생각들에 대해 비판에 앞서서 감사하는 마음을 가질 것이고 그래야만 한다.

 

일을 할 때의 방법은 그 실행 결과만큼이나 중요하다.

훈련 외에 다른 수단은 없다.

해결에 사용한 테크닉에 집중해야 한다.

문제 해결 자체에 대한 대가이지만,

어떻게 해결하는지가 중요하다.

 

몸의 일부인 것처럼

훈련할수록 더 편안해지고 별도의 주의 집중과 의식적인 노력이 없이도 자연스럽게 할 수 있게 된다.

우리가 달성하려는 목표에만 집중할 수 있다.

작성 가능한 최선의 코드를 만드는 데 집중

 

변수, 메서드, 클래스들의 이름을 가장 이해하기 쉽고 의미를 포괄할 수 있도록 최선을 다해 네이밍한다.

소요된 시간이야 어떻든 훌륭한 것

그 훈련이 완벽하도록 노력해야 한다.

이렇게 하다 보면 실제 업무 상황에 부딪혔을 때 해결책을 찾는 데만 집중하면서도 테스트 코드 작성이 자연스럽다.

 

카타는 품세

작은 훈련용 코딩

접근방법을 훈련하는 데 활용

반복훈련

같은 코딩 카타를 반복하더라도,

매번 다른 테크닉,

다른 언어,

다른 기술,

다른 접근 방법

효과를 최대화할 수 있다.

시험하고 비교해 볼 수 있다.

 

펫(pet) 프로젝트

취미생활과도 비슷한 나만의 소프트웨어 프로젝트

내가 바로 사장

가장 먼저 문제 도메인을 이해하고

기술적인 결정을 내리고 코드를 작성한다.

 

시험하고,

발견하고,

배우고,

즐길 수 있는 기회

 

미리 경험

프로젝트 아이디어

백로그에 할 일들을 정리하여 준비

작업을 분할

우선순위를 생각

일정을 추산

사용자 스토리를 작성

테스트

배포

버전 컨트롤

지속적인 통합(integration)

사용성

사용자 인터페이스

코드 베이스

설계

데이터베이스

 

열정적으로 할 수 있는 주제

일상을 효율적으로 관리하는 데 관심이 많다면 나만의 일정 관리 앱

항상 뭔가 다르게 하고 싶은 요소

린 스타트업 개념에 대한 자료를 찾아보고 익숙해지기를 권한다.

비즈니스화하고 싶다면 비즈니스 자체에 집중하고,

작성된 코드들을 시장이 원하는 방향이 아니라면 얼마든지 버릴 준비가 되어 있어야 한다.

최소한의 것만 남기고 깨끗이 정리할 수 있어야 한다.

 

오픈소스 프로젝트에 기여하는 것도 좋은 훈련 방법이다.

문서에 내용을 추가한다든가,

테스트 코드를 작성한다든가,

버그 목록이나 구현해야 할 기능 목록에서 가장 간단한 것

작은 기능을 새로 제안하고 구현

 

훌륭한 개발자들이 어떻게 일하는지 체험할 수 있다는 것이다.

또한 공개적으로 자신의 활동을 알릴 수 있는 기회이기도 하다.

 

페어(Pair) 프로그래밍

팀의 정신적 에너지가 높아지고

혼자 배우는데는 한계가 있다.

문제는 시간이다.

스스로에게만 의존하면,

자신만의 좁고 편향된 생각에서 벗어날 방법이 없다.

 

즉각적인 피드백

좋은 토론 기회

색다른 접근 방법

 

공유하고 더 나아질 수 있는 기회를 늘 찾고 활용해야 한다.

누군가를 가르치다보면 내 생각을 구조화할 수밖에 없어서 설익은 개념을 제대로 이해하고 가다듬게 된다.

모르는 사람과 페어 프로그래밍을 하는 것이 더 좋다.

완전히 새로운 문제 해결 방식을 접할 가능성이 훨씬 높다.

다른 사람의 생각에 마음을 여는 것이 중요하다.

어떤 때는 배우고, 어떤 때는 가르치고, 어떤 때는 두 가지 모두 하기도 한다.

 

인적 네트워크

정서적 만족감

열정적인 개발자들

아는 것을 공유하려

 

나는 아테네에서 가장 똑똑한 사람임에 틀림없다. 왜냐하면 나는 내가 아무것도 모른다는 사실을 알기 때문이다. - 소크라테스

자신이 모르는 것을 모른다고 받아들이지 않는 것이다.

모르고 있다는 것을 인지하지 못한 상태를 2단계 무지라고 한다.

아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.

 

무지는 프로젝트에서 가장 큰 단일 장애요소다.

즉 무지의 수준을 최대한 빨리 낮추면 낮출수록 업무 생산성과 효율이 매우 높아진다.

모르는 것을 배우는 기회를 만들기 위해 항상 노력해야 한다.

내가 무엇을 모르는지 알지 못하는데 어떻게 그걸 배울 기회를 만들 수가 있나?

 

무지라는 장애요소를 제거하는 것은 우선순위에서 높이 두어야 한다.

이렇게 무지에 대항하는 습관을 들이면 프로페셔널로 성장하는 데 큰 도움이 된다.

 

그것은 당신이 그렇게 믿기로 결정한 것이고 그에 따라 현실이 되었다.

우리는 항상 시간이 있다는 것이다.

시간을 최적화하지 못할 뿐이다.

우리 커리어에는 그다지 중요하지도 않은 다른 일에 시간을 소모하고 있을 가능성이 높다.

 

시간이 낭비였고,

시간이 생산적이었는지

새로운 것을 배우거나,

우리가 사랑하는 사람과 함께 보낸 시간이다.

쉬는 데 시간을 썼다면 그것 또한 중요하다.

재충전해야 하므로 항상 신경써야 한다.

 

게으름에 대한 변명

몇 시간 씩 낭비하는 시간을 줄이기로 했다.

출근 전에 카페에서 한 두 시간 동안 자기계발을 해보자.

코드를 작성하거나,기술 문서를 읽거나,블로그에 글을 올리는 등커리어에 도움이 된다고 생각되는 일들을 하자.새로운 것을 배우거나 무언가를 연습할 수 있는 좋은 기회다.

 

정기적인 모임경험이 많은 사람을 통하면 훨씬 더 빠르게 배울 수 있다는 점도 생각해야 한다.자투리 시간뉴스 구독기로 최신 뉴스나 기술동향을 찾아보자.

 

집중: 뽀모도로 기법

그 시간에 제대로 집중하는 것이 핵심어디에 쓸지 미리 정해두는 것이 좋다.1. 어떤 일2. 25분 타이머3. 타이머 끝날때까지4. 짧게 쉰다. (5분)5. 매 4회 뽀모도로 길게 쉰다. (15~30분)

 

단순한 것을 선호

페이스를 유지

삶이 건강해야 가족의 삶도 건강해진다.

 

커리어의 주인이 되기는 어려운 일이다.

성공적인 커리어를 가지려면 결단력과 열정이 필요하다.

집중하지 못하면 많은 노력들이 낭비된다.

배움과 훈련이 멈추는 순간 우리의 커리어도 멈춰버린다.

시간이 없다는 말은 더 이상 변명이 될 수 없다.

우리는 항상 시간이 있다.

우리는 모두 정확히 같은 만큼의 시간이 주어진다.

차이점은 우리가 그 시간을 어떻게 쓰느냐일 뿐이다.

 

===========================================================================

 

메인프레임, 미들웨어

팀원 모두가 프로젝트를 성공해내길 바랐다.

우리 모두는 영웅이 되고 싶었다.

프로젝트를 통해 많은 것을 배우고 있었고 경험 많은 팀 동료들과 어울리는 것도 좋았다.

고품질의 좋은 코드를 작성하는 일이 즐거웠다.

팀 동료들은 모두 그렇게 생각했다.

모두가 지치고 힘들었지만 마음 깊은 곳에서는 즐기고 있었다.

 

그때는 인정과 명예를 원했다.

헛고생, 얼마나 노력했는지 알아주지 않았다.

힘겹게 완료했지만, 노예처럼, 어떤 취급

 

질문하지 않았다.

대안을 제시하려 노력하지도 않았다.

한번도 '아니오'라고 말하지 않았기 때문이다.

 

주어진 일정 안에 완료한다는 것이 불가능함을 알고 있으면서도 상급 관리자의 요구를 그냥 받아들이고 그대로 실행한다.

신뢰는 바닥으로 추락한다.

상급 관리자 자신은 집에 일찍 들어가고 주말을 가족들과 즐긴다.

모든 책임을 개발자들에게 뒤집어 씌운다.

개발자들의 능력이 부족해서, 개발자들이 더 열심히 일을 하지 않아서,

 

버그? 초당 10000 트랜잭션도 처리 못하는..?

3개 국가에서 동시에 서비스를 출시하길 원했고

3개 국가를 합쳐 2천만 명에 달했기에 첫날 방문자가 수십만 명 정도는 될 것이라고 예측

 

어김없이 새로운 요구사항을 추가했다.

일정은 그대로였다.

우리는 여러 차례 이미 주어진 요구사항들만으로도 일정을 맞추기 어려우니 기능을 추가할 것이 아니라 줄여야 한다고 말했다.

계속 일을 키우기만 했다.

 

겨우 몇 시간 전까지도 시스템 배포 작업이 이루어졌다.

코드는 엉망이었고, 수정을 살짝만 해도 정말 고통스러운 상황이 벌어졌다.

테스트를 한번 하려면 모든 것을 수동으로 다시 돌려보아야 하기에 대단히 어려웠다.

나쁜 평판만 생겼다.

 

서비스 오픈 범위를 일부 줄이고 기능 몇 가지는 생략할 수 있었다고 말했다.

거의 동시에 그 회사를 떠났다.

그 회사는 새로운 개발자들을 선별 과정을 거칠 여유도 없이 급하게 채용해야 했다.

회사에 더 큰 문제가 되었다.

 

매니저의 잘못이며 회사를 나가야 할 사람은 바로 그라고 말할 수 있다.

우리 개발자들은 그런 상황 전체를 피할 수 있었다.

회의 때마다 개발 일정에 여유가 없음을 통보하고, 

시스템에 대한 부하 점검이 필요함을 이메일 기록으로 남겼어야 했다.

 

모든 기능이 구현되더라도 시스템이 다운되면 전혀 의미가 없다는 점

우리는 '아니오'라고 말할 수 있어야 했다.

모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다.

 

일정을 준수할 수 있을지

어느 정도 자신감을 가지고 있는지 꾸준히 표명해야 한다는 점이다.

자신감을 갖는다는 것은, 모든 기능이 테스트되고,

실제 상용 서비스와 최대한 비슷한 환경에서 충분히 검증된 상태로 소프트웨어가 전달되어야 함을 의미한다.

 

노력해보겠다.

상황을 이해해서 그렇게 되게 만드는 것이다.

그렇게 되게 하겠다.

우리가 평소 열심히 일을 하지 않는다는 것을 암묵적으로 고백하는 것

언제든지 일을 빨리 하는 데 쓸 수 있다고 하는 것과 다를 바 없다.

 

야근과 휴일 근무를 밥먹듯이 하겠다는 뜻인가?

오래 일한다고 달라지는 것이 있나?

 

실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는다고 했다.

중독적이고 파괴적인 습관

성공하길 원하고 우리의 역량을 후회없이 최대한 발휘하고 싶어한다.

 

나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.

문제 상황을 공유할 것이라고 말해야 한다.

다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

정직하고 투명한 방법을 사용한다면 누군가 부당하게 피해를 입는 일 없이 팀 전체는 물론 회사에도 이득이 될 것이다.

 

반드시 하나 이상의 대안들이 따라와야 한다.

문제를 분석해서 대안

항상 실용적인 대안을 찾아 낼 수 있는 것은 아니다.

최소한 브레인스토밍은 해보아야

어떤 것을 원하십니까?

 

'아니오'라고 대답해야 하는 상황에서도 항상 '네'라고 말할 방안을 탐색해야 한다.

어떻게 풀어야 할지 방법을 모를 수도 있다.

최대한 이른 시점에 그 사실을 정직하게 알려야 한다.

 

최선의 노력을 다하고 있음을 보여주어야 한다.

문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야 한다.

진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다.

 

모든 새로운 정보가 있을 때마다 팀이 어떻게 대응해야할지 결정할 기회

새로운 정보가 있으면 팀원들이 뭔가 다른 아이디어를 생각해 내거나 해당 분야를 더 잘 이해할 수 있도록 도움을 줄 수 있다.

새로운 것을 이야기할 때 팀 전체가 신뢰를 갖고 듣기 마련이다.

아무리 나쁜 상황에서도 우직한 정직함을 보여줄 수 있다면 프로페셔널의 조건 중 하나를 갖춘 것이다.

 

진척도, 문제점, 병목요소

백로그(해야 할 일 목록)

일의 진척도와 해야 할 일을 시각적으로 보여 줌으로써 비즈니스 팀이 우리가 처한 상황을 정확하게 이해할 수 있도록 하였고,

아무리 야근과 휴일 근무를 하더라도 일정을 맞출 수 없음을 비즈니스 팀에 납득시키는 데 도움이 되었다.

 

주어진 일정 동안 무엇을 할 수 있을지, 개발자들과 함께 추산 가능해야 한다.

솔직함으로 인해 더 큰 문제를 피할 수 있다.

붉은 깃발, 현실적인 다른 대안

 

'아니오'라고 할 때 관리자들은 우리를 더 많이 믿어 줄 것이다.

현명한 사람은 자신이 모든 것을 알 수는 없음을 안다.

문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표

 

동고동락

야근을 한다면 관리자도 야근

간식거리, 격려, 농담

공동체 의식이 강화되고 프로젝트의 고통과 희열을 함께 느낄 수 있다.

무엇이 되었든 성과를 낼 수 있는 것에 몰입하는 분위기가 조성된다.

 

개발자를 보호하고 팀이 가진 장애요소들을 제거한다.

편안한 마음으로 자신감을 갖고 일할 수 있도록 해준다.

건강하고 행복하고 단결되게 하는 것은 관리자의 직무다.

 

고객이 무엇을 가장 필요로 하는지

최선의 방법을 도우며 조언하는 것이 우리의 일

윤리의식과 행동수칙

 

파급효과, 파악해서 알려주는 것은 우리들의 몫

'아니오'라고 답하는 것은 우리의 의무

그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고

각각의 장단점은 무엇인지를 알려주길 기대한다.

고객의 결정은 프로페셔널이 제공한 충분한 정보와 이해를 기반으로 이루어져야 한다.

밀어붙이려 한다면 당연하게도 프로페셔널은 그것을 거부한다.

우리도 그래야 한다.

 

===========================================================================

 

깨끗한 코드만으로는 프로젝트를 성공시킬 수 없다는 것

 

모든 실수에서 교훈을 얻으면서 진화하고 있다.

훌륭한 개발자들과의 협력적인 관계 속에서 일을 하는 것이 얼마나 중요한지 깨닫고 있다.

태도 변화가 이떻게 레거시 시스템을 다루는 개발자들을 돕고 저품질 소프트웨어의 양산을 막을 수 있는지도 이야기한다.

 

수준 이하의 코드

코드가 너무 민감하고 여기저기 얽혀 있어서

자동화가 되어 있지 않아, 하나하나 테스트해야 한다.

 

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 까깝다. - 실용주의 프로그래머

 

지속적인 돌봄, 토양, 잡초, 물

오래 방치할수록 다시 보고 즐길 수 있는 상태로 되돌리는 데 더 많은 수고가 필요하다.

새 기능을 추가할 때마다 상태가 나빠진다. (썩게 만든다.)

유지보수에 드는 비용과 노력이 감당할 수 없을 만큼 커져버린다.

코드의 품질이 낮아질수록 새로운 기능을 추가하거나 버그를 수정하거나 어떤 기능을 테스트하는 일이 점점 더 어려워진다.

 

코드의 품질을 돌보아야 하는 책임은 바로 개발자에게 있다.

코드의 문제를 프로젝트 관리자들에게 이야기하고 리팩토링 할 시간을 요구할 때도 있지만 무시되는 경우가 많다.

이는 관리자가 나쁜 코드의 악영향에 대해 이해가 부족하거나, 개발자가 문제 상황을 제대로 설명하지 못한 것이다.

대충 작성한 부분이 있다는 뜻

 

함량 미달의 개발자들로 팀을 꾸린다는 것은 있을 수 없는 일이다.

꾸준히 코드 베이스를 돌보고 두려움 없이 빠르게 리팩토링을 한다.

자동화 테스트를 구축하고 활용할 줄 안다.

변명이 될 수는 없다.

 

기술적 부채 (백로그에 기록)

페어 프로그래밍

테스트 코드가 없었다.

이미 동작하고 있는 코드에요.

코드는 당장은 안 쓰지만 나중에 필요할 수도 있고요.

이 무슨 말도 안 되는 이야기인가?

지금 만들고 있는 것은 완전히 새로운 기능이고 레거시와도 관계가 없다.

기존의 더러운 것을 청소하는 것이다.

이미 깨끗한 상태를 더럽혀서는 안 된다.

기술적 부채가 더해져서는 안 된다.

 

누군가가 백로그의 기술적 부채 항목을 보고 언젠가 고칠 거라고 생각들을 하지만 그런 일은 절대 일어나지 않는다.

백로그에 기술적 부채를 더하는 행위는 개발자가 코딩을 하던 당시에

아무런 죄책감 없이 잘못된 코드를 그대로 반영했다는 것밖에는 설명이 안된다.

 

개발자들이 의도적으로 나쁜 코드를 작성하지는 않는다.

핑곗거리를 찾는다.

우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다.

 

문제 원인은 코드의 사소한 논리 오류였고 단위 테스트를 했더라면 금방 잡을 수 있는 성격의 것이었다.

게다가 이 문제에 매달리느라 다른 개발자들의 시간까지 갉아먹었다.

이 모든 것이 로컬에서 돌려볼 수 있는 '단위 테스트를 작성할 시간이 없어서' 발생한 일이다.

 

디버깅거리를 늘린다.

해당 코드가 어떤 영향을 미쳤는지 분석하고 이해해야 한다.

팀 전체적으로 디버깅 시간을 늘리는 것이다.

'시간이 없기(!!)' 때문에 발생한다.

 

안티-패턴이다.

테스터가 버그를 발견하는 것은 개발자로서 대단히 수치스러운 일이다.

인간의 예측하기 어려운 행동을 반영하여

문제를 찾아내는 데 중요한 가치가 있다.

 

디버깅 스킬이 중요하기는 하지만 코드 수준에서 디버깅을 해야 하는 상황 자체가 대단히 당혹스럽고 불편하다.

리팩토링하고 테스트 코드를 만들어서 다시는 그런 일이 필요하지 않도록 해야 한다.

자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.

 

단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다.

즉 제대로 된 테스트 없이 코딩을 마무리한다.

단위 테스트의 구현 및 테스트 완료까지 포함되어야 한다.

 

전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다.

이기적인 사람, 소프트웨어 프로젝트는 팀워크

난해하고 불분명할 수 있다.

관계된 모든 사람들이 개인의 작은 이기적 행동 때문에 피해를 입게 된다.

 

3천여 개의 테스트 항목이 있는 테스트 슈트

테스트 커버리지를 100%에 가깝게 하였을 뿐만 아니라 단 5분이면 테스트를 완료할 수 있게 만들었다.

현저한 제품 개발 역량 향상

태도는 큰 차이를 가져올 수 있는 작은 요소다. - 윈스턴 처칠(Winston Churchill)

 

무언가가 마음에 들지 않는다면 바꾸어라.

그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라.

 

몇몇 조각들을 맞추는 데 성공하면 전체 그림의 일부분을 볼 수 있다.

재미있고 도전적인 문제로 바라 보는 것이다.

항상 우리가 대가를 지불받고 있는 프로페셔널이라는 사실을 잊지 않고 고객이 비즈니스 목적을 달성토록 주의를 기울여야 한다.

일을 즐길 수 있느냐 없느냐는 우리의 태도에 달려 있다.

 

회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다.

바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.

 

===========================================================================

 

목표에 맞게가고 있는지 정기적으로 살펴볼 수 있는 피드백 루프를 만들어 준다.

올바른 일(Right Things)

최소 시장 충족 기능(MMFs: minimum marketable features)에 집중하고,

백로그를 관리하고,

스탠딩업 미팅을 하고,

번-다운 차트를 만들고,

사용자 스토리와 시나리오를 쓰고,

제품 수용 기준을 정하고, 

작업완료가 무엇인지 정의

크로스펑셔널 팀을 운영

 

생명을 연장할 수는 있겠지만 죽음을 피할 수는 없다.

기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다.

우리가 어떤 상황에 놓여 있는지 파악하는 것은 대단히 중요하다.

현재의 상황을 반드시 고려해야 한다.

역할과 책임 그리고 정보의 흐름에 영향을 줄 수 있기 때문에

고객 만족, 투자대비 이익을 기대하지 않는 회사

 

5년 동안 계속 개발 중이기만 해도 만족할 회사가 있을까?

개별적인 상황 논리와 독립적인 것

 

급여 지급 시스템

XP 실행 관례의 도입 이후

버그 1/3, 디버깅 시간은 제로에 근접, 생산성은 10배

중요한 것은 소프트웨어 장인정신을 심는 것이다.

 

우리가 매일 같이 습관처럼 해야 하는 것이다.

테스트 주도 개발(TDD), 지속적인 통합(CI)

진심으로 받아들이고 내재화해야 한다.

명확한 전략을 정의해야 한다.

가치와 행동이 일치하는지 봐야 한다.

그렇게 해서는 상대방을 납들시킬 수 없다.

일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다.

 

피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그,

전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다.

 

성공할 확률

관리자들의 승인이 필요할까?

커지더라도 빠른 작업 속도

망가질 두려움을 덜 수 있기 때문이다.

테스트 코드를 먼저 작성하면 여러 가지 장점이 있다.

한 번에 하나씩만 집중

오버 엔지니어링을 하는 것을 줄여준다.

 

중복되기도 상충되기도 한다.

테스트로 규정된 부분만 작성하게 되기 때문이다.

BDUF(Big Design Up Front): 설계가 커지고 복잡해지는

 

일단 멈추고 버그부터 수정한다.

어떤 일을 하고 있었던지 간에 하던 일을 멈추고 마지막 변경점에서 문제 부분을 수정하는 데 집중해야 한다.

가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다는 장점이 있다.

 

가장 훌륭한 테스터는 자동화된 테스트를 개발하여 개발자를 돕고

비즈니스 분석가와 제품 오너가 사용자 시나리오에 따른 제품의 적합 기준을 정의하는 데 도움을 주는 사람이다.

훌륭한 테스터는 자동화하기 어려운 임의의 사용자 시나리오에 집중하여 개발자를 돕는다.

 

같은 페어끼리 너무 오래 있으면 효과가 적다.

하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

 

===========================================================================

 

보이스카웃의 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라.

엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다.

'깨진 유리창 법칙'으로도 알려져 있다.

 

지속적으로 코드를 리팩토링하면 이러한 위험이 줄어든다.

지속적으로 코드를 가다듬는다.

점진적으로 상태가 향상되어 리팩토링에 너무 많은 시간을 들이는 일이 없어진다.

 

전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다.

수정되는 부분에 한정해서 리팩토링을 집중하는 것이 더 나은 방법이다.

트레이드 오프를 이해한다는 것이다.

그럴 필요 자체가 없을 수 있다.

애당초 코드를 수정할 필요가 없다면, 리팩토링해야 할 이유도 없다.

리팩토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.

유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다.

 

책임감

구글에서 실패한 소프트웨어 프로젝트 비율을 검색해보면 얼마나 많은 프로젝트들이

이런 저런 형태로 실패했는지 여러 보고 자료와 통계를 찾아볼 수 있다.

실패 비율: 30% ~ 70%

 

원하지 않는다고 하면 귀담아 들어야 한다.

기분 나쁘게 생각하거나 그 사람의 지식 부족을 의심할 이유는 전혀 없다.

우리는 그런 사람들과의 대화에서 배워야 한다.

이러한 가치와 최소한 동등한 수준의 가치를 만들어 내기 위해 당신은 무엇을 하고 있습니까?

이러한 실행 관례보다 더 나은 방법이 있습니까?

 

우리의 의사 결정에 책임감을 가져야 한다.

우리는 이러한 결정들을 기록하고 문제가 있을 때 에스컬레이션 해야 한다.

 

실용주의

오늘날 훌륭한 것으로 취급되던 것이라도 인정했더라도 미래에는 그렇지 않을 수 있다.

어떤 가치를 주는지, 피드백 루프

어떤 실행 관례를 도입했다고 해서 영원히 사용해야 하는 것은 아니다.

점검하고 적응해야 한다.

특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다.

개방적인 사고 방식을 가져야 한다.

 

전체 애플리케이션이 정상 동작하는지 확인할 수 있다면 어떻겠는가?

서로 충돌하여 문제를 일으키지 않는지 즉시 알 수 있다면 어떻겠는가?

그러면 엄청난 시간을 절약할 수 있다.

 

===========================================================================

 

무엇인가를 잘 하고 싶어한다.

스스로 자랑스럽다.

우리 중 극히 일부만이 마스터가 되기 위한 어렵고 힘든 긴 여정을 감내해낸다.

투자 & 보상

 

가능성이 거의 제로에 가까웠기 때문이다.

선택지는 제한적이었다.

꿈을 이룰 수 있는, 선택 가능한 거의 유일한 커리어임을 알고 있었다.

 

나의 영어 실력이 런던에서 소프트웨어 개발자로 일하기에는 턱없이 부족하다는 것도 깨달았다.

개발자와 이야기를 나누거나 소프트웨어 프로젝트에 대해 토론하거나, 구직을 위해 인터뷰를 할 수 있는 수준에는 부족했다.

전화로 대화하는 것은 아예 엄두도 못 낼 정도 였다.

전화로는 누구와 얘기하든 전혀 이해할 수가 없었다.

 

Java를 배울 수 있는 다른 직장

개인 영어 교사를 고용하여 저녁 시간에 영어 공부를 했다. 석사 과정에도 지원했다.

자격 인증, 최소한 런던의 회사들 입장에서 낯익은 내용을 이력서에 추가할 수는 있었다.

나의 커리어가 내게 얼마나 중요한지 깨달았다.

 

내가 살고 싶어하는 곳이 어디인지를 떠나서 나만의 기준과 포부에 따라 성공적인 커리어를 준비하는 과정

나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야만 한다는 것을 깨달았다.

나의 인생이고 나의 커리어이고, 내가 주인이어야 했다.

 

이후 4년 동안, 항상 영국의 일자리를 주시하고 나 자신을 갈고 닦았다.

2004년 1월, 이탈리아 시민권이 발급되었다는편지를 받았다.

2주 뒤, 런던에서 첫 직장을 잡았다.

긴 여정이 이제 겨우 시작이며 갈 길이 멀다는 것, 새롭고 흥분되는 일들이 기다리고 있다는 것을 깨닫고 있었다.

 

어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.

스스로의 커리어를 가치있게 여기고 아끼고 보살펴야 한다.

긴 여정이며 각자의 선택에 따라 마스터가 될 수 있음을 이해해야 한다.

 

===========================================================================

 

커리어의 방향을 정하는 것이 중요하다.

커리어를 몇 년짜리 프로젝트라 여기고 어떻게 관리할지 생각해보자.

프로젝트의 비전과 종국적인 목표를 이해했다면 가장 중요한 요구사항은 전달받은 것이다.

그것을 작은 단위로 나누고 점진적인 반복 작업으로 만든다.

작은 작업 단계마다 프로젝트의 목표를 재평가하고 필요한 경우에는 수정해야 한다.

 

재평가하고 다시 목표를 세워야 한다.

개인적인 삶, 프로페셔널한 삶 속에 나타나는 모든 사건들을 고려해야 한다.

커리어의 방향을 확신할 수 없을 때는 모든 문들을 열어보기 시작해야 한다.

 

제발로 찾아와 노크를 하고 기회를 가져다 줄 사람은 없다.

좋은 기회를 제공해줄 수 있는 사람들이 나를 모른다면,

내가 어떤 사람이고 무엇을 하는지,

특히 얼마나 재능이 있는지 모른다면 그 사람이 나에게 기회를 제안할 턱이 없다.

밖으로 나가서 교류를 해야 한다.

세상이 나에게 접근할 수 있어야 한다.

다른 사람들이 나에게 다가오고 나와 이야기하는 것이 불편하지 않아야 한다.

다른 사람 다른 회사들에서 나에게 선택지를 제안할 수 있는 환경을 만들어야 한다.

 

- 새로운 것을 공부하고 기술적 지식을 확장한다.

- 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.

- 다른 개발자, 비즈니스맨

- 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.

- 오픈 소스 프로젝트

- 프로젝트를 만들고 공개

- 콘퍼런스에 참석

- 콘퍼런스에서 연사

 

모든 직장, 프로젝트들 하나 하나를 투자로 인식하는 것이 가장 중요

큰 목표를 향해 다가가는 단계 중 하나다.

끊임없이 지식과 열정과 몰입 그리고 프로페셔널로서의 태도를 키워나간다.

장기적으로 투자의 성과를 평가

 

일에서 투자 이익을 얻는다는 개념을 이기적이고 프로페셔널하지 않은 이력서 채우기로 오해해서는 안 된다.

지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다.

개발자들은 그들이 배우고 싶은 것을 따라서 일을 선택한다.

배울 것이 더는 없기 때문에도

개인적인 삶도 커리어 결정에 중요한 역할을 한다.

금전적 보상이 좋은 조건으로 커리어를 쫒는 것이 나쁠 이유가 없다.

안정적인 직장이 절실할 때도 있다.

그냥 일에 지쳐서 여행만 다니고 싶을 수도 있고,

개인적인 기술을 연마할 여유가 있는 야근과 휴일 근무가 적은 직정이 필요할 수도 있다.

 

커리어에서 옳고 그른 것은 없다.

지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다.

지식 & 경험, 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면,

단순히 돈만 좇을 때보다 좋은 직장을 얻기가 오히려 더 수월하다.

 

===========================================================================

 

원동력: 동기부여에 대한 놀라운 진실

돈은 충족되어야 할 기본 조건이고,

지식 노동자를 움직이는 것은 자율성, 통달, 목적의식 이렇게 세 가지 라고 이야기하고 있다.

 

자율성: 무엇을, 어떻게, 언제할지 통제할 수 있는 상태

통달: 프로페셔널, 계속 배우고 진화하는 것

목적의식: 더 나아지게 하고 있다고 느끼는 것을 뜻한다. 아무런 이해없이 시키는 대로 일하는 것의 반대 개념이다.

 

성취감, 목적의식은 우리를 행복하게 해주고 더 나은 세상을 위해 우리가 기여했다는 느낌을 준다.

신중하게 선택한 곳이라면, 새로운 직장에서 새로운 일을 시작하는 것은 아주 신나는 일이다.

피터의 원리, 자신의 무능력이 드러날 때까지 승진하려는 경향

 

그 여정 자체가 훨씬 더 중요함을 알고 있다.

일에 대한 보상을 받는 프로페셔널이라면 고객에게 가치를 제공할 의무가 있다.

일을 선택할 때는 자율성, 통달, 목적의식을 쫓아야 한다.

 

역량이 더 높아질수록, 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다.

집중과 결단력, 스스로 만들어 나가야 한다.

일을 신중히 선택하고 고객들을 만족시켜 나가면, 소프트웨어 장인으로서 매우 성공적이고 즐거운 커리어를 만들 수 있다.

 

===========================================================================

 

현재 업무가 제대로 진행이 안 되고 잘못된 행동들을 하고 있는 기존 개발자들이 문제라면,

그와 똑같이 행동할 사람을 또 채용하는 일이 없도록 해야 한다.

지속적으로 배우고 혁신하고 효율적인 실행 관례를 도입하고,

프로젝트의 성과와 코드의 품질에 주의를 기울이고,

문제를 풀기 위해 스스로 협력하고,

무엇이든 더 나은 방법을 추구한다면 이러한 훌륭한 개발자들과 비교해 기준에 미달되는 개발자를 채용하는 것도 어리석은 일이다.

 

모든 회사들이 최고의 인재를 원한다고 표방하지만 최고의 인재가 실제로 어떤 의미인지는 잘 모르는 경우가 허다허다.

회사들의 실제 채용 공고를 살펴보면 이러한 문제가 쉽게 드러난다.

 

프로젝트 그 자체와 함께 절차,

문화에 훨씬 큰 문제가 있고 실제로 풀려는 문제도 그러한 것들일 가능성이 높다.

문제들을 어떻게 풀어야 하는지 단서조차 못 잡고 있고 그에 적합한 사람을 채용하는 방법도 모른다.

 

더 많은 돈만을 쫓고, 일하는 방법을 개선하거나 자기계발에는 공을 들이지 않는다.

더 대우가 좋은 은행으로 얼마든지 옮겨 다닐 수 있다.

더 역량 있는 사람이 필요하다고 성화다.

더 나아지도록 변화시킬 수 있는 사람, 더 품질 좋은 소프트웨어를 효율적으로 만들어 내고 비용을 낮출 수 있는 사람을 원한다.

사람을 고용하기 위해서는 채용 방식을 바꾸어야 한다는 것을 모른다.

채용 공고의 직무 요건을 바로잡아야 한다.

 

회사에서 내보내고 싶은 사람과 같은 부류의 사람을 또 채용하게 될 수도 있다.

한 사람을 채용하기 위해 10명에서 30명까지 인터뷰해야 한다.

지원자의 '적합성'의 문제가 아니다.

정확히 어떤 사람을 찾는지, 어떻게 찾을 수 있는지도 잘 모르는 경우가 흔하다.

 

함께 일하고, 기술 토론을 하고,

페어 프로그래밍을 하고, 좀더 효율적인 실행 관례 도입

뭔가 하나 시키면 언제 끝날지 알 수가 없다.

도대체 뭘 하고 있는지 모르겠다.

 

그 개발자들을 돕게 하기 위함이었지 그 개발자들을 해고하기 위한 것이 아니었다.

나는 그들을 더 나아지게 하기 위해 이 자리에 있다.

나는 그 개발자들과 며칠 동안 함께 시간을 보냈고 그들의 신뢰를 얻었다.

 

인터뷰할 시간이 없다는 변명

우리는 가족이나 연인보다 회사 동료들과 훨씬 많은 시간을 보낸다.

신뢰할 수 있고 좋은 관꼐를 맺을 수 있는 사람을 동료로 두는 것은 대단히 중요하다.

 

주관적으로 평가

면접관 개인의 기술적 역량, 가치 기준, 편견에 따라 정해진다.

계층 구조와 통제에 가치를 두는 사람은 자기보다 더 나은 사람, 심지어 자신과 비슷한 수준의 사람조차 배척한다.

배우기를 원하고 더 나은 일하는 방법을 찾는 사람은 자신보다 훌륭한 사람과 함께 일하기를 원하고

최소한 자신과 비슷한 역량의 사람이라도 채용되기를 희망한다.

 

절대적인 숫자: 기술은 일을 통해서 또는 자발적인 자기계발을 통해서 배울 수 있지 학점이나 자격증을 통해서 얻는 것이 아니다.

키워드 매칭

기술 목록의 나열: 스스로 지원을 포기하게 만들 수 있다. 희망 기술까지 더해지기 일쑤다.

잘못된 기업 문화 설명

잘못된 요구 항목

잘못된 선별 조건

승진 요건과의 불일치: 직무 요건으로 필터링된 사람들이 회사 안에서 좋은 성과를 낼 것으로 기대하는 자체가 앞뒤가 안 맞는 일이다.

 

태도와 책임, 프로젝트 종류, 사용 기술

가치관과 회사의 문화에 집중된 내용으로 채워져야 한다.

 

개발자 역량 향상을 위해 배우고 연습할 시간을 따로 제공하고 이러한 부분이 회사에 문화적으로 녹아 있음을 강조하고 있다.

Github 계정 링크: 오픈 소스에 대해 얼마나 진지하게 생각하는지

당신에게 일은 단순히 직장에 출퇴근하는 것 이상의 의미가 있어야 합니다.

 

훌륭한 개발자들에게 일은 그냥 일이 아니다.

일은 취미이자 열정이다.

좋아하는 일을 하면서도 돈을 벌 수 있어서 행운이라고 느낀다.

훌륭한 개발자들은 회사도 같은 방식으로 생각하기를 바란다.

개발자들은 그들이 빛날 수 있는 기회와 재미난 일거리를 많이 제공해 줄 회사를 찾는다.

 

추천 채용 시스템에 금전 보상이 더해지면 채용 절차 전체를 무효화만한 잘못된 동기가 생길 수 있다.

좋은 개발자들은 좋은 개발자들과 일하고 싶어한다.

좋은 개발자들은 추천 채용을 훌륭한 개발자에게 배울 수 있는 기회로 생각한다.

훌륭한 개발자가 들어오면 회사에도 좋고 추천한 개발자의 성장에도 좋다.

소프트웨어 장인이라면 다른 개발자를 추천하는 것 자체가 스스로의 평판을 시험대에 올리는 행위임을 이해한다.

즉 추천한 본인과 동등한 수준의 열정, 가치, 원칙으로 헌신하는 사람이어야 한다.

 

좋은 개발자는 매우 드물다.

면접 시간을 어떻게 아낄 것인가?

지원자 모두를 면접하는 것은 불가능하다.

높은 지원자들을 추려내야 한다.

 

내가 가장 중요하게 생각하는 개발자의 자질이 무엇인지,

어떤 문화를 심고 싶은지,

열정적인 소프트웨어 장인

 

항상 새로운 것을 시도,

배우고, 지식을 공유하고,

커뮤니티 활동에 적극적인 사람

채용 조건을 아무리 잘 만든다고 하더라도 이력서를 선별할 때는 좋은 개발자를 의도하지 않게 제외시키기도 한다.

훌륭한 개발자에 대해서 명확히 정의 필요

 

자신의 커리어를 위해 개인 시간을 들여서 스스로에게 투자하는 사람,

즉 열정이 있는 사람을 구분하기에 충분해보였다.

 

서류 선별조차 하지 않는다면 다시 모든 지원자를 면접해야 하는 상황으로 되돌아간다.

비용적, 시간적으로 감당할 수 있는 일이 아니다.

 

상황이 절박하면 실수할 확률이 높아진다.

특히 채용할 때는 더욱 그렇다.

채용 기준을 낮추고 아무나 받아들이기 쉽다.

 

회사는 시급하게 채용해야 하는 상황을 절대 만들어서는 안 된다.

잘못된 사람이 조직에 들어오기 쉽다.

자질이 부족한 개발자에 대한 고객의 불만이 극에 달해 조기에 종료될 수도 있다.

회사의 평판이 나빠지는 것뿐만 아니라 그 형편없는 개발자들로 다음 프로젝트를 또 다시 꾸려야 한다.

 

열정적인 개발자는 개방된 사고로 항상 무언가를 배우기를 원하기 때문이다.

그들은 스스로 동기가 부여되어 혁신하고 기술 변화를 이끈다.

누가 무엇을 하라고 할 때까지 기다리지 않는다.

무언가를 시킬 때까지 그저 가만 있는 사람들은 회사를 정체 상태로 이끌어 피해야 할 사람들이다.

개인 시간을 기꺼이 투자한다.

 

먼저 회사가 그들을 어떻게 채용했었는지 회사의 채용 방식에 의문을 품어야 한다.

채용 절차가 의도한 대로 동작하지 않았을 가능성이 있다.

다른 회사들도 똑같이 훌륭한 사람들을 찾고 있다는 것을,

역으로 훌륭한 사람들도 나쁜 회사들을 걸러내고 있다는 것을 기억해야 한다.

 

===========================================================================

 

면접은 쌍방향이다.

회사는 그들의 목적을 달성하는 데 도움을 줄 수 있는 개발자를 찾으려 하고,

개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려 한다.

 

회사에 대해서 파악할 수 있는 중요한 기회

새로운 회사에서 일하는 것은 커리어상 대단히 중요한 결정이어서 개인의 삶에 직접적으로 영향을 미친다.

더 많은 시간을 보내기 때문이다.

 

기업이 경쟁우위를 점하려면 실력있고 열정 가득한 개발자를 채용

면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야 한다.

비즈니스 협상

 

협상의 결과에 따른 보상과 위험 수준이 어떠하고 그 내용이 무엇인지 반드시 이해해야 한다.

양쪽 모두에게 가치

나쁜 파트너와 함께 일을 해야할 이유는 없다.

 

여러 관점의 질문들을 던지고, 일하는 방식을 개선하여 목표를 성고엊긍로 달성하는 데 기여하기를 원한다.

어떤 식으로 일하는지,

무엇을 성취하길 원하는지,

당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않는 사람이,

실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까?

 

일하는 방식을 개선하는 데 그의 도움을 받겠다는 것이다.

협업과 권한부여는 성공적인 팀이 되기 위해 반드시 필요하다.

지원자가 협업을 잘 할 수 있을지,

권한부여를 잘 감당할 수 있을지 판별하는 것이다.

 

지원자가 일과 회사에 대해 아무런 질문도 하지 않는다면,

단지 '아무 일자리'나 찾고 있을 뿐이라는 신호가 될 수 있다.

 

많은 질문들을 쏟아낸다면 그가 그의 커리어를 소중히 하고 올바른 직장을 찾는 중이라고 짐작할 수 있다.

항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.

질문을 많이 한다는 것이 더 능력있다는 증거는 아니지만

최소한 지원자 스스로 즐겁게 일할 수 있는 곳을 찾고 있다는 증거는 될 수 있다.

 

열정적이고 애착을 보이는가?

사례에 대해서 어떻게 표현하는가?

실패에 대해서 책임감을 느끼는가?

남 탓을 하는가?

잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해본 적이 있는가?

불평 불만 대신, 그 상황을 개선하기 위해 노력해본 적이 있는가?

어떤 종류의 업무 환경을 찾고 있는가?

회사에서 그러한 환경을 제공해 줄 수 있는가?

껄끄러운 부분까지 가급적 모두 말해야 한다.

 

재능있는 사람을 채용하기 위해서는 열정과 업무 역량 그리고 문화적인 궁합을 따져봐야 한다.

신뢰하는지

여러 측면

프로페셔널을 채용

교육적

토론할 여지

열정이나 프로페셔널로서의 자질에 대해서

창의성 부족, 폐쇄적인 회사 문화의 일면

 

좋은 면접은 자유 토론

소프트웨어 개발과 관련하여 지식과 정보를 교환하고,

기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

 

몇몇 부분은 생각이 다릅니다.

그것에 대해서 이야기를 나누고 싶습니다.

 

자유 토론 방식 면접

바로 지원자의 실제 경험을 알아낼 수 있다.

 

주요 기술은 무엇인가?

더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가?

스스로 대답을 준비해야 한다.

 

테스트 주도 개발(TDD)

클린 코드

리팩토링

페어 프로그래밍

애자일 방법론

 

개선할 필요가 있다면

설계 스킬이 뛰어난 사람을 선별해야 한다.

열정이 가득한 사람을 선별해야 한다.

 

잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?

소프트웨어 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까? 트레이드 오프를 선택

 

이렇게 대화를 확장하다가, 쉽게 주제를 옮길 수도 있다.

지금은 가독성에 대해 이야기를 나누었습니다.

좀 전에는 테스트에 대해서 언급했는데 더 자세하게 이야기할 수 있을까요?

 

면접이 끝나면 모든 대화가 마인드 맵으로 종이에 남아 각 지원자와 나누었던 대화들을 다시 기억해내는 데 효과적으로 이용된다.

지원자가 작성한 코드

어떤 테스트를 작성할지 얼마나 빨리 결정하는가? (경험수준)

개발 도구(IDE, 언어, 테스팅/목업 프레임워크, 단축키 등)에 얼마나 익숙한가?

클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가?

깨끗하고 명료하게 작성?

제안이나 조언을 할 때 어떻게 반응?

어떤 방식으로 생각을 전개?

문제 해결만이 아니라, 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가?

 

공개된 프로그래밍 연습문제 카타

도움을 요청

올바른 방향을 찾을 수 있도록 가능한 모든 도움을 주어야 한다.

너무 오래 해매도록 내버려 두어서는 안 된다.

길어야 3~4분 정도 기다렸다가 도움

압박 속에 있기 때문에, 시간을 지체하면 상황만 나빠질 뿐이다.

어느 부분을 어려워하는지 파악할 수 있고 면접관으로서 계속 평가할 수 있다면 지원자가 자신의 역량을 보이도록 최대한 도와야 한다.

 

내가 한 가지 후회하는 것은 그에게 면접 결과를 빨리 알리지 못해서,

그가 다른 회사를 이미 선택해버렸다는 것이다.

 

자신의 컴퓨터를 직접 가져오도록 요구하는 것도 좋다.

좋아하는 도구, 소중한 면접 시간을 아낄 수도 있다.

업무 외 시간에도 코딩을 하는 개발자라면 이러한 것들이 항상 준비되어 있다.

 

소중히 하는 가치?

어떤 종류의 태도를 기대?

직무의 핵심 스킬?

지원자의 다재다능한 면을 알아보는 것은 바람직한 행위다.

 

지식수준?

핵심가치?

사전 선별 절차는 극히 중요하다.

사전 선별은 회사의 핵심 가치에 따라 지원자를 걸러내는 단계다.

업무와 전혀 관계 없는 기술들에 대한 객관식 온라인 시험으로 지원자를 평가하는 것은 최악의 방법이다.

 

새로운 것을 시도하는 데 얼마나 열정적인지 알 수 있었다.

업무 시간에는 허락되지 않는 배움의 욕구를 채우기 위해 개인 시간을 투자하고 있었다.

올바른 환경과 기회만 주어진다면 아주 훌륭한 개발자로 빛날 매우 전형적인 스타일이었다.

 

재능, 태도, 열정, 잠재성

소프트웨어 개발 기초 역량이 충분하다면

우리가 무슨 기술을 사용하든 금방 배울 것이다.

 

실제 고객에게 소프트웨어 제품을 공급하는 과정에서만 배울 수 있다.

현실에서의 경험과 성공적인 이력들이 필요하다.

그리고 특정분야(도구, 언어, TDD)만 잘 아는 스페셜 리스트 보다는

여러 서로 다른 기술들과 도구, 스크립팅, 가상머신 등등에 폭넓게 조예가 있는 기술 분석 전문가도 필요하다.

 

충분한 시간

주어진 문제를 얼마나 빨리 코드로 구현하느냐

시간 제한을 짧게 하면 지원자로 하여금 좋은 코드를 작성하는 것이 아니라 문제 해결에만 집중하게 만든다.

시간 제한을 아예 두지 않는 것이다.

좋은 지원자들을 누적해서 확보하는 데 특별히 관심이 있는 작은 회사들에게 적합하다.

 

최소 2주 정도

능숙함이 아니라, 얼마나 좋은 코드를 만들어 내는지 파악하는 것이 목적이다.

독립적으로 문제 해결을 위해 어떤 테크닉을 사용하는지 보는 것이 중요하다.

 

강한 팀은 각 개발자들 모두 면접을 진행할 수 있어야 한다.

모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다.

노련한 개발자가 면접을 어덯게 진행하는지 지켜본 경험은 나중에 그 주니어 개발자가 면접을 수행할 때 많은 도움이 될 수 있다.

면접관을 로테이션하면서 팀원 모두가 채용 과정에 참여하도록 하는 것도 바람직하다.

 

자신 프로젝트를 자신이 통제할 수 있다는 확신을 심어준다.

무력감, 당황스러울 뿐이다.

좋은 개발자는 나쁜 개발자를 채용하지 않는다.

좋은 개발자는 그들 자신보다도 더 훌륭한 개발자를 찾으려 노력한다.

좋은 개발자는 훌륭한 팀을 구성하는 것이 얼마나 중요한지 잘 알고 있다.

훌륭한 팀은 회사뿐만 아니라 개발자들 자신에게도 이익이 된다.

 

당신의 팀이 더 나아질 수 있도록 도와줄 수 있는  사람이어야 한다.

겸손하고 정직해야 한다.

채용을 위한 평가나 취조가 아니라 당신이 존중하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다.

이야기를 경청하고 그에게 마음을 여는 것이 중요하다.

실제로 무언가 새로운 것을 배울 가능성이 높다.

 

직무와 전혀 관계 없는 바보 같은 질문은 하지 말아야 한다.

완전히 시간 나입다.

구글의 면접관들도 잘못된 것을 깨닫고 이런 질문을 그만둔 지 오래되었다.

 

애자일, 자율성, 협업

즉시 일어나서 화이트보드에 전에 개발했던 시스템에 대해서 그림을 그리며 설명을 했다.

감사합니다. 저는 그 말씀을 큰 칭찬이라고 생각하겠습니다.

이 단순한 아키텍처가 3개 대륙에 걸쳐 2천만 명이 넘는 가입자를 서비스하고 있습니다.

이보다 더 복잡하게 만들지 않고서도 해냈다는 것을 기쁘게 생각합니다.

 

나는 그 임원에게 면접을 계속하는 것이 의미가 없음을 설명했고,

면접 기회를 준 것에 감사를 표하고 자리를 떠났다.

 

검색할 수 없어도 시스템 개발이 가능할까?

문제 대응 방법을 찾는 것은 소프트웨어 개발자로서 갖추어야 할 핵심적인 능력이다.

인터넷 검색때문에 코딩 면접이 변별력을 잃을 수 있다면 면접 과제 자체가 문제가 있다고 본다.

 

지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보같은 면접 방법이다.

자신의 도구와 기술을 마스터하고 테스트와 리팩토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야 한다.

 

실제 도구를 이용해서 생산된 실제 코드를 평가해야 한다.

실제 프로젝트와 가까운 다른 연습문제를 통해서도 '문제 해결 능력'을 평가할 수 있다.

- 잘못된 설계

- 떨어지는 응집성

- 깊은 종속성

- 리팩토링

- 지속적인 요구사항 변경

- 도메인 모델

실제 문제에 가까운 과제들을 제시

 

오프라인에서 직접 얼굴을 마주보는 면접이 가장 바람직하다.

좋은 개발자를 찾기는 꽤 어렵고 오랜 시간이 걸린다.

면접에 시간을 투자하고 있다면 그를 최대한 의미있게 활용해야 한다.

 

테스트, 리팩토링, 좋은 네이밍

함께 일할만한 동료인지 알아보기 위해 자연스럽게 대화하자.

좋은 개발자에 대한 수요는 매우 높다.

즉 좋은 개발자들은 거꾸로 회사를 면접하여 평가하고 나쁜 회사들을 걸러낸다.

 

업무를 토론하며, 업무 일정과 우선 순위

직접 권한을 가지고서 빠른 주기로 일이 진행됨

통합된 백로그, 검증 책임

 

애자일 행오버

5개년 계획 따위를 계속 설교하고 다니지만 실제로 뭘 해야 하는지 정확히 아는 사람은 없다.

말만 많다.

일을 올바르게 하고, 소통을 원활히 하고, 피드백 주기를 짧게 하고,

팀워크를 최대화한다는 것과 같아야만 한다.

 

일을 즐겁게 할 수 있게 하는 요건들, 자율성과 목적의식을 제공할 수 있어야 한다.

최선을 다하지 않는 것일까? (동기부여)

애자일 전환이 피드백 루프를 짧게 하고,

상황을 투명하게 만드는 데는 긍정적이지만 개발자들을 성장시키는 데는 도움이 되지 않는다.

 

열정을 다해서 애플리케이션을 더 나아지게 하고 일하는 방식을 개선하려고

온갖 노력을 쏟는 동안 다른 개발자들이 그저 뒤에서 팔짱만 끼고 구경하거나 심지어 방해하는 것이 화가 날 뿐이다.

항상 그렇지만 상황이 안 좋아지면 제일 먼저 가장 능력 있는 개발자들이 떠나간다.

 

일정 추산이나 우선순위 정의는 없었다.

일부분이라도 질서를 부여하려 노력했다.

백로그를 정리하고 업무 리뷰와 계획을 위한 절차를 실행했다.

 

8개월 동안 이런 저런 방법으로 사람들이 프로젝트에 관심을 가지게 하려고 노력했다.

팀원들이 하는 일에 대해 조금이라도 자부심을 갖도록 공을 들였다.

하지만 어느 시점에 이르러서는 너무 당혹스러운 나머지, 독립적인 기능들 몇 가지만 추려서 혼자서 작업했다.

당혹감과 팀 구성원들과의 언쟁만 늘었다.

 

다른 프로젝트로 보내주든가 아니면 회사를 그만두겠다고 말했다.

그 문제를 고객사의 IT 부서 고위직까지 이슈화시켰고 결국 거의 팀원 전체가 교체되었다.

컨설팅 회사에서 직접 그 프로젝트와 납품 과정에 대한 권한과 책임을 모두 챙기게 되었다.

 

5명의 재능 있고 열정적인 개발자들과 유능한 비즈니스 분석가 한 명으로 18개월~24개월동안,

2백만 파운드 이하의 비용으로 완료할 수 있는 프로젝트 였다.

이런 프로젝트를 개발자 한 명이 바꾸는 것은 거의 불가능하다.

훨씬 더 큰 수준에서의 개입이 필요하다.

 

- 자신에게 아무런 권한이 없다고 생각한다.

- 그런 일을 이끌어가야 할 당사자가 되고 싶지 않다.

- 그렇게 되기에는 복잡한 자애요인이 너무 많다.

- 뭔가 바뀌는 것이 가능하다고 믿지 않는다.

- 무엇이 더 나은 일인지 사람들의 동의를 받기 힘들다.

- 아무 상관 없다. 그냥 출퇴근만 하면 된다.

 

제대로 할만한 동기 부여

스스로의 일을 개선하는 데 진정 관심을 가지고 있는가?

일을 더 잘 할 수 있도록 지속적으로 자기계발을 하고 있는가?

회사가 하는 일이 사회에 기여하고,

해야할 가치가 있다고 느끼고 있는가?

회사가 해내는 일을 좋아하는가?

 

외부로부터 소프트웨어 장인을 수혈받는 것이다.

정규직, 계약직

소프트웨어 장인의 경우 스스로 설정한 임무

프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다.

멘토로서 행동, 자신의 자기계발 활동을 다른 사람들과 공유하려 한다.

 

몇 명의 소프트웨어 장인

기술적인 문제 해결에 도움이 될뿐만 아니라, 열정을 불어 넣고 혁신을 일으키는 데 지지자이자 동맹이 되어준다는 것이다.

지난 미팅 이후 뭔가 새롭게 배운 것을 공유할 분 있습니까?

블로그 글에 대한 링크나 비디오, 책들도 공유하기 시작했다.

 

열정적으로 토론, 직접 활용, 실습 세션

동기부여가 되지 않는 사람들은 혁신을 창조하고 적용할 에너지가 없다.

일을 제대로 하고 책임을 지는 데도 관심이 없다.

 

동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자이다.

실력 있는 개발자, 본받고 싶고 영감을 일으키는 개발자,

바로 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다.

개발팀에 열정을 불어넣고 동기를 부여하고 싶다면 소프트웨어 장인 몇 명을 팀에 영입해야 한다.

 

===========================================================================

 

스스로 코딩에 대해 제대로 알기나 할까?

우리 옆에 앉아서 페어 프로그래밍을 할 수 있나?

구체적으로 무엇을 해야 하는지 상세하게 가이드할 수 있을 만큼 현실을 제대로 이해하고 있나?

 

항상 더 나은 방법을 찾고 스스로를 개발하고자 하는 사람들로 가득 찬 환경을 접해본 개발자들은 그리 많지 않다는 것이 안타까운 현실이다.

롤 모델이 부족하기 때문에 주니어 개발자들은 소프트웨어 개발이라는 것이 그리 신나는 커리어는 아니라고 믿게 된다.

 

개발자들이 행복한 회사라면 외부의 훌륭한 개발자들을 유입할 수도 있을 것이다.

그 책을 읽기 시작할 거라고 공표

 

테크 런치 진행하기

서로 다른 기술, 접근 방법, 테크닉, 서적 등 참여자 누구든 공유하거나 토론하고 싶어하는 것

점심 도시락, 회의실, 화이트보드, 프로젝터

주제를 포스트잇에 적도록 한다.

병합, 모든 주제들을 다시 한번 낭독, 득표가 많은 주제

 

프로젝트가 전개되는 와중에 이전에 결정된 사항들을 되돌아보는 경우는 극히 드물다.

너무 익숙해져 더 나은 방법들을 탐색해보지 않게 된다.

즉 매너리즘에 빠지고 지루함이 찾아온다.

 

기존 결정들에 대한 재검증: 새로운 사람은 기존 결정이 이루어진 맥락을 이해한 후 그 결정이 올바른 것이었는지 확인해 줄 수 있다.

지식의 공유: 새로운 개발자는 특정 문제들이 어떤 식으로 해결되었는지 배울 수 있다.

개선: 새로운 개발자는 문제들을 해결할 더 나은 방법을 제안할 수도 있다.

공통 학습: 서로 현재의 해결책을 토론하고 지식들을 공유하고 나면 기존 멤버와 새로운 개발자 모두 더 나은 해결책이 떠오를 수 있다.

 

그룹 코드 리뷰는 팀 전체를 하나로 만들 수 있다.

모두가 리뷰에서 이루어진 결정에 책임감을 느끼고 어떤 것이 품질을 만들어내는지 되새기게 된다.

 

- 주석은 주관적, 개인적으로 표현되어서는 안 된다.

- 누가 코드를 작성하느냐는 중요하지 않다.

- 커밋 히스토리를 뒤지지 않는다. 비난할 사람을 찾기 위해 과거를 파헤치지 말고 미래를 변화시키는 데 집중한다.

- 주석은 반드시 객관적이고 생산적이어야 한다. 어떻게 코드를 개선할지에 집중해야 한다.

- 퍼실리테이터의 도움이 필요할 수도 있다.

- 퍼실리테이터의 역할은 모두에게 발언권을 주고 누군가를 비난하는 상황이 생기지 않도록 하는 것이다.

- 이슈 한 가지에 대해서 너무 오랫동안 이야기되더라도 개발자들이 원한다면 그냥 그렇게 한다.

 

관심을 보이는 사람들에게 집중하라.

모두가 관심을 가질 것으로 기대하긴 어렵다.

변화를 수용하는 사람들에 집중하자.

그들과 페어 프로그래밍을 하고, 테스트를 작성하고, 서로의 코드를 리뷰한다.

유익한 토론들을 하고 아이디어와 정보를 나눈다.

그들과 함께 일을 즐긴다.

새로운 테크닉과 접근방법을 사용하기 시작하면 함께하려는 사람이 늘어날 것이다.

 

개방된 커뮤니티의 원칙 중 하나는 들어오는 사람이 초대 받은 사람이다라는 태도

모두를 바꾸려 할 필요는 없다.

소수의 사람들로도 큰 진보를 만들어 나갈 수 있다.

특정 날짜를 정해서 모임을 진행하는 것이 좋다.

 

개인 시간을 들여 공부하고 연습하는 데 상사의 허락을 구할 필요는 없다.

책임있게 행동하면 될 뿐이다.

팀이 스스로 더 나아지기 위해서 훈련하는 것에 대해 민감하게 반응하고 불평할 관리자는 없다.

단, 학습 활동 때문에 업무를 소홀히 해서는 안 된다.

상식적으로 책임있게 행동해야 한다.

투덜대지 마라

 

시간이나 장소가 없다는 것은 변명이 될 수 없다.

열정적인 개발자들에게 좋은 환경을 제공하기만 하면 된다.

스스로 무엇을 배우고 공유할지 여러 가지 방법을 찾을 것이다.

회사에도 품질과 혁신을 가져다 줄 것이다.

 

===========================================================================

 

무지

대중

트라우마

 

냉소주의

똑똑해 보이는 것을 더 중요하게 여긴다.

그들 스스로의 약점을 드러내고 싶지 않아서일 수도 있다.

새로운 것을 도입하게 되면 그들의 권위가 위협받는다고 생각한다.

꼬투리를 잡고 방해하는 것이 더 쉽다.

 

너무바쁜

어떤 일의 장기적인 비용을 보지 못하고 근시안적인 판단을 한다.

계속해서 반복할 시간은 있다.

특히 시스템이 망가질까 두려워 큰 규모의 개선은 엄두도 못 낸다는 사실이 얼마나 큰 비용인지 알지 못한다.

이들의 눈에 보이는 것은 너무 바빠서 일하는 방식을 바꿀 시간이 없다는 것뿐이다.

 

상사

상사가 기술 배경이 없다면 당신이 제안하는 것들이 어던 장점이 있는지 이해하지 못할 가능성이 높다.

뭔가 자동화하는 도구를 만들자

프로젝트 운영 비용을 줄이자

코드를 지금보다 유지보수하기 쉽게 만들자

프로젝트 딜리버리 주기를 줄이자.

 

몰상식

가장 최악의 타입니다.

합의가 불가능하다.

논리적으로 반대할 내용이 없으면 이 문제에서 저 문제로 끊임없이 옮겨 다닌다.

그렇게 하면 성능 문제가 있을 것 같다.

자동화 테스트로는 사람이 하는 것만큼 효과를 낼 수 없다.

말이 막힐 때마다 이 부눕ㄴ에서 저 부분으로 아무런 합리적 근거도 없이 생트집을 잡는다.

제안자를 그냥 개인적으로 싫어하는 것일 수도 있다.

어쩌면 퇴사를 생각하고 있거나, 다른 벌여 놓은 일이 많아서 더 이상 새로운 일을 만들기 싫은 경우일 수도 있다.

실제 내막을 알기는 어렵다.

 

무념무상

좋은 아이디어를 대충 엉망으로 구현해서 결과적으로 좋은 아이디어를 나쁜 아이디어로 만드는 것

 

피해망상

개발자들은 회사가 자신에게 피해를 주고 있다고 생각한다.

고과나 급여, 복리 후생 등에서 불공정한 대우를 받고 있다고 느낀다.

일부러 망치면서 회사도 한번 당해봐야 돼

팀을 파괴하고 개발자들끼리 서로 비난하게 한다.

더 최악인 것은 이런 개발자들은 절대 회사를 나가지 않는다.

대신 회사가 자신을 해고해서 거꾸로 회사를 고소할 수 있을 때까지 기다린다.

 

무능력

제안의 본질을 파악하지 못한다.

인지능력, 이해능력의 부족을 보인다.

막연하게 생각하며 이들이 하는 제안은 왜곡된 사실을 기반으로 한 어디선가 주워들은 설익은 아이디어들뿐이다.

그리고 무언가 노력을 하더라도 소프트웨어 개발자라는 직업이 그들의 적성에 맞지 않다는 것을 계속 증명할 뿐이다.

 

상아탑 아키텍트

모든 것을 알고 있다고 생각한다.

자신이 제일 높은 지위를 차지하고 있다고 생각하나

수년 동안 상용 시스템의 코드를 단 한 줄도 만들어 본 적이 없는 경우가 대부분이다.

개념 설명용(Proof of concept) 코드 밖에 없다.

책임을 지는 일은 극히 드물다.

잘되면 자신의 덕이고, 일이 잘못되면 그들의 지시를 '제대로' 따르지 않은 개발자 탓이다.

이들은 코드를 작성하지 않기 때문에 항상 자신의 존재 이유를 증명해야 한다는 압박이 있다.

이들이 취미로 하는 일은 인터넷에서 새로운 기술 약어를 찾는 것이다.

이들은 어떤 비싼 기술에 대한 광고 자료를 읽고서 멋진 파워 포인트 문서를 만들고,

신참 개발자들에게 프로토타입을 만들어 보라고 시킨다.

그리고 관리자를 꼬드겨 개발자들이 자신의 가이드를 따르도록 명령하게 만든다.

이들은 아직 비즈니스 담당과 개발팀 간에 요구사항 정리조차 되지 않은 시점임에도

프로젝트를 위한 기술 스택을 정의하는 것이 자신의 업무라고 믿는다.

 

좌불안석

다른 사람으로 대체되어 직무를 잃거나 해고될까 봐 걱정한다.

자신의 실제 가치를 알게 될까봐 두려워한다.

실체를 폭로할 위협으로 바라 본다.

 

팬보이

이런 종류의 개발자들은 특정 도구나 언어 프레임워크에만 아주 오랛동안 전념해서 해당 기술에는 전문가다.

자신이 잘 아는 분야가 그것 밖에 없기 때문에 자신이 전념하고 있는 그것만이

모든 것에 대한 최고의 해결 최강이라고 믿고 다른 모든 대안들을 거부한다.

만약 이러한 사람들의 반대에 부딪힌다면 아주 긴 시간 동안 뜨거운 논쟁을 벌일 준비를 해야 한다.

 

===========================================================================

 

논쟁을 두려워해서는 안 된다.

의견 충돌이 없는 마음 편한 대화만을 기대할 수는 없다.

싸울 준비가 되어 있어야 한다.

당신이 생각하는 내용이 어떤 것이든 말할 수 있는 용기가 있어야 한다.

정직함과 투명함은 소프트웨어 장인이라면 반드시 가져야 할 핵심 가치다.

자신감도 필요하다.

자기가 하는 말이 무엇인지 스스로도 제대로 모르면서 다른 사람을 설득할 수는 없다.

 

단순함을 추구해야 한다.

아이디어나 제안은 아주 명료하고 단순해야 한다.

명료하게 정리부터, 누구든지 이해하기 쉽게 만들어야 한다.

예제를 이용하는 것이 좋다.

제안이 받아 들여지느냐의 여부는,

그 내용도 중요하지만 커뮤니케이션을 얼마나 잘 하느냐가 큰 영향을 미친다.

 

상대방의 언어로 말해야 한다.

사용하는 언어를 배우고 활용해야 한다.

당신의 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다.

제품 오너가 대상이라면 유지보수 비용 절감이나, 릴리즈 주기 단축, 릴리즈 신뢰성 증대

 

말할 내용에 대해 스스로 제대로 이해하고 있어야 한다.

연구하고, 실험하고, 연습해야 한다.

어떤 반대 의견이나 문제 지적이 있을지 미리 생각하고 수용될만한 답을 미리 준비해둬야

 

제안이 가진 단점이나 예상되는 문제 상황은 질문이 나오기 전에 미리 밝혀야 한다.

충분한 정보가 없다면 그 부분을 미리 투명하게 고백해야 한다.

미리 밝히는 것은 당신이 충분히 깊이 생각했다는 것을 보여주고 제안 자체에 대한 신뢰성을 높인다.

 

상대방을 존중해야 한다.

경청하는 법을 배운다.

당신만이 좋은 아이디어를 갖고 있다고 오판

모두의 말을 경청하고 정리해보아야 한다.

 

실현하기가 얼마나 어려운지 짐작할 수 있게 된다.

신뢰를 쌓으라

사람들이 당신을 믿어 주지 않는다면 아무런 변화도 이루어낼 수 없다.

지속적으로 품질 좋은 소프트웨어를 딜리버리

품질 좋은 소프트웨어는 설계, 변수나 함수의 네이밍,

의미 있고 가독성 높은 테스트 코드, 중복이 없고 장황하지 않은 코드

 

모두 만족하고, 버그가 없고, 일정 안에 딜리버리되는 것이다.

돈을 벌거나, 돈을 절약, 매출을 지켜주는 것

 

자신의 열정을 보여 주는 사람을 훨씬 더 잘 따른다.

신뢰를 쌓으려면 역량이 있어야 한다.

당신이라면 그 일을 해낼 수 있을 것만 같은 느낌이 들어야 한다.

당신이 그들을 이끌어 줄 것이라고 느껴야 한다.

 

전문성을 확보하라

훨씬 더 나은 미래

설계 변경, 업무 절차 변경, TDD 활용

새로운 기술을 제안하기 전에, 본인 스스로 충분히 이해

프로토타이핑, 다른 기술과 비교

 

다른 사람에게 가르쳐줄 수 있어야 한다.

개인 시간을 들여서까지 새로운 기술이나 실행 관례를 스스로 공부하고 마스터하려는 사람은 많지 않다.

당신의 학습과 시행착오에 대한 경험은 다른 사람들의 학습 곡선을 단축시키는 데 도움이 될 수 있다.

겸험이 쌓일 수록 당신의 영향력은 커진다.

더 나은 프로페셔널

 

직접 보여 주면서 따라하게 하는 것이 가장 좋은 방법

소프트웨어 설계,

깨끗한 코드,

작업 주기 계획,

개발자 동기부여,

업무 압박에 대한 대응,

신뢰 관계

 

그런 일은 절대 일어나지 않는다.

혼자서 모든 이슈와 조직 전체를 상대로 두고 싸울 수는 없다.

한 번에 한 가지씩 신중하게 싸울 곳

 

코드의 일부를 수정

무능한 개발자를 쫓아내고 실력 있는 개발자를 데려오는 일

버그들을 없애는 일

전체 애플리케이션을 버리고 새로 작성하는 일

해외 개발팀과 벤더들을 관리하는 일

관료제를 없애는 일

모든 것을 한꺼번에 추진하는 것은 비현실적일 뿐만 아니라 불가능했다.

조직 문화를 바꾸는 것

 

당신이 준비되어 있지 않다면 조직의 소프트웨어 개발 절차를 바꿀 수 없다.

모든 이슈들이 똑같이 중요하지는 않다.

의미 있는 곳에 노력을 집중하고 더 빨리 가치를 얻을 수 있는 싸움에 우선순위를 두자.

 

윤리의식과 행동원칙이 있다.

자신의 일과 커리어를 스스로 통제한다.

준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자

무슨 일이 일어나든 항상 진실을 말해야 한다.

 

일정에 맞추어서 제품이 딜리버리되고,

예산을 지키고, 버그가 없는 것에 관심을 가질 뿐이다.

일의 진척 상황에 대해서 정직하고 투명하게 말해야 한다.

단, 직접적인 질문이 없다면 상세한 구현 내용들에 대해서 일일이 짚어서 설명할 필요는 없다.

 

생산성 향상, 비용 절감, 매출 증대, 일정 준수, 버그 감소, 예측 가능하고 꾸준한 개발 속도, 비즈니스 요구사항의 충족

무언가 바꾸고 싶다면 그 변화들이 상사가 관심을 가지는 요소들에 어떤 영향을 미치는지 생각해야 한다.

 

몰상식한 사람들은 무시하자.

논리적인 논쟁을 하려 하고 내가 주장하는 바로부터 무언가를 더 알아내려는 사람에게 집중하자.

모두가 참여하도록 만드는 데 주의를 기울이자.

무언가를 더 나아지게 만드는 데 목적을 두어야 한다.

열정을 공유하고, 모범을 보임으로써 사람들을 이끌고, 정직하고 투명해야 한다.

자신감을 축적하고 당신이 아는 것을 다른 사람들에게 가르쳐 주는 행위는 주변 사람들에게 신뢰를 쌓는 최선의 방법이다.

누군가가 따르고 싶어하고, 조언을 듣고 싶어하는 사람이 되어야 한다.

 

상아탑 아키텍트

가치와 아이디어의 충돌

이해하려 들지는 않는다.

책임을 진다고 이야기하길 좋아한다.

소프트웨어 모듈들을 파워포인트 장표의 작은 박스들로만 그릴뿐 실제 그 모듈들의 내용을 이해하지는 못한다.

작성한 코드도 존재하지 않기 때문이다.

잘못된 아키텍처 설계로 인해 많은 개발자들이 고통 받을 때 그는 아무런 고통도 느끼지 못한다.

 

논쟁을 한다면 영혼이 빨려나가는 듯한 느낌을 받을 것이다.

만약 어떤 이유로든 일이 잘못되면, 나는 분명하게 가이드를 줬다 라고 발뺌해버리기 쉽다.

몇 장의 다이어그램이거나 웹사이트 URL 몇개가 전부이다.

 

프로젝트에 관계된 사람들 모두에게 메일을 쓰겠습니다.

자신의 결정에 책임을 질 수 있어야 해요.

뭔가 잘못되었을 때 누군가가 책임을 묻는다면 기꺼이 받아들일 것입니다.

 

어떤 배경에서 이루어졌는지, 어떤 도구들과 라이브러리들을 비교해봣는지 자료를 올리겠습니다.

우리 애플리케이션이 많은 애플리케이션들로 구성된 큰 에코시스템 안에서 동작한다는 것을 이해하고 있습니다.

외부 모듈과의 연동에 대한 가이드라인이라면 따르지 않을 이유가 없지요.

이 논쟁 이후에 외부의 영향 없이 자유롭게 의사를 결정했다.

 

진정한 소프트웨어 프로페셔널은 권한에는 항상 책임이 따른다는 것을 이해하고 있다.

권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다.

책임이 주어져 있다면, 관련된 의사결정에 권한도 가질 수 있도록 해야한다.

관료주의와 정치 뒤에 숨는다.

그들이 당신 앞을 가로막는 것을 피하고 싶다면, 그들의 결정에 책임지도록 만들어야 한다.

 

소프트웨어 장인이라면, 기술적인 역량뿐만 아니라 주니어 개발자들을 위한 롤 모델 역할도 할 수 있어야 한다.

정직하고 투명해지기를 두려워하지 않는다.

고객을 속이거나 문제를 숨기는 방법으로 일을 하지 않는다.

진심을 말하며 자신의 행동에 책임을 지고 프로젝트를 위해 최선이라면 싸우기를 주저하지 않는다.

 

완벽한 솔루션을 전달해야 한다.

모르는 정보를 알고 있거나, 자신감이 부족하거나 어쩌면 두려움때문일 수 있다.

일을 잘 해내려면 소통을 명확히 해야 한다.

신뢰를 쌓는 방법을 알고 있어야 한다.

변화를 이끌기 위한 핵심적인 요소다.

대화하는 상대방을 이해하고, 공감할 수 있어야 한다.

자신을 준비시키고 용감해지고, 주도하자.

결국엔 신뢰다.

 

품질은 선택사항이 아니다.

비용이나 시장 타이밍과 같은 트레이드오프 문제만 없다면, 항상 높은 품질을 기대한다.

일정과 비용을 맞추기 위해서 어쩔 수 없이 품질을 희생해야 한다고 말할 때도

고개를 끄덕이면서 속으로는 결과물의 품질이 좋기를 기대한다.

 

현실적으로 시간과 돈은 마음대로 늘릴 수 있는 것이 아니다.

어떤 결정을 하든지 간에, 심지어 저품질을 선택해야 하는 경우에서도 항상 품질이 좋기를 희망한다.

경험 많은 장인으로 이루어진 팀은 하루에도 몇 번씩 수정된 소프트웨어를 배포할 수 있다.

실행 관례의 준수로 인해 업무 속도가 늦어진다는 것은 있을 수 없는 일이다.

 

수작업으로 테스트하느라 시간을 낭비할 필요도 없고 버그를 고치느라 업무가 중단되지도 않는다.

학습 곡선을 당기고 멘토링하는 데 관심을 기울여야 한다.

스스로 충분히 능숙해져야 한다.

 

리팩토링을 위한 리팩토링은 시간낭비다.

특별한 이유도 없이 코드를 열어서 재정리하는 일은 아무런 의미가 없다.

처음 발견했던 것보다 더 깨끗하게

레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래 보다 깨끗하게 만들어 놓아야 한다.

 

새롭게 추가할 기능이 레거시 코드에 큰 영향을 준다면 사전에 영향이 가해지는 부분을 리팩토링하는 것이 바람직하다.

새로운 기능을 받아들이기 쉬운 상태로 만들어야 한다.

즉 확장에는 열려 있고 변경에는 닫힌, OCP 원칙을 준수할 수 있도록 코드를 리팩토링한 후에 신규 기능을 추가한다.

 

같은 팀이 되어 도와야 한다.

어떤 상황에서든 필요한 일이다.

백로그 상세화, 단순히 작업 우선 순위나 사용자 스토리가 아닌 비즈니스 자체의 운영방식을 바꿔야 하는 것들도 있었다.

빨리 만들었다는 것이 엉망이다 라는 것이어서는 안 된다.

 

어떤 방식으로 그것을 동작하게 만드느냐이다.

비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다.

문제를 단순하고 우아한 방법으로 해결하는 것은 복잡하고 과잉된 방법으로 해결하기보다 훨씬 더 어렵다.

 

그들은 코드 한 줄도 짜지 않고 문제를 해결할 방법을 찾는다.

가장 훌륭한 코드는 작성할 필요가 없는 코드다.

 

잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다.

가장 중요한 부분으로 코드가 해야 할 일을 해낸다.

코드는 버그와 고통의 근원이다.

더 적게 작성할수록 더 좋다.

 

- 명료하고, 충분히 표현되고, 인관되어야 한다.

- 중복이 있어서는 안된다.

- 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

 

명료함을 항상 우선시한다.

도메인 기반 설계, SOLID 원칙

오염되는 것을 막아준다.

 

미래를 위한 모든 것이 일반화, 범용화해야 했다.

범용 코드는 물론 좋다. 하지만 공짜가 아니다. 코드가 범용화될수록 더 복잡해진다.

 

문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다.

나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

 

실용주의가 없는 장인정신은 장인정신이 아니다.

고객의 만족이다.

품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다.

 

섣부른 과잉 설계(BDUF: big design up-front) X

깨끗하고 잘 작성된 코드는 항상 중요하다.

깨끗하고 잘 작성된 코드는 비즈니스의 요구에 맞추어 빠르고 안전하게 변경할 수 있는 기반이 된다.

요구사항의 변화에 맞추어 코드를 빠르게 바꿀 수 있는 것이 비즈니스를 돕는 최선의 방법이다.

 

새로운 스킬, 새로운 실행 관례, 새로운 기술

배우고 마스터하는 것은 병목점이 된다.

시간이나 비용과 같은 대가가 따르지 않는다면 항상 높은 품질을 선택해야 한다.

 

===========================================================================

 

장인의 길

여정, 개발과 자신의 직무에 열정적이다.

문제를 단순한 방법으로 푸는 데 열정적이다.

배우고 가르치고 공유하는 데에도 열정적이다.

진화하도록 돕는 데도 열정적이다.

그들의 코드를 공유하고, 멘토링하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다.

 

기술 커뮤니티 활동에도 열정적이다. 겸손하다.

항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.

사회적 윤리적 의무감을 느껴야 한다.

프로페셔널해지도록 만들어야 한다.

최선을 다해 역량을 마스터할 과업

항상 최고의 코드를 만들도록

희생해서라도 계속해서 배우고 남을 도우리라는 각오

 

새로운 것에 대해 호기심

특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다.

항상 주어진 문제에 가장 적합한 도구를 찾고 단순히 해결책을 추구한다.

 

몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다.

도구들이 없다면 장인이라고 할 수 없다.

코드 작성이 아니라 문제 해결에 집중한다.

가능하고 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는 데 집중한다.

 

장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다.

엉망인 코드, 작성자 본인 외에는 아무도 이해할 수 없는 코드로 하여금 남아 있는 개발자들의 지탄을 받을 일을 만들지 않는다.

긍정적인 일들로 연상되는 존재여야 한다.

통찰력 있는 기여, 열정, 지식, 훌륭한 동료로서 인정받는다면 더할나위 없다.

 

정직과 용기란 필요한 상황에서 고객에게 아니오라고 말할 수 있는 것을 의미한다.

비현실적인 요구를 할 때 고객과의 껄끄러운 상황이 발생할 것을 알면서도 그 요구가 제대로 반영되기 힘들다라고 전달하는 것이다.

즉 고객이 나쁜 의사결정을 할 때 그것이 적절치 못하다고 지적하는 정직함과 용기를 말한다.

장인은 스스로 판단하기에 무언가 올바르지 않은 결정을 그대로 추진하거나 책임지지 않을 것이라는 점을 고객에게 분명히 밝힌다.

 

모든 아니오에는 항상 대안을 제시해야 한다.

정직과 용기, 완전한 투명성에 의해서 이루어진다.

 

성공한 소프트웨어 장인은 스스로의 커리어를 매우 신중하게 계획한다.

무언가를 배우고 더 나은 프로페셔널이 되기 위한 기회들을 찾는다.

 

많은 개발자들에게 새로운 직장을 찾는다는 것은 내가 지금 가진 지식과 시간을 제공해서 최대한 많은 급여를 대가로 받겠다는 의미다.

프로페셔널이라면 직장은 급여 이상의 의미가 있다.

직장은 그들의 커리어를 위한 지속적인 투자다.

 

우리의 열정과 헌신 그리고 업무 외 개인 시간을 들여 확보한 지식들을 투자하여 일터를 더 나은 곳으로 만든다.

배우고 성장하는 장이 되게 한다.

일터를 더 나은 곳으로 만드는 데 투자한다는 의미는 우리의 커리어를 더욱 풍요롭게 할 수 있는 기회를 늘린다는 것과 같다.

 

나는 단순히 주어진 업무에만 집중한 적은 한번도 없다.

언제 어디서도 그건 내 업무가 아닙니다. 라고 말한 적이 없다.

나는 항상 더 많은 것을 제공하고 더 많은 일을 수행해서 내 주변 모두가 더 나아지도록 노력했다.

내 역할과 직급이 무엇이든 상관없이 내가 할 수 있는 최선의 도움을 주려 노력했다.

나의 투자라고 생각한다.

내 일을 위한 투자일 뿐만 아니라 개인의 커리어를 위한 투자이기도 하다.

 

투자에 따른 이익

기대하는 이익의 종류는 나의 개인적인 또는 업무적인 삶의 변화에 따라 매번 달라진다.

특정 기술이나 산업을 접하거나, 새로운 형태의 프로젝트를 경험하거나,

다른 스킬을 개발할 수 있는 기회를 얻거나,

다른 역할 또는 다른 형태의 책임을 수행하거나,

금전적 이익, 금전적인 이익은 우선순위에서 높지 않는다.

 

평균적으로 2년마다 회사를 옮겼다.

5년이나 머문 곳도 있고 어떤 회사는 3개월 만에 나와야 했다. (모두에게 양해를 구하고)

하상 신중하게 다음 직장을 찾았다.

내가 겪어온 모든 업무들은 나의 커리어를 진전시키는 데 도움이 됐다. (프로가 되기 위한 여정)

 

- 나의 커리어로부터 나는 무엇을 원하는가?

- 그것을 성취하기 위한 다음 단계는 무엇인가?

- 이 일은 나의 커리어 방향과 합치하는가?

- 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?

- 그러한 투자에 대한 이익은 무엇인가?

- 얼마 동안 지속되어야 하는가?

- 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?

- 자율성, 통달, 목적의식

- 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?

 

익숙한 공간을 벗어나 바깥 세상을 경험할수록 나는 아직 한참 멀었다는 것을 깨달았다.

새로운 사람은 새로운 아이디어와 더 많은 에너지로 정제된 상황에 도전하고 훌륭한 일을 해낼 수도 있다.

매년 15% ~ 30% 정도씩 구성원이 바뀌는 것은 회사에 매우 득이되는 일이라고 생각한다.

새로운 사람들은 회사를 최신의 정보에 밝아지게 하고 경쟁력 유지와 분위기 쇄신에 도움이 된다.

 

그 사실을 인정하는 데는 상당한 용기가 필요하다.

하지만 한번 인정하고 나면 모든 것이 더 나아진다.

마음을 열고 사람들을 만나는 것이다.

커뮤니티 행사에 참석하고, 오픈 소스에 기여하고, 토론 메일링 리스트에 참여한다.

 

직업을 대하는 태도에 있다.

말이 아니라 행동에 의해 규정된다.

가치와 프로페셔널한 태도를 지칭

개방적으로 받아들인다.

모두 투명함과 짧은 피드백 루프를 통해 고객에게 가치를 전달하는 데 집중한다.

 

728x90
댓글