DevOps/좋은 글

개발자에 있어서 경계해야 하는 점 : 소프트웨어 집단의 부패, Expert Beginner의 유산

게임이 더 좋아 2022. 6. 26. 14:27
반응형
728x170

원문을 의역하신 것을 내가 다시 가져왔다.

정말 좋은 글이기에 나에게 도움되는 문구만 추려보려고 한다.

또한 내 코멘트를 붙이면서 느끼고자 한다.

 


 

 

“Expert Beginner”라는 용어를 자신의 테두리가 곧 전체의 테두리라고 굳게 믿고, 지역적 최고점에 도달한 후 배움을 멈춘 개발자들을 표현하기 위해 사용했다.

=> 내가 아는 것이 전부라고 생각하는 사람이면서 배움을 포기한 사람.

“Expert Beginner” to describe someone who has capped out in their learning at some sort of local maximum, convinced that the local is global.

=> local maximum과 global maximum을 착각하는 사례는 흔히 ML,DL에서 나오기도 한다.

=> 다시 말해서 내가 한 분야에 대해서 잘 안다고 자부하는 순간 배움을 멈춰버리는 것이다.

=> 개발자는 끊임없이 공부해야 하는 숙명을 가지고 있다.

 


 


Expert Beginner들은 큰 그림을 볼 수 있을 정도의 역량이 없으므로 자신들이 expert가 아니라는 사실을 자각하지 못한다.

=> 자신들이 Expert라고 착각한다는 말이다.

=> 즉, 자신들이 여태까지 노출되었던 환경이 곧 전체이자 유일한 방법이라고 생각할 정도로 시야가 좁다는 뜻이다.

Expert Beginners are developers who do not understand enough of the big picture to understand that they aren’t actually experts.

What I mean by this is that they have a narrow enough perspective to think that whatever they have been exposed to is the best and only way to do things

=> 다시 말해서 내가 겪어보지 않았고 겪어볼 생각도 없기에 내 세상에서는 통하기에 아직도 나는 그 분야를 잘 안다고 착각하는 것이다.

=> 적어도 그 환경에서는 내 실력과 믿음이 깨질 일은 없다.

=> 그렇기 때문에 Expert Beginner가 되는 것이다. 회사에선 무능력하게 평가받지는 않는다.

 



단순히 특정한 기술을 싫어하거나 사용해보지 않았다고 해서 Expert Beginner가 되는것은 아니다.

“내 기술스택 안에 들어있지 않거나 내가 경험해보지 않은거라면, 딱히 값어치 있는게 아니다” 라고 결론 짓는 자기중심적인 마인드를 말하는 것이다.

This isn’t to say that not liking a technology or not having worked with one makes someone an Expert Beginner, but rather the vaguely solipsistic mindset that “if it’s not in my toolchest or something I’ve had experience with, it’s not worth doing.”

=> 특정 기술을 싫어하는 것과 사용하지 않은 것과는 별개다. 다만 그 이유가 내가 하기 싫어서, 값어치가 없는 것 같은 느낌이라서와 같은 추상적인 이유와 말도 안되는 변명이라면 그것이 맞다.

 

 

 

또 다른 Expert Beginner의 특징은 일반적으로 그들이 소프트웨어 집단 내에서 어느 정도의 권위나 영향력을 가진 위치에 올라 있다는 것이다.

Another characteristic of the Expert Beginner, however, is that they have some position of relative authority or influence within a software group.

 

=> 내가 영향력을 가진다면 가장 경계해야 하는 점이 아닐까 싶다.

=> 영향력이 있다면 자신이 어떤 역할을 하는지 어떤 영향을 주고 있는지 다시 재고할 필요가 있다.

=> 영향력이 있는 자리로 올라가면 생기는 특징 중에 하나인 듯 싶다.

 

 


 

대표적인 예를 들어보자. IT 계열이 아닌 작은 회사의 “tech guy가 있다고 치자.

