설계 결함 및 굴욕 처리 [폐쇄]

제안한 소프트웨어 디자인에서 항상 기본적으로 정확 했습니까? 근본적으로 잘못된 디자인을 제공하면 동료 팀원의 존중을 잃는 경향이 있습니다. 당신이 그 후에 무엇을 하든지, 그 사건 이후에 당신이 제안한 모든 것에 대해 교차 점검을받습니다. 이것은 당신이 팀을 처음 접했을 때 특히 나쁘고, 당신이 성공한 이야기가 어디 있는지 과거를 알지 못합니다.

아마도 당신이 나쁜 디자인을 한 이유는 경험이나 지식이 부족하거나 그 분야에 모두 있었기 때문일 것입니다. 그런 상황에 처한 당신은 어떻게 대처 했습니까? 이것은 당신의 경력에서 한 번 일한 것입니까? 이것을 뒤에 놓거나 그러한 상황에 처한 사람이 새로운 업무를 찾아야합니까? 솔직한 의견 부탁드립니다 ...

감사합니다.

한 번, 재산 500의 부사장은 나쁜 사업 결정으로 회사에 백만 달러를 지불했습니다. 그가 CEO에게 사임했을 때, "그녀의 교육에 백만 달러를 투자했는데 지금 떠나려고합니까? 나는 받아들이지 않습니다."라고 대답했습니다.

나는 신인이거나 무능하다고 가정하는 사람에 대해 실수를 저지르는 관리자와 다른 노동자들에 질리게됩니다. 좋은 디자이너가 될 수있는 방법은 한 가지뿐입니다. 나는 직원들이 실수를하더라도 상관없고, 여러 번 같은 일을하는지 걱정합니다. 문제는 당신이 얼마나 겸손하고 가르치는가? 누군가 당신에게 당신의 실수를 제시 할 때, 당신은 먼저 자신을 방어합니까, 아니면들을 수 있습니까? 당신이 그의 자존심을 삼켜 서 배울 수있는 희귀 한 사람 중 하나라면, 당신은 계속 가치가 있습니다. 한 번 실수로 존경을 잃은 사람은 당신의 존경을받을만한 사람이 아닙니다.

개인적으로 내가 처음 두 번 디자인 한 프로젝트를 두 번 다시 작성해야했지만 그 사실을 알고 있습니까? 나는 많은 것을 배웠고, 그 당시 고용주들은 혼란 스러웠지만 그것은 실수로부터 배우고 자함으로써 시간이 지남에 따라 얻는 효율성에 의해 빠르게 상쇄되었습니다.

굴욕 측면과 회복 방법에 관해서는 두 가지 조언이 있습니다. 첫째, 사람들은 시간이 지남에 따라 잊어 버립니다. 또한 다른 누군가가 그들에게 주목을 받으면 그들도 망할 것입니다. 그러면 모든 것이 다시 평등해질 것입니다. 둘째, 다른 사람들이 정직하고, 배우고, 실수 할 때 멍청하게 굴지 마십시오. 실제로, 그들은 엉덩이에 확고한 발 차기를 필요로하지 않는 한 그들을 격려해야합니다. 정직한 실수를했을 때의 느낌을 기억함으로써 시간이 지남에 따라 팀의 문화를 바꿀 수 있습니다. 결국 사람들이 더 나은 프로그래머, 디자이너 및 인간이되도록 영감을 줄 것입니다.

나는 이것을 오랫동안 (15 년 이상) 해 왔으며 여전히 처음에는 제대로하지 못합니다. 최상의 디자인은 반복적 인 공동 작업 프로세스에서 비롯됩니다. 한동안 디자인 작업을했을 때, 그것이 디자인이 할 수있는 유일한 방법이라는 생각에 갇히기 쉽습니다. 새로운 관점은 당신이 놓친 것들을 보는 데 도움이됩니다.

이것이 작동하려면 팀이 서로를 신뢰해야합니다. 사람들에게 결함이있을 수있는 디자인을 보여주고 디자인에 대한 비판을 받아 들일 수 있어야하는 것을 두려워 할 수는 없습니다. 결과적으로 팀의 나머지 부분은 디자인의 결함이 디자이너에게 반영되지 않음을 이해해야합니다. 디자인의 예상 부분입니다. 또한 팀원들이 자신의 실수와 다른 사람들의 실수로부터 배우고 더 잘하는 방법입니다.

이와 같이 작동하지 않는 기능 장애 팀에있는 경우 두 가지 옵션이 있습니다.

