기사에도 많이 나온 글인데 원문을 찾아 읽었다. 원문 기사를 연결한다. What I’ve Learned in 45 Years in the Software Industry
BTI360 팀 동료 인 Joel Goldberg는 최근 40년 이상 소프트웨어 업계에서 일한 후 은퇴했습니다. 그가 떠날 때 그는 오랜 경력을 통해 배운 교훈을 공유했습니다. 그의 허락하에 그의 지혜를 여기서 나눕니다.
소프트웨어 산업에서 40년을 돌이켜 보면, 얼마나 많이 변했는지 놀랐습니다. 저는 펀치 카드로 경력을 시작했고 클라우드 컴퓨팅 시대로 끝을 맺고 있습니다. 이러한 모든 변화에도 불구하고 제 경력 전반에 걸쳐 저를 도왔던 많은 원칙은 변하지 않았으며 계속해서 관련성이 있습니다. 키보드에서 물러나면서 소프트웨어 엔지니어로서의 경력에서 배운 여섯 가지 아이디어를 공유하고 싶습니다.
1. 지식의 저주를 조심하십시오.
당신이 뭔가를 알게 되면, 그러한 일을 알기 전에 어땠는지를 상상하는 일은 불가능합니다. 이것은 지식의 저주(the Curse of Knowledge)이며 수많은 오해와 비효율성의 근원입니다. 복잡성에 익숙한 똑똑한 사람들은 특히 복잡성을 자랑스러워 합니다.
지식의 저주를 경계하지 않으면 코드를 포함하여 모든 형태의 커뮤니케이션에 당황할 가능성이 있습니다. 작업이 전문화될수록 초보자가 이해할 수 없는 방식으로 의사소통할 위험이 커집니다. 지식의 저주와 싸우십시오. 청중을 이해하기 위해 노력하십시오. 처음으로 소통하는 내용을 배우는 것이 어떤 것인지 상상해보십시오.
2. 기본에 집중
기술은 끊임없이 변화하지만 소프트웨어 개발에 대한 몇 가지 기본적인 접근 방식은 이러한 추세를 초월합니다. 다음은 오랫동안 관련될 6 가지 기본 사항입니다.
- 팀워크 — 훌륭한 팀은 훌륭한 소프트웨어를 구축합니다. 팀워크를 당연시하지 마십시오.
- 신뢰 — 팀은 신뢰의 속도로 움직입니다. 함께 일하고 싶은 신뢰할 수 있는 사람이 되십시오.
- 의사소통 — 정직하고 적극적으로 의사소통합니다. 지식의 저주를 피하십시오.
- 합의 추구 — 전체 팀이 함께 할 시간을 가지십시오. 토론과 불일치가 최상의 설루션을 제공하도록 하십시오.
- 자동화된 테스트 — 잘 테스트된 코드를 사용하면 팀이 자신 있게 빠르게 이동할 수 있습니다.
- 깔끔하고 이해하기 쉬우며 탐색 가능한 코드 및 디자인 — 코드를 인수할 다음 엔지니어를 고객으로 생각하십시오. 후임자가 읽기, 유지 관리 및 업데이트하는 데 문제가 없는 코드를 빌드하십시오.
3. 단순성
복잡성과의 싸움은 끝이없는 원인입니다. 설루션은 가능한 한 간단해야 합니다. 코드를 관리할 다음 사람이 당신만큼 똑똑하지 않다고 가정하십시오. 더 적은 수의 기술을 사용할 수 있으면 그렇게 하십시오.
"디자이너는 추가할 것이 없을 때가 아니라 제거할 것이 없을 때 완벽 함을 달성했다는 것을 알고 있습니다."
앙투안 드 생 텍쥐페리
4. 먼저 이해하기
스티븐 코비의 7 가지 습관 중 하나는 "먼저 이해하기 위해 찾은 다음 이해하기"입니다. 이 격언은 다른 어떤 조언보다 좋은 경청자이자 팀 동료가 되도록 도와주었습니다. 다른 사람들에게 영향을 미치고 효과적으로 협력하고 싶다면 먼저 그들을 이해해야 합니다. 자신의 생각을 알리기 전에 적극적으로 그들의 감정, 생각 및 관점을 이해하도록 경청하십시오.
5. Lock-In주의*
소프트웨어 구축 방식에 혁명을 일으킬 차세대 생산성 제품이 항상 있을 것입니다. CASE (Computer Assisted Software Engineering) 도구, COTS, Peoplesoft 및 SAP와 같은 Enterprise Resource Planning 제품, 예, 심지어 Ruby. 전체 론적 개발 철학을 채택하면 비용과 시간이 크게 절감된다고 주장합니다. 항상 분명하지는 않은 것은 상당한 선행 비용이나 자신이 부담할 수 있는 제약입니다. 락인은 주로 공급 업체에서 발생했지만 이제는 프레임 워크에서도 발생할 수 있습니다. 어느 쪽이든, 고정은 변경에 상당한 비용을 의미합니다. 현명하게 선택해. 새로운 것이 항상 좋은 것은 아닙니다!
*lock-in 효과란 이미 존재하는 재화나 서비스보다 더 뛰어난 서비스가 나와도 이미 투자된 기회 비용으로 새로운 서비스로 옮기지 못하는 현상.
6. 정직하고 역할에 맞지 않을 때 인정
경력의 어느 시점에서 자신에게 적합하지 않은 역할을 맡게 될 수 있습니다. 잘못된 역할은 캐릭터 결함이 아니지만 무시해서는 안 되는 문제입니다. 이러한 딜레마에 대한 해결책은 둘 이상 있을 수 있습니다. 당신이 진화하거나, 역할이 진화할 수 있습니다. 열쇠는 무슨 일이 일어나고 있는지 인식하고 건강에 해로운 곳에서 벗어나기 위해 자기 지식을 갖는 것입니다. 불행한 것은 누구에게도 최선의 이익이 되지 않으며 BTI360은 이를 인식합니다.
제가 GM에 있었을 때, 다음 단계가 아니었다면 실패했습니다. 더 많은 사람을 관리하거나 더 크고 복잡한 프로젝트를 수행하는 것입니다. 많은 사람들에게 이것은 비참한 경력 경로를 만들었습니다 ( Peter Principle 참조 ). EDS에서 문화는 이와 같지 않았습니다. 사람들은 관리 역할에 들어갔다 나갔다. 전략적 플래너와 같이 범위가 더 큰 역할에서 PM 또는 프로젝트 수준 개발자와 같이 범위가 더 좁은 역할로 이동하는 것과 관련된 오명은 없었습니다. 저는 이러한 유연성을 활용하여 기술 피라미드의 최상위 역할에서 프로젝트 수준의 개발자로 다시 이동 한 사람 중 한 명이었습니다. 나는 결코 뒤돌아 보지 않았다.
마지막 생각들
BTI360에 입사하기 전에도 위에서 설명한 원칙을 소중히 여기는 곳이라는 것을 알 정도로 문화에 대해 충분히 알고 있었습니다. 저는 여러분 각자가 BTI360을 소프트웨어 구축을 위한 훌륭한 장소로 계속 만들 수 있는 강력한 엔지니어링 문화를 유지하는 소유권을 가지기를 바랍니다.
'개발자' 카테고리의 다른 글
A Guide to Debouncing 버튼 바운스 해결 가이드 (0) | 2021.05.28 |
---|---|
점성 액체 정량공급기 배선 도면 (0) | 2021.05.18 |
어드벤처 디자인 교과 운영 Guide (0) | 2021.02.23 |
Joel Goldberg의 교훈에 이은 인터뷰 (0) | 2021.01.25 |
Care 04-101 Cyber Physical Systems 강의 계획 (2) | 2021.01.06 |
스마트 팩토리(Smart Factory) 센서 데이터 수집 전송 장치 (0) | 2020.09.10 |
도시농업 전문가 양성과정 (0) | 2020.07.30 |
배리어프리 앱 개발 콘테스트 지원 (0) | 2020.07.02 |
더욱 좋은 정보를 제공하겠습니다.~ ^^