그는 “컴퓨터를 꽤 하는” 사람이고, 회사가 성장함에 따라 IT 기술이 필요해져서 프로그래머가 된다. 컴퓨터를 잘 다루는 파워 유저에서 개발자가 된 그는, 자신이 기대했던 것 보다 더 많은 기술을 습득하고, 자신의 제한된, 그리고 제대로 교육받은 적 없는 능력에 대해 자신감을 가지게 된다.

=> 스타트업에서 흔히 일어나는 일이라고 생각한다. 경력자가 없는 집단, 경력자더라도 이미 고착화된 집단


같은 일을 하는 동료도 없으니 그의 기술을 평가할 수 있는 사람은 나 자신과 IT 지식 없이 “어쨌든 되기는 하는것 같애, 아마도” 라는 칭찬을 해주는 사람들 뿐이다.

=> 잘한다고 생각하고, 다른 사람도 잘한다고 믿는다.

=> 내가 잘한다고 생각할 때, 다른 사람이 칭찬할 때.. 자아도취하지 말자.

=> 잘하는 것은 없다. 다만 익숙해질 뿐

The iconic example might be the “tech guy” at a small, non-technical firm.

He “knows computers” so as the company grew and evolved to have some mild IT needs, he became a programming dilettante out of necessity. 

In going from being a power user to being a developer, his skills exceeded his expectations, so he became confident in his limited, untrained abilities. Absent any other peers in the field, the only people there to evaluate his skills are himself and non-technical users who offer such lofty praises as “it seems to work, kind of, I think.”

 

그는 장님들만 있는 거리의 외눈박이이며, 굉장히 현실적이고 동시에 불운하게도, 지역적(local) 전문가이다. 이 예시의 등장인물은 Expert Beginner가 되기에 매우 좋은 조건들을 갖추고 있다.

쉽게 성공할 수 있고, 요구되는 기준이 낮으며, 진짜 전문가들은 존재하지 않고, 경쟁도 없으며, 외부와의 교류도 없다.

 

 He is the one-eyed man in the valley of the blind and, in a very real and unfortunate sense, a local expert. This is the iconic example because it has the fewest barriers to Expert Beginnerism–success is simple, standards are low, actual experts are absent, competition is non-existent, and external interaction is not a given.

 

=> 개인적으로 요즘 스타트업은 아니겠지만 예전에 만들어진 스타트업과 중소기업에서는 이런 일이 많다고 들었다.

=> 모든 것을 일반화하려는 것은 아니며 실제 사례와 경험을 전해들은 것이다.

 

 


 

부분이 썩으면 전부 썩게 된다

 

 

볼링장들의 매출이 선수들이 얼마나 볼링을 잘 치는가에 달려 있다고 가정해보자.

Let’s say that bowling alleys make their money by how well their bowlers bowl and that I live in a small town with a little, startup bowling alley.

=> 볼링장에는 잘 치는 사람들이 많을수록 좋다.

=> 실력 있는 사람이 볼링장의 성장을 불러온다.

 

나나 그들이나 내가 뭘 하고 있는지는 잘 모르지만, 내가 거기서 볼링을 치기 시작한 후로, 자세가 우스꽝스럽긴 해도 나의 실력이 빠르게 느는 것을 발견한다. 평균점은 올라가고, 볼링장은 돈을 벌고, 모든게 완벽하다. 이윤과 성공적 커리어 앞에서 누가 불만이 있겠는가!

=> 내가 한 행위로 인해 점수가 높아져서 나는 이전보다 잘 치는 사람이 되었다.

=> 볼링장은 내가 잘치는 사람이라고 생각한다.

=> 이후의 인력들도 잘치기를 바라며 나에게 부탁한다.

 

I don’t really know what I’m doing, and neither do they, but we both see me improving rapidly as I start bowling there, in spite of my goofy style. My average goes up, the bowling alley makes money, and life is good–there’s no arguing with profit and success!

 

 

내 평균이 150을 웃돌고 나의 성장세에 끝이란 없을 것 처럼 보일 때 쯤, 볼링장은 조금 더 확장해서 몇몇 초보 선수들을 영입하여 내 밑에서 일하게 하기로 결정한다.