1. 팀을 고치려고 노력하다
2. 새로운 팀을 찾습니다 (내부 또는 새로운 직원).

내가 아는 한, 나는 항상 근본적으로 방어 적 이었습니다. 그것은 기본적으로 올바른 것과는 다릅니다 . 'x'를 결정해야하는 시간과 'x'가 뒤늦은 결정 으로 잘못 결정된 것이 분명 해지는 시간 사이의 상황이 종종 바뀝니다 .

그것은 미국 소득세를 준비하는 것과 같습니다. 많은 사람들이 답이 있어야한다고 생각합니다. 없습니다. 당신은 당신의 의견이 있습니다; 세무사에게 그녀의 의견이 있습니다. 국세청은 의견을 가지고 있습니다.

내가 실수를해도 다른 사람의 존경을 잃지 않습니다. (내가 아는 한) 나는 부분적으로 항상 내 실수를 인정하기 때문이라고 생각합니다. (실제로, 나는 종종 내 자신의 실수를 발견합니다 .) 또한, 거의 모든 중요한 디자인 결정에는 둘 이상의 사람이 서명을합니다. 이러한 결정에있어 실수는 전적으로 한 사람이 아니라 그룹이 소유합니다.

실수를 인정하는 한, 나는 당신이 역량과 경험을 얻는 것이 쉬워 진다고 생각합니다. 내 경험에 비추어 볼 때, 새로운 디자인과 개발은 실수를 할 가능성이 적습니다.

그것은 계속해서 일어나고, 당신의 경력을 방해해서는 안됩니다. 중대한 책임을 맡고있는 사람은 항상 올바른 결정을 내리지 않습니다. 사실, 중대한 책임을 맡고있는 사람은 언제나 결정을 내릴 수 없습니다.

그러나 대부분의 경우 불완전한 정보를 바탕으로 방어적인 결정을 내릴 수 있어야합니다. 딸이 말했듯이 "그저 사람 일 뿐이야."

모든 사람은 때때로 잘못을받습니다. 실수는 불가피하다. 잘못했을 때 자유롭게 인정하고 실수를 통해 배우고 특히 처음에 자신이 실제로 틀렸다는 것을 확신하지 못한 경우 겸손을 나타내십시오.

"가습"은 절대 일어나지 않아야합니다. 개인의 성과를 전혀 향상 시키지는 않습니다.

우리 회사는 여전히 어려운 결정에 목을 내밀고 싶지만, 틀 렸음을 인정하고 필요할 때 자신의 행동을 조정할 수있는 사람들을 존중하는 문화를 개발했습니다.

제안한 소프트웨어 디자인에서 항상 기본적으로 정확 했습니까?

그래, 난 초인간적이야! 물론 아닙니다.

근본적으로 잘못된 디자인을 제공하면 동료 팀원의 존중을 잃는 경향이 있습니다.

아니! 그렇게되면 팀 정신에 문제가있는 것입니다.

모두 실수합니다. 어떤 해결책은 좋고 나쁜 것으로 밝혀졌습니다. 성공과 실패는 모두 당신과 팀의 다른 사람들이 교훈으로 삼아야합니다.

첫 번째 실수는 기분이 좋지 않을 수 있지만 수백 개의 실수를 한 후에는 일의 일부와 같습니다.

모든 사람에게 발생합니다. 가장 중요한 것은 실수로부터 배우고 다시는 일어나지 않도록 노력하는 것입니다. 또한 본인이 실수했음을 인정해야합니다. 예를 들어, 열등한 데이터 액세스 계층 (SubSonic3)을 사용하는 실수를 저지른 적이 있습니다. 결정을 내릴 때 수작업으로 작성된 SQL 쿼리에서 벗어나고 싶었습니다. 그래서 나는 처음에 가장 쉬운 것 중 하나처럼 보이는 것을 선택했습니다. DAL에 대해서도 경험이 많지 않았습니다. 글쎄, 몇 가지 문제를 해결 한 후 왜 일부 쿼리가 너무 오래 걸리고 SubSonic이 아무런 이유없이 전체 테이블을 가져 오는 것을 알았습니다.

