질문을 던져놓고 구글 검색을 해보니 몇 가지 글이 보이는군요. 10x engineers 라는 키워드도 있네요.
https://linkedin.com/pulse/great-engineer-vs-good-marissa-fayer-mba/
- 좋은 개발자는 문제를 해결하는 특별한 도구들을 갖추고 있다. 좋은 개발자는 체계적이고 합리적이며, 모든 각도에서 바라보고, 모든 가능한 입출력을 분석한다.
- 탁월한 개발자는 위에 언급한 모든 능력을 기반으로, 이를 즉시 사용 가능한 해결책에 적용한다. 이미 알려진 패턴들(과학과 수학의 원리들, 린 개발 원칙 등)을 창의적인 방법으로 새로운 실생활의 문제에 적용한다.
- 가장 탁월한 개발자들은 귀를 기울일 줄 줄 안다. 문제에 귀를 기울이고, 이해관계자와 그들이 가치를 두는것에 귀를 기울이고, 시장에 귀를 기울이고, 피드백에 귀를 기울인다. 그리고 창의적인 방법을 떠올리는 내면의 소리에 귀를 기울인다.
1. (컨베이어 벨트에 선풍기 가져온 사람 예를 들면서) 게으른 사람은 언제나 일하지 않을 방법을 찾는다. 게으른 엔지니어가 최고의 엔지니어다.
2. 좋은 엔지니어는 요청받은 문제를 푼다. 가끔씩 본인의 기술 역량을 향상시키기 위한 수업을 듣는다. 탁월한 엔지니어는 요청받은 것에서 한발 더 나아간다.
- 사람들이 질문이 있으면 그를 찾는다.
- 끊임없이 학습한다.
- 아는 걸 지속적으로 공유한다.
- 옳다고 생각하는 것을 고수하지만, 언제 포기해야 할지도 알고 있다.
- 손을 더럽히는 걸 두려워하지 않는다.
3. 나쁜 엔지니어는 시스템에 버그가 있을 때 왜 고치기 어려운지 변명한다. 좋은 엔지니어는 본인의 전문성에 기반하여 버그를 고친다. 탁월한 엔지니어는 주어진 문제 뒤에 숨겨진 의미를 찾는다.
- 모든 다른 시스템에는 유사한 버그가 없는지(또는 이미 고쳐졌는지) 체크한다.
- 유사한 버그가 또 일어나는 걸 피할 수 있는 장기적 해결책이나 설계를 제안한다. (각 해결책 사이의 cost/benefit analysis 첨부)
- 본인의 전문 영역 밖으로도 눈을 돌려, 다른 그룹에서 유사한 문제를 겪진 않았는지 찾아본다. (또는 이미 컨택해 봤다)
질문을 던져놓고 구글 검색을 해보니 몇 가지 글이 보이는군요. 10x engineers 라는 키워드도 있네요.
https://linkedin.com/pulse/great-engineer-vs-good-marissa-fayer-mba/
- 좋은 개발자는 문제를 해결하는 특별한 도구들을 갖추고 있다. 좋은 개발자는 체계적이고 합리적이며, 모든 각도에서 바라보고, 모든 가능한 입출력을 분석한다.
- 탁월한 개발자는 위에 언급한 모든 능력을 기반으로, 이를 즉시 사용 가능한 해결책에 적용한다. 이미 알려진 패턴들(과학과 수학의 원리들, 린 개발 원칙 등)을 창의적인 방법으로 새로운 실생활의 문제에 적용한다.
- 가장 탁월한 개발자들은 귀를 기울일 줄 줄 안다. 문제에 귀를 기울이고, 이해관계자와 그들이 가치를 두는것에 귀를 기울이고, 시장에 귀를 기울이고, 피드백에 귀를 기울인다. 그리고 창의적인 방법을 떠올리는 내면의 소리에 귀를 기울인다.
==
https://www.quora.com/How-do-you-identify-a-good-vs-great-engineer
답변이 엄청 많은데.. vote 높은 거 몇 개만 보면
1. (컨베이어 벨트에 선풍기 가져온 사람 예를 들면서) 게으른 사람은 언제나 일하지 않을 방법을 찾는다. 게으른 엔지니어가 최고의 엔지니어다.
2. 좋은 엔지니어는 요청받은 문제를 푼다. 가끔씩 본인의 기술 역량을 향상시키기 위한 수업을 듣는다. 탁월한 엔지니어는 요청받은 것에서 한발 더 나아간다.
- 사람들이 질문이 있으면 그를 찾는다.
- 끊임없이 학습한다.
- 아는 걸 지속적으로 공유한다.
- 옳다고 생각하는 것을 고수하지만, 언제 포기해야 할지도 알고 있다.
- 손을 더럽히는 걸 두려워하지 않는다.
3. 나쁜 엔지니어는 시스템에 버그가 있을 때 왜 고치기 어려운지 변명한다. 좋은 엔지니어는 본인의 전문성에 기반하여 버그를 고친다. 탁월한 엔지니어는 주어진 문제 뒤에 숨겨진 의미를 찾는다.
- 모든 다른 시스템에는 유사한 버그가 없는지(또는 이미 고쳐졌는지) 체크한다.
- 유사한 버그가 또 일어나는 걸 피할 수 있는 장기적 해결책이나 설계를 제안한다. (각 해결책 사이의 cost/benefit analysis 첨부)
- 본인의 전문 영역 밖으로도 눈을 돌려, 다른 그룹에서 유사한 문제를 겪진 않았는지 찾아본다. (또는 이미 컨택해 봤다)