=> 볼링장은 못하는 선수도 성장시켜주길 바라면서 인력을 투입한다.

=> 다만 성장시킨다는 것이 실제로 회사의 지속적인 성장을 가져올지는 모른다.

=> 여기서는 160점까지 성장시켜줄 수는 있으나 그 이상을 올라가지 못한다.

=> 이것도 성장이라 본다면 성장이지만 결국 160점이란 한계를 맞이한다.

 

그들의 첫 출근 날, 나는 어떻게 공을 드는지를 보여주고, 어떻게 나처럼 걷는지를 가르친다. 그들이 엄지와 손가락 구멍들은 어디에 쓰는거냐고 물어보면, 나는 그냥 “아 그건 신경쓰지마. 여기선 그거 안 써.’ 라고 대답해 준다.

열심히 하는 모습을 보이기 위해 신입들은 내 말을 그대로 따르고, 내가 그랬듯 점수가 오르기 시작한다. 나는 160 언저리에서 서서히 정체기를 맞이하고 있는데도.

=> 무엇이 잘못된지 모르는 채 처음보다 성장했다. 올바른 방법이라고 맹신하는 모습이다.

 

Around about the time my score was topping 150 and the sky seemed the limit, the bowling alley decided that it was time to expand and to hire a couple of entry-level bowlers to work under my tutelage.

On the day they arrived, I showed them how to hold the ball just like I hold it and how to walk just like I do. When they ask what the thumb and finger holes are for, I respond by saying, “don’t worry about those–we don’t use them here.

Eager to please, they listen to me and see their averages increase the way mine had, even as I’m starting to top out at around a 160 average.

=> 여전히 나는 정체되어 있다. 하지만 정체된 것은 인지하지 못하고 그저 바로 되는 방법만 추구하고 있다.

 

 

시간이 지나고, 그들 대부분은 내 식대로 하는 것에 만족한다.

=> 당장은 성장하는 것이 보인다. 아니, 다시 말하자면 성장하는 것처럼 보인다.

하지만 몇몇은 의지가 충만하여 여유 시간에 연습을 따로 하기 시작한다.

그들은 책을 읽고, 볼링 기술에 대한 방송도 시청한다. 그러던 어느 날, 그들이 나에게 “TV에서는 손가락을 공 안에 넣고 쳐서 엄청 높은 점수를 내던데요. 200 이상요!” 라고 말한다.

=> 새로운 경험과 지식에 열려있는 인력들이 들어온다.


그들은 내가 자신들 만큼이나 성장에 관심이 있기를 기대하지만, 나는 이렇게 반응하고 그들은 풀이 죽고 만다.
“아냐. 여기선 그렇게 안 해. 나는 너희들이 태어나기 전부터 볼링을 했고, 내가 어떻게 하고 있는지는 내가 제일 잘 알아… 그리고, TV에서 나오는 걸 다 믿으면 안돼.”

=> 내가 성장해온 길이 있기 때문에 성장을 하는 방법은 이것 밖에 없다고 생각하는 관리자

=> 새로운 성장의 기회가 열렸음에도 알아차리지 못하고 오히려 역행한다.

 

As time goes by, most of them are content to do things my way.

But a couple are ambitious and start to practice during their spare time.

They read books and watch shows on bowling technique. One day, these ambitious bowlers come in and say, “the guys on TV put their fingers in the ball, and they get some really high averages–over 200!”

They expect me to be as interested as they are in the prospect of improvement and are crestfallen when I respond with, “No, that’s just not how we do things here.

I’ve been bowling for longer than you’ve been alive and I know what I’m doing… besides, you can’t believe everything you see on TV.”


그렇게 나는 내가 볼링장에서 더 오래 일했으니, 나에게 결정권이 있다는 것을 그들에게 상기시킴으로써 집단의 혁신을 빠르고 확실하게 제거한다. 이것은 보편적으로 사용되는 완벽히 불합리한 추론으로, 대화를 불만족으로 끝맺음 짓는 방법이다.