그래서 나는 상사에게 실수를했다고 설명하고 그 문제를 해결할 계획을 주었다. 물론 사장님은 며칠간의 순수한 이주가 필요한 다소 큰 실수를 저지르는 것에 대해 열성적이지 않았습니다. 그러나 그는 또 같은 실수를 다시하지 않도록했다. 그는 내가 마이그레이션을 제안한 다음 데이터 액세스 계층에 대한 개념 증명 프로젝트를 만들었으며 요구 사항에 맞게 작동하고 전체 테이블을 풀지 않았는지 확인했습니다. 결국, 그것은 나에게 좋은 학습 경험이었고 이제는 프로젝트의 핵심 부분이 요구 사항을 충족하고 큰 문제가 없는지 확인해야합니다.

그래서 기본적으로 당신이하는 일은 이것입니다 :

1. 실수했음을 인정
2. 그것을 고칠 계획을 세우십시오
3. 계획이 실제로 작동하는지 확인하십시오
4. 다시 확인하십시오.
5. 고쳐!

문제를 해결하는 방법을 잘 모를 경우 다른 팀 구성원이 참여하는 것을 두려워하지 마십시오.

마지막으로 긴장을 푸십시오! 누구나 실수를합니다. 처음으로 완벽하게하는 사람은 거의 없습니다.

이것은 괴짜 오줌 싸기 대회 물건이며, 좋은 상황은 아닙니다. 항상 옳은 사람은 없으며 누군가가 더 나은 방법을 찾거나 문제가있는 경우 부끄러워 할 것이 없습니다. 당신이 한 방법.

정서적으로 자신 의 솔루션 에서 자신을 버리고 최상의 솔루션 을 찾기 위해 시간을 보내야하며 , 다른 사람이 문제를 해결하더라도 문제가 해결되면 기뻐할 수 있습니다.

당신이 당신의 질문에 말하지 않은 것이 많이 있습니다. "디자인 제공"에 대한 설정이 무엇인지 알 수 없습니다. 계획된 접근 방식에 대해 동료와의 초기 토론입니까, 아니면 최종 코드가 무엇인지 희망하는 것입니까?

전자의 경우, 기분이 나빠질 이유가 없으며 동료가 미래에 당신을 의심 할 이유가 없습니다.

다른 사람과 디자인을 논의하기 위해 최종 배송까지 기다린다면 다른 작업에 대해 의심을 품지 않습니다.

모든 사람 은 자신의 디자인을 다른 사람과 논의해야합니다. 복잡성 또는 중요도에 따라 여러 사람과 여러 번 논의해야 할 수도 있습니다. 누구나 실수를하거나 요구 사항을 오해하거나 특별한 경우를 놓칠 수 있습니다.

조기에 발견 된 실수는 해결하기 쉽고 저렴합니다. 같은 실수를 반복해서 반복하지 않는 한 그들은 매우 용서해야합니다. 동료 검토를 통해 실수를 조기에 쉽게 잡을 수 있습니다.

팀 환경에서 고독한 코더가 되려고 노력하는 경우, 다른 사람의 도움이 필요 없을 정도로 완벽하다고 생각하는 (거의 용서할 수없는) 죄를 저지르고 있습니다. 그것이 팀 환경이라는 사실은 아무도 아무도 그것을 이해하지 못할 정도로 문제가 크다는 것을 증명합니다. 사람들은 서로 대화를해야합니다. 그렇지 않으면 실수로 인해 어글 머리가 풀리기 (또는 릴리즈 후)에 너무 가까워집니다.

나는 항상 좋은 결정과 나쁜 결정을 구분했다. 그리고 다른 정확하고 잘못된 결정에. 올바른 결정은 동일한 상황에서 동일한 정보를 사용하여 동일한 방식으로 결정하는 것입니다. 나쁜 결정은 당신이 다르게 만들 것입니다. 올바른 결정은 후시와 추가 정보의 이점으로 올바른 것으로 판명됩니다. 반대로 잘못된 결정으로.

부정확 한 결정을 내리지 않는 사람은 아무것도하지 않는 경우가 종종 있습니다. 잘못된 결정은 배우는 방식입니다. 의사 결정자가 스스로 결정에 투자하고 결정을 소급 적으로 정당화하려고하거나 결국 결정이 좋은 것으로 판명되기 때문에 잘못된 결정은 종종 악화됩니다.

내가 만든 대부분의 디자인 결정은 올바른 것으로 판명되었지만 잘못된 결정을 통해 가장 많이 배우고 더 발전했습니다. 나는 내 결정 중 일부가 잘못된 결정 이었음을 희망하지만, 나쁜 결정에 대한 문제의 일부는 결정이 잘못되었음을 인식하고 그로부터 발생하는 흔하지 않은 교훈을 받아들이는 것입니다.