=> 군대에서와 같은 예전부터 해온 방법

=> 물론 좋은 전통까지 매도해서 까려고 하는 것은 아니다. 하지만 왜 이렇게 하며 어떻게 하면 더 잘할 수 있지에 대한 생각은 열어두어야 한다고 생각한다.

 

이 시점에서, 열정적인 선수들 중 절반은 “공 안에 손가락을 넣는” 방법을 포기하고, 절반은 다른 볼링장에서 퇴근 후에 만나 조용히 연습을 한다.

시간이 지나 그들의 점수는 내 점수를 제치고, 그들은 이 접근법이 더 우수하다는 것을 객관적으로 증명했으니 변화를 일으킬 수 있다고 믿게 된다.

하지만 내가 화를 내며 그들의 성과는 그저 꼼수일 뿐이며, 나도 한번은 205점을 낸 적이 있다고 한바탕 설교를 하고 나자 그들은 남은 동료들을 두고 사라진다. 그들은 나의 꽉 막힌, 역행하는 볼링장을 떠나, 고작 고집 때문에 저급한 방법을 선택하지는 않는 곳으로 떠나게 된다.

볼링장은 가장 높은 점수를 내는 선수들을 다른 볼링장이 아닌, Expert Beginner에게 빼앗겼다.

=> 더 좋은 인력이 내부 사람으로 인해 사라졌다.

=> 회사라는 조직이 썩어가는 과정

 

And thus, quickly and decisively, I squash innovation for the group by reminding them that I’m in charge by virtue of having been at the bowling alley for longer than they have.

This is a broadly accepted yet totally inadequate non sequitur that stops discussion without satisfying.

At this point, half of the ambitious developers abandon their “fingers in the ball” approach while the other half meet after bowling at another alley and practice it together in semi-secret.

After a while, their averages reach and surpass mine, and they assume that this development–this objective demonstration of the superiority of their approach–will result in a change in the way things are done.

When it instead results in anger and lectures and claims that the scores were a fluke and I, too, once bowled a 205 that one time, they evaporate and leave the residue behind.

They leave my dead-end, backward bowling alley for a place where people don’t favor demonstrably inferior approaches out of stubbornness.

The bowling alley loses its highest average bowlers not to another alley, but to an Expert Beginner.

 


 

결국 썩어버린 전체

떠나지 않은 볼링선수들은 두가지 흥미로운 교훈을 얻게 된다.


첫번째는 그들이 자신의 차례를 기다리면, 실제 능력과 상관없이 무조건적인 권력을 얻게 된다는 것

=> 분명 오래 헌신한만큼 대우하는 것은 당연하다. 로열티도 충분하다. 다만 열려있는 생각을 가졌어야 했다.

The first lesson they learn is that if they wait their turn, they can wield unquestioned authority regardless of merit.

 

두번째는 이 볼링장에서는 그저 그런 상태로 있어도 괜찮거나, 심지어는 더 좋을 수도 있다는 것이다.
그래서 새로운 선수들이 고용되었을 때, 회사의 ‘라인’을 유지하고 본인들의 차례를 기다리기 위해서 그들의 과거 경험 그대로 신입들에게 나쁜 방법을 강권하는 것에 동참한다.

=> 오래된 방법에 익숙해진 사람들은 새로운 것을 두려워하며 새로운 것이 나의 자리를 빼앗을 것이라 생각하며 새로운 것을 하려는 사람을 배척한다. 

=> 이는 나와 같은 사람만 양산할 뿐이다.

=> 결국 회사라는 단체는 무능한 집단이 되어버린다.

 

The second lesson they learn is that it’s okay and even preferred to be mediocre at this alley.

So when new bowlers are hired, in the interests of toeing the company line and waiting their turn, they participate in the inculcation of bad practices to the newbies the same way as was done to them.

 

또 하나의 흥미로운 전개는 채용 프로세스에 미치는 영향이다.

수석 Expert Beginner로서, 나는 배운게 있다. 열정 넘치는 어린 신입들을 만나기 싫은 나는, 채용 프로세스를 그저 그런 “팀 플레이어”들을 모집하는 방향으로 바꾼다.

=> 나에게 맞는 사람을 모집할 것인가?? 회사의 성장을 위한 사람을 모집할 것인가??

=> 정답은 없다. 내가 일하면서 바뀔수 도 있는 것이고 회사의 성장을 위한 사람을 뽑았어도 나로 인해 나갈 수도 있을 것이다.

 

 

이 채용 결정은 명시적인 행동이라기보다 무의식, 혹은 합리화에 가깝다. “나보다 더 나은 사람들은 채용하지 않겠다” 가 아니라 “이 사람들은 나의 ‘고정관념을 깨는’, 또한 ‘전문적인’ 방법들과는 어울리지 않아” 라고 생각하는 것이다.

=> 하지만 이런 생각을 가짐으로 인해 회사는 성장을 포기하게 된다. 틀림과 다름을 구분하지 못하는 지경까지 이르렀다.

=> 이런 경지에 이른다면 채용 프로세스에서 False Positive 같은 말도 안되는 경우가 발생할 것이다.

 

심지어, 나는 나의 Expert Beginnerism에 너무 빠져버려서 Competent 혹은 Expert 수준의 작업과 무능한 수준의 작업을 구분할 정도의 지식도 갖추지 못하여, 이 둘을 혼동할 가능성 마저 있다.(조금 더 설명해 보자면 “볼링 면접”시에 나는 결과가 아닌 자세에만 집중하여 220점을 낸 선수가 내 자세랑은 다르다는 이유로 나쁜 선수라고 생각할 수 있다)

이렇게 함으로써, 나는 나의 새로운 Expert Beginner 중위들을 포함한 모두에게 이런 문화를 강화하게 된다.

 

 

Since I don’t like being shown up by ambitious young upstarts, I begin to alter my recruitment process to look for mediocre “team players” that won’t threaten my position with their pie-in-the-sky “fingers in the ball” ideas.

Now, I know what you’re thinking–doesn’t this level of awareness belie the premise of the Expert Beginner being unaware of the big picture? The answer is no. This hiring decision is more subconscious and rationalized than overt. It isn’t, “I won’t hire people that are better than me,” but, “those people just aren’t a good fit here with my ‘outside the box’ and ‘expert’ way of doing things.” And it may even be that I’m so ensconced in Expert Beginnerism that I confuse Competent/Expert level work with incompetent work because I don’t know any better. (The bowling analogy breaks down a bit here, but it might be on par with a “bowling interview” where I just watched the form of the interviewee’s throw and not the results, and concluded that the form of a 220 bowler was bad because it was different than my own.) And, in doing all this, I’m reinforcing the culture for everyone including my new Expert Beginner lieutenants.

 


현실로 돌아와서

 

볼링장 이야기는 그렇다 쳐도, 이 이야기가 실제 소프트웨어 개발 환경에 적용 가능할까?

꽤 간단히 가능하다.

자동화 테스팅의 부재. 거대한 함수나 클래스들. 수 많은 복사-붙이기 코딩. 오래 되었거나 적절치 못한 툴 사용. 프로세스들. 예를 들자면 끝이 없지만

중요한 것은 부족한 지식으로 점철된 치명적인 문화를 가진 사람들이 힘 있는 위치에 있다는 것이다.

=> 영향력이 있는 사람이 어떤 사람인가? 중요해짐

=> 리더가 가지는 책임감

 

자신들이 무엇을 모르는지 자각하지 못하고, 전문가인 본인들이 모르는 것은 알 필요가 없다는 생각.

이것은 재능있고 열정적인 사람들을 떠나게 하거나 혹은 그저 그런 집단에 합류하게 만드는 유해한 문화이다.

=> 유해하다. 나는 그런 사람이 아닌가 항상 경계해야 한다.

=> 리더는 모른다는 것을 인정하고 배워야 한다. 리더는 스페셜리스트보다 제너럴리스트가 되어야 한다.