그들이 " 월요일 아침 쿼터백 "이 아닌 한 . 나는 모든 디자인 토론을 통해 앉아있는 사람이 사실 이후에는 효과가 없다고 주장한다고 말하지 않고 아무 소용이 없습니다. 건설적인 상황에 놓여 있지 않더라도 비판을받을 수 있어야합니다.

아마도 SO 사이트의 가장 큰 특징 중 하나는 위험을 감수하고 솔루션을 제안하고 불확실한 것입니다. 이것이 당신이 배우는 방법입니다. 당신의 머릿속에 헛소리가 가득한 삶을 살아가는 것은 잘못된 일입니다.

그들은 당신이 모르는 것을 알지 만 모든 것을 알지는 못할 것입니다. 그것을 극복하고, 일하고, 무언가를 해보십시오. 그들이 너무 똑똑하다고 생각하는 시간을 낭비하게하십시오.

항상 좋은 디자인을 제공 했습니까 ? 아니! 나는 그것을하기 위해 노력하고, 더 나아지려고 노력하지만, 각각의 연속적인 프로젝트에서, 내가 항상 할 수있는 것처럼 보이는 것은 이전에 한 일을 되돌아보고 어떤 식 으로든 마크를 놓친 방법에 대해 울부 짖는 것입니다.

별보다 덜한 디자인을 제안한 사람은 그 사람이 실수로부터 배우고 자하며 비판에 개방되어 있음을 보여 주면 그 사람을 반대하지 않을 것입니다. 그 사람이 비슷하게 발전하기 위해 노력하고 있고 적성을 가지고 있다는 증거를 보면, 잘못된 설계 제안은 단지 학습 기회 일뿐입니다.

이제는 모든 사람에게 일어나므로 디자인이 왜 잘못되었는지 알아 내고 그로부터 배우는 것이 가장 좋습니다 . 지식이 부족하면 디자인 실패로 인해 다음에 사용할 수있는 새로운 지식이 생길 것입니다. 당신을 낙담시키지 마십시오. 모두가 어느 시점 에서이 과정을 거칩니다. 경험을 쌓고 새로운 팀 / 환경을 파악하는 가장 좋은 방법입니다.

이것은 종종 일어날 것입니다. 우리 산업은 매우 빠르게 변화하고 있으며, 결코 틀리지 않을 가능성은 사실상 제로입니다.

그러나 나쁜 디자인을 그들의 반대에 대한 그들의 견해를 낮추었습니까? 그것이 그들이 과잉 반응하는 이유 일 수 있습니다.

실수가 거대했다면, 다시 존경을 얻는 데 시간이 걸릴 것입니다. 동료 중 한 사람이 당신을 나쁜 방향으로 데려 와서 전체 팀에 문제를 일으킨다면, 가까운 시일 내에 더 자신을 증명하기 위해 그를 필요로하지 않겠습니까?

당신이 할 수있는 일은 당신이 틀렸다는 것을 인정하고, 옳은 사람에게 신용을주고, 미래에 더 잘 듣고 연구 옵션을 개선하기 위해 노력합니다.