=> 자신의 영역 외의 것도 중요함을 인정해야 한다.

 

이 Expert Beginner들은 사실은 인격적인 문제가 없을 수도 있다.

나는 이것이 외부와 격리된 환경, 낮은 기대치, 그리고 실제로 효율성 산출이 불가능한 그저 그런 수행능력에 대한 꾸준한 보상이 만들어낸 자연스러운 결과라고 생각한다.

=> 되고 싶어서 된 것은 아니라고 생각한다.

=> 회사의 프로세스가 만들어낸 괴물의 일종일 수 있다.

 

소프트웨어 산업의 특성에 대해 한번 생각해볼 필요가 있다. 릴리즈 일정이 늦어지고, 버그는 많고, 예산까지 초과 했을 때에 따로 릴리즈 팀을 운영하는 회사를 몇번이나 보았는가?

제대로 관리하기가 너무나 힘든 애플리케이션을 포기하고, 처음부터 다시 작성(결국 똑같은 사이클을 언젠가는 반복할걸 알면서)하는 팀은?

마치 작동할 것처럼 보였지만 결국엔 지면에서 떨어지자 멈춰버리고, 추락하는 로켓을 만들고 나서도 승급을 하는 로켓 기술자들 마냥, 그들은 그렇게 하고도 승급을 하고 포상을 받는다.


“뭐, 좀 제대로 안되기는 했어 존스. 그렇지만 너도 이걸 통해 많이 배웠을테니까, 너를 수석 로켓 기술자로 승급시키고 두번째 버전의 설계를 맡기도록 하지. 우리의 록스타, 당신에게 말야!”


이 상황에서 존스가 자신이 마이다스 왕이라고 생각하는 건 놀라운 일도 아니다.

=> 환경도 그렇고 프로세스도 그렇고 사람에게 ~한 형태로 일하도록 만든다.

=> 반복되는 업무 속에서 한 때 빛났던 맘 속의 보석도 빛을 잃어간다.

 

기본적으로 사람들의 소프트웨어에 대한 기대치는 로켓에 비해 훨씬 낮기 때문에 업계에서는 이런 일이 용인되는 것이다.

나는 여기서 업계가 완전히 바뀌어야 한다고 불평하고자 하는 것이 아니다.

다만 외부 피드백과 우리 자신의 인식에 따라 얼마나 쉽게 실제 배운 것보다 많이 알고 있다고 생각하게 될 수 있는지를 설명하려고 하는 것이다.

=> 아는 것과 실제의 괴리가 커지고 있음

=> 이는 회사의 성장을 저해하는 요소 중 하나임

 

That’s all well and good for bowling and bowling alleys, but how is this comparable to real software development practices?

Well, it’s relatively simple.

Perhaps it’s a lack of automated testing. Giant methods/classes. Lots of copy and paste coding. Use of outdated or poor tooling. Process.

It can be any number of things, but the common thread is that you have a person or people in positions of authority that have the culturally lethal combination of not knowing much;

not knowing what they don’t know; and assuming that, due to their own expertise, anything they don’t know isn’t worth knowing.

This is a toxic professional culture in that it will force talented or ambitious people either to leave or to conform to mediocrity.

You may think that this is largely a function of individual personalities, that departments become this way by having arrogant or pushy incompetents in charge, but I think it’s more subtle than that.

These Expert Beginners may not have such personality defects at all.

I think it’s a natural conclusion of insular environments, low expectations, and ongoing rewards for mediocre and/or unquantifiable performances.

And think about the nature of our industry. How many outfits have you worked at where there is some sort of release party, even (or especially) when the release is over budget, buggy and behind schedule? How many outfits have you worked at that gave up on maintaining some unruly beast of an application in favor of a complete rewrite, only to repeat that cycle later? And the people involved in this receive accolades and promotions, which would be like promoting rocket makers for making rockets that looked functional but simply stopped and fell back to Earth after a few hundred feet.

“Well, that didn’t work, Jones, but you learned a lot from it, so we’re promoting you to Principal Rocket Builder and having you lead version two, you rock star, you!” Is it any wonder that Jones starts to think of himself as King Midas?

As an industry, we get away with this because people have a substantially lower expectation of software than they do of rockets. I’m not saying this to complain or to suggest sweeping change but rather to explain how it’s easy for us to think that we’re further along in our skills acquisition than we actually are, based on both our own perception and external feedback.

 


 

정체하지 않고 진전하는 문화 만들기

 

단순하게 표현하자면 자만심을 가진 사람들이, 어떻게 하나의 집단을 만들어내고 동시에 망가뜨리는지에 대해 이야기 해 보았다.

이번에는 이러한 사태를 최대한 방지할 수 있는 비교적 간단한 방법들을 제시해 보려고 한다.

 

첫째로, Expert Beginner의 덫에 빠지지 않기 위해서 제일 중요한 것은 자기 자신의 들뜬 감정을 믿지 않는 것이다.

자신이 한 것에 대해서 적절한 자신감을 가지되, 이성적인 주장 혹은 증거 없이 자신의 학습이 완성 되었다거나, 나는 직급이나 연차가 이 정도 되었으니 질문을 받을 필요가 없다거나 하는 식의 생각을 지양해야 한다. 

=> 만연해 있는 군대식 문화, 까라면 까.

까라면 까도 이유를 알려주고 까는 것은 천지차이. 군대에서 뼈저리게 느꼈다.

 

소프트웨어 집단으로서 이 현상을 막기 위한 방법도 몇가지 리스트로 만들어 보았다.

  1. 팀 멤버들에게 최대한 자유롭게 상상할 수 있는 기회를 주고, 그들이 발견한 방법을 직접 보여줄 수 있도록 독려하라 (성공보다는 실패에서 배우는게 많음을 기억하자).
  2. 새로운 언어, 접근법, 프레임워크, 패턴, 스타일 등을 학습하는 것에 대한 인센티브를 제공하라
  3. 특정 주장이 더 낫다고 평가하거나 수용할 때, 절대로 그 사람의 연차를 근거로 삼지 말아라.
  4. 외부의 의견을 사내에 강제적으로 주입받을 수 있는 정책을 만들어라 (점심시간을 이용한 네트워킹, 월간 트레이닝, 감사 등)
  5. 가능하다면 논쟁이나 의견 충돌이 있을 때 직급이나 투표 등의 주관적 기준이 아닌 좀 더 객관적인 기준으로 해결하라.
  6. 증명하는 문화(culture of proof)”를 만들어라. 실제 레퍼런스, 통계, 사실 등이 확인되지 않으면 그 의견은 없는 것이나 다름 없다.
  7. 주기적으로 주니어와 시니어를 아우르는 설문을 진행하라. 그들의 강점과, 강점의 갯수만큼 자신이 모르는 것, 혹은 알고 싶은 것에 대한 것을 작성하도록 하라. 이것은 사전에 직원들이 (특히 오래된 직원들이) 자신이 “모든 것을 다 안다”라고 생각하게 되는 분위기를 미연에 방지하기 위해서이다.

 

이 리스트는 우선적으로는 매니저와 팀 리더들을 위한 것이지만, 팀 멤버들도 충분히 이러한 변화를 일으킬 수 있다.

차이점은 한쪽은 바로 실행에 옮길 수 있고, 다른 쪽은 관리자들을 설득해야 한다는 점이다.

가능하다면, 몸소 실천해서 보여줌으로써 주도 해보라.

만약 이것이 모두 소용이 없다면

내 개인적인 생각으로는 이미 가망이 없는 것이니 가능성이 있는 곳으로 떠나기 바란다.


팀원 누구든-제일 시니어이거나 최고 경력자라 할지라도- “모르겠다” 라는 답변을 할 수 있는 문화를 만드는 것이 Expert Beginner 들로 인한 집단의 부패를 방지하기 위한 중요한 방책이다.

 