디자인이 잘못되었다고 생각하지 않은 것은 무엇입니까? (임의의 예는 아님-일부 가져 오기에는 수백만 개의 레코드가 있으며 며칠이 걸릴 것이라는 점을 인식하지 않고 행 단위로 코드를 재사용하고 (한 위치에서 비즈니스 규칙 만 변경해야하는) 기존 웹 서비스를 사용하도록 가져 오기 프로세스를 설계하십시오. 그것으로부터 배우고 미래에 그런 것들을 고려하십시오.

항상 실수 가있을 것 입니다. 실수는 프로그래머가되는 것입니다. 인터넷의 다른 사람, 특히 동료로부터 계속 배우십시오. 여기서 유일하게 부끄러운 점은 여기서 포기하거나 이와 같은 문제가 발생할 때 머리를 모래에 묻는 것입니다.

그것을 뒤로하고 머리를 숙이고 최선을 다하십시오. 훌륭한 프로그래머라면 실수를 통해 빛을 발할 것입니다.

자신의 아이디어가 탄탄한 토대 위에 놓여 있는지 확실하지 않은 경우, 아이디어를 회사 전체 또는 부서에 제안하기 전에 신뢰할 수있는 동료 몇 명과 논의해야합니다. 사실, 확실하더라도, 당신은 여전히 ​​당신과 함께 일하고 사람들을 가장 잘 아는 사람들과 토론해야합니다. 문제를 조기에 발견하는 데 도움이됩니다.

그것은 때때로 우리 모두에게 일어난다. 첫 번째 디자인을 프로토 타입으로 사용하십시오. 정확히 무엇이 효과가 있었으며 왜 효과가 없었으며 왜 그런지 알아보십시오. 그러면 훨씬 더 나은 최종 제품을 작성할 수 있습니다.

자신을 정당화하려고하거나 방어 적으로 행동하지 마십시오. 실수를 인정하고 계속 진행하십시오.

근본적인 문제는 설명되지 않는 것 같습니다. 이것은 사회적 문제입니다. 거의 모든 직업에서 그러한 행동을 볼 수 있습니다. 실수를 저지르고 특정 물건에서 당신을 "분류"하는 것은 영원한 것입니다. 사회적 행동입니다. 영리하고 똑똑한 사람들조차 모두를 따르는 경향이 있습니다.

프로그래밍과는 아무런 관련이없는 예를 하나 들어 보도록하겠습니다. 이전 직장에서는 설거지를 한두 번 씻는 것을 잊었습니다. 그 이후로 모든 노동자들은 내가 설거지를하지 않는 사람이라고 생각했습니다. 그리고 이제 싱크대에 더러운 것이 있으면 바로 나입니다.

그것은 모든 곳에서 동일합니다. 이것은 어떤 종류의 문제가 있더라도 사회적 행동입니다.

솔직한 피드백을 원한다고 말씀하십니까? 유일한 해결책은 다른 일을 끝내는 것입니다. 팀의 모든 사람들이 당신이 당신의 일을 잘하지 못한다고 생각하면 곧 변하지 않을 것입니다. 이렇게 말해서 죄송합니다. 따라서 다른 종류의 직업을 찾으십시오. 왜냐하면 이런 종류의 (어리석은 고백해야합니다) 사회적 행동을 절대로 바꾸지 않기 때문 입니다.

핵심은 사례를 어떻게 진술하고 어떤 종류의 변경을 수행 하는가입니다. Jon Skeet보다 더 훌륭하고 더 훌륭한 프로그래밍 전문가라고 주장한다면 어느 시점에서 당신은 그것에 대해 무너질 가능성이 큽니다. 핵심은 솔루션을 제시하여 확인하지 않아야 할 완벽한 솔루션이 아니라 문제에 대한 합리적인 솔루션임을 보여줄 수있는 방법입니다.

가장 좋은 예는 static내가 한 번 일한 웹 응용 프로그램에서 수업을하는 데 따른 부작용을 발견하는 것 입니다. 하나의 인스턴스가 응용 프로그램의 모든 사용자에게 유지되고 공유되는 것이 얼마나 나쁜지 알지 못했지만 그로부터 배웠고 시간 내에 복구되었습니다. 때로는 무언가가 발견되고 중대한 수정이 이루어져야 할 수도 있습니다. 나는 그 캠프에 있었기 때문에 한 번 일했을 때 메모리 문제를 일으키는 문자열 연결을 줄이기 위해 많은 VBScript를 살펴 봐야했습니다. 1998 년에 애플리케이션에 해당 필드에 ~ 20 개의 선택적 필드가 있으므로 동적으로 SQL을 생성해야하는 고객 코드를 찾기 위해 1998 년에 SQL 주입에 취약한 코드를 작성하는 것을 기억할 수 있습니다.

완벽주의는 여기서 양날의 칼이 될 수 있습니다. 이것은 제가 그 세 번째 의견을 보는 방법이며, 때때로 제가하는 방식이기도합니다. 나쁜 점은 이러한 모든 실수가 있다는 것입니다. 좋은 점은 최선을 다할 때 다른 사람들의 기대를 뛰어 넘지 않으면 만날 수 있다는 것입니다. 지속적인 개선은 완벽주의를 보는 PC 방법 일 수 있습니다. 그리고 적당히 유지한다면, 나는 이것을 좋은 것으로 간주합니다. 모든 실수에 대해 코드가 프로덕션에 들어가나요? 작업이 완료됩니까? 누군가가 항상 무언가를 고치고 있거나 너무 심하게되고 싶어서 완벽하게 될 때까지 다른 일을하지 않으려는 것이 좋을뿐만 아니라 숙고 할 요점입니까? 연습은 작업을 더 잘 수행 할 패턴을 찾는 데 도움이 될 수 있습니다. 하나,