Expert Beginner는 절대로 “모르겠다”라는 답을 하지 않는다.

=> 나는 여기서 전문가이기 때문에 틀릴 일이 없다. 내가 모르는 것은 쓸모 없는 것이다. 내가 가장 잘 알고 있다. 라고 생각하기 때문이다.

 

이는 곧 기술을 배우고 있는 사람과 자신이 이미 알건 다 안다고 생각하는 사람 사이의 중요한 차이이다.

당신의 그룹이 성장하고 있지 않다면, 부패하고 있는 것이다.

 

Having identified a group-(de)forming attitude that could most effectively be described as a form of hubris, I would like to propose some relatively simple steps to limit or prevent this sort of blight.

First of all, to prevent yourself from falling into the Expect Beginner trap, the most important thing to do is not to believe your own hype. Take pride in your own accomplishments as appropriate, but never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way to preventing yourself from becoming an Expert Beginner.

In terms of preventing this phenomenon from corrupting a software group, here is a list of things that can help:

  1. Give team members as much creative freedom as possible to let them showcase their approaches (and remember that you learn more from failures than successes).
  2. Provide incentives or rewards for learning a new language, approach, framework, pattern, style, etc.
  3. Avoid ever using number of years in the field or with the company as a justification for favoring or accepting anyone’s argument as superior.
  4. Put policies in place that force external perspectives into the company (lunch-and-learns, monthly training, independent audits, etc).
  5. Whenever possible, resolve disputes/disagreements with objective measures rather than subjective considerations like seniority or democratic vote.
  6. Create a “culture of proof”–opinions don’t matter unless they’re supported with independent accounts, statistics, facts, etc.
  7. Do a periodic poll of employees, junior and senior, and ask them to list a few of their strengths and an equal number of things they know nothing about or would like to know more about. This is to deflate ahead of time an air of “know-it-all-ism” around anyone–especially tenured team members.

 

This list is more aimed at managers and leaders of teams, but it’s also possible to affect these changes as a simple team member.

The only difference is that you may have to solicit help from management or persuade rather than enforce.

Lead by example if possible. If none of that is possible, and it seems like a lost cause, I’d say head off for greener pastures.

In general, it’s important to create or to have a culture in which “I don’t know” is an acceptable answer, even for the most senior, longest-tenured leader in the group, if you want to avoid Expert Beginner fueled group rot.

After all, an earnest “I don’t know” is something Expert Beginners never say, and it is the fundamental difference between a person who is acquiring skill and a person who has decided that they already know enough. If your group isn’t improving, it’s rotting.

 


 

짧게 다시 요약해보자

1. 연차나 경력이 그 사람이 한 행위에 대한 근거가 되는 것은 좋지 않다.

2. 기존의 방법을 유지할 때는 왜 좋은지 알고 써야 한다. 그렇지 않으면 알지도 못한 채 썩어가고 있는 것이다.

3. 모르는 것이 당연하다. 

4. 모르면 배우고 싶어하는 것이 개발자다.

5. 내가 모르는 것도 유용할 수 있다.

6. 논의를 할 때는 이성적인 근거를 이용해서 판단한다.

7. 학습은 끊임없이 해야 한다.

8. 리더는 팀원들을 이끌어나가는, 회사를 이끌어나가는 중요한 자리다.

.. 등이 있다.

아주 좋은 글이었다.

내가 왜 공부하는지 더 맘 속 깊숙히 느낄 수 있었다.

 

 

 


참고링크

https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner/

https://medium.com/@jwyeom63/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%A7%91%EB%8B%A8%EC%9D%98-%EB%B6%80%ED%8C%A8-expert-beginner%EC%9D%98-%EC%9C%A0%EC%82%B0-9d226b6ebde2

반응형
그리드형

'DevOps > 좋은 글' 카테고리의 다른 글

신규 개발자가 해야 하는 일  (0) 2022.10.26
개발자가 성장하는 방법  (0) 2022.10.10
개발자면 가져야 할 의사소통 능력  (0) 2021.10.07