어떤 도구나 기술, 프로세스보다도 중요하다.
아래의 내용은 제가 개인적으로 느끼는 부분과 개발자들이 나아가야할 방향에 대해서 크게 공감한 글을 발견하였고, 이것에 대해 많은 사람들이 읽었으면 하는 바람에서 번역해 보았습니다.
본 포스팅은 Elye의 10 Positive Software Developer Cultures That I Embrace를 번역하여 작성하였습니다.
(원어 부제: It’s mode important than any tool, technology, or process)
“프로그래머는 너드(nerd, 머리는 좋으나 세상물정을 모르는 사람)다. 그들은 사람보다 컴퓨터로 하는 일을 더 잘한다.” 그것이 내가 성장한 뒤 느낀점이었다. 나는 내성적이고 프로그래밍을 좋아하기 때문에 프로그래밍 능력만 있으면, 다른 사람들과 함께 일하는 방법에 대해서는 당장 걱정해야할 부분이 아니라고 생각했다.
수년에 걸쳐 내가 나이를 먹고 20년이 넘는 기간동안 다양한 프로그래머와 사무실 사람들과 함께 일하면서 알게된 사실이 있는데, 매일 출근하는 나의 행복은 내가 어떤 기술적인 프로젝트에 참여하게 되는지, 프로세스가 얼마나 원활한 상태를 가지고 있는지에 대한것은 아니었다는 점이다. 대신 직장에서의 행복은 함께 일하는 사람들과 내가 속한 직장 문화에 의해 결정된다.
출근하러 가서, 우리가 참아야 할 정치적인 것들이 있다는 점을 안다면, 우리의 하루를 망칠 수 있다. 그리고 우리가 매일 그런것들 상대하고 있다면 더 나빠질 것이다.
따라서 긍정적인 개발자 근무 문화를 구축하는 것은 매우 중요하다. 아래는 나의 경험상 그렇게 될 수 있도록 하는 10가지 방법이다.
1. 경쟁보다 동지애를 선호하라
처음 직장에 들어갔을 때, 결국 모든 사람이 승진하지는 않는다는 사실을 잘 이해하고 있다. 나에게 있어서는 가장 헌신적이고 열심히 일하며, 생산적인 개발자만이 경력의 사다리를 더 빨리 오를 수 있는 기회를 갖게 될 것이다.
당연히 나는 내 모든 동료, 특히 나와 같은 위치에 있는 사람들을 경쟁자로 대한다. 더 열심히, 더 오래 일하고 더 많이 생산한다. 출근하는 것은 전장에 들어가는 것과 같다. 예를 들어, 다른 사람보다 더 잘할 수 있는 방법, 상사 앞에서 내 작업을 더 잘 보이게 하는 방법 등에 대한 끊임없는 전략을 구사하는 것처럼 말이다.
수년에 걸쳐, 나는 내가 원하는 것을 얻었다. 즉, 승진하였고, 또 승진하였다. 각 레벨에서의 경쟁은 더욱 치열해진다. 출근은 너무 스트레스로 다가왔다. 나는 이 때 일을 하게 된 동기에 대해 질문하기 시작하였다. 나는 공통의 목표를 향해 일하는 진정한 친구가 없다.
돌이켜보면 나는 진정한 우정을 쌓는 데 많은 기회를 놓치고 있었다. 동료애 없이 출근하는 것은 무의미하다. 우리는 회사의 CEO가 될 수 있지만, 그 자리는 너무 외로울 것이다.
나는 처음부터 다시 시작하고, 실수로부터 배운 경력을 리셋할 수 있는 기회를 갖게 된 것은 행운이라고 생각한다. 경력을 쌓는데 집중하기 보다는 다른 사람과 함께 일하고 함께 배우고 함께 성장하는 모든 순간을 즐긴다.
그들 중 일부는 비록 어리지만 지금보다 훨씬 더 높은 경력을 가지고 있다. 나는 그들을 진심으로 축하한다. 나보다 더 잘하는 친구가 있다는 것은 기쁜 일이다. 또한 우리는 승진할 기회가 올 때 그들의 경험에서 배울 수도 있다.
오래된 속담 중 “적보다 친구가 낫다"는 말이 옳다고 생각한다. 동료를 적이 아닌 친구로 만들고, 경쟁보다 동료애를 구축하는데 노력하라.
적보다 친구가 낫다 - 중국 속담
2. 사무실의 시간은 “일하기"만을 위한 시간은 아니다
어렸을 때, 학교에 가는 것은 배우는 것이지 노는 것이 아니라는 인상을 받았다. 선생님이 주위에 있을 때, 아무 말도 하지 않았다. 주의 깊게 듣고 학습에 집중하였다.
나는 이 사고방식을 직장으로 가져왔다. 일할 땐 일 이야기만 하는 줄 알았다. 근무 시간에 업무에 대한 일이 아닌 것을 이야기 하는 것은 “근무 윤리의 위반"이라고 말이다. 업무와 관련되지 않은 사항에 대해 이야기 할 수 있는 유일한 시간은 휴식 시간과 근무시간 이후 뿐이었다.
몇 년 동안 함께 일한 후에도 여전히 동료에 대해 잘 알지 못한다는 것은 놀라운 일이 아니었다. 나는 그들이 어떤 프로젝트를 하고, 어떤 팀에 속해 있는지는 알고 있지만, 개인으로서, 가족으로서, 그들의 취미가 무엇인지에 대해서는 아무것도 몰랐다. 여기에는 나에게 보고해야 하는 사람들도 해당되었다. 그렇게 나는 매니저로서 비참하게 실패하였다.
다른 나라와 산업의 분야로 가서 내가 관리자에서 QA 테스터로 경력을 리셋했을 때, 일하는 문화가 얼마나 다른지 문화적 충격을 많이 받았다.
나는 회사 설립자(일명 CEO라 하는)가 우리와 비교적 가까운 곳에서 일하는 작은 회사에서 일한다. 매일 나의 동료들은 나에게 나의 하루가 어떠냐고 묻고, 그들의 인생과 ‘일’과 관련이 없는 것에 대해 이야기를 할 것이다. 우리가 근무시간에 ‘일’하지 않기 때문에 CEO를 짜증나게 할지 걱정이다.
내가 보기에 이것은 거의 모든 사람이 하고 있으며, 가끔은 CEO도 와서 인생에 대해 좋은 이야기를 나누는 등, 나는 그것이 사실 내가 이런 직장생활이 되어야 한다고 생각했던 것과는 매우 다른 문화라는 것을 깨달았다. 이곳의 사람들은 서로를 인격체로 알고 있으며, 매우 유대감이 좋다.
어떤 사람들은 그러한 회사가 어떻게 생산적일 수 있는지 궁금해 할 수 있다. 내가 일했던 이 회사는 이 지역에서 가장 빠르게 성장하는 회사 중 하나이며, 내가 존경하는 많은 모바일 개발자 전문가들은 이곳에서 기여했다. 진보적이고 생산적이다!
그런 뒤 나는 우리가 서로 더 잘 연결하고, 더 잘 아는 법을 배우면서, 의도치 않게 더 잘 함께 일한다는 사실을 깨달았다. 우리는 더 나은 신뢰관계를 구축하고 서로의 도전과 강점을 이해하며, 이를 통해 공통의 업무 목표를 위해 서로를 더 잘 보완할 수 있다.
“사람들은 당신이 얼마나 관심을 갖고 있는지 알기 전까지는, 당신이 얼마나 알고 있는지 신경쓰지 않습니다.”라는 말은 옳다고 생각한다. 인간으로서 서로에 대해 배우고 신뢰를 구축하라. 이것은 더 나은 업무 문화를 만들 것이다!
사람들은 당신이 얼마나 관심을 갖고 있는지 알기 전까지는, 당신이 얼마나 알고 있는지 신경 쓰지 않습니다. - 시어도어 루즈벨트
3. ‘우리'가 ‘나'보다 낫다
‘독학 프로그래머'는 정규 교육을 마치지 않고, 스스로 연구하고 학습하는 프로그래밍을 하는 사람을 가리키는 용어이다. 그런데 주의하지 않으면, 이 용어를 자주 사용하는 사람은 “나는 독학 프로그래머이고, 아무도 필요없다"는 잘못된 사고방식을 가질 수 있다.
프로그래밍은 혼자서 효과적으로 탐색하고 완전히 발견할 수 있는 분야가 아닙니다. 우리는 개인 멘토가 없을 수도 있고, 정식 과정을 수강하지 않을도 있지만, 그것이 책, 튜토리얼, 블로그, 매뉴얼 또는 스택오버플로우 등 어딘가에서 여전히 읽으면서 배운다는 사실을 바꾸지는 않습니다. 이 모든 것은 누군가에 의해 작성되었습니다. - 출처
다른 사람에 비해 추상적인 개념을 프로그래밍하는 그들의 지적 능력에서 우월한 사고방식이나, 무언가를 프로그래밍하는 그들의 높은 평가를 받는 ‘유일한 옳은 방법'은 시간이 지남에 따라 팀 전체에 독이 될 수 있는 개인주의적 자기 중심 문화를 초래할 수 있다.
초점을 ‘내가’ 얼마나 이 프로젝트에 기여 했으며, ‘나의' 아이디어였고, ‘내가’ 없었다면 불가능 했을 것이라는 것에 맞춘다면 위험하다. 오랜 세월 쌓아온 팀 유대감에 균열이 생기고 결국 제대로 작동하지 않는 팀이 될 수도 있다.
어떤 소프트웨어 프로젝트도 원맨쇼가 아니다. 소프트웨어 자체는 항상 조직 내 또는 외부에서 다른 지원 그룹이 만든 것의 집함인 라이브러리, 프레임워크, 도구 등과 같은 다른 엔터티 위에 구축된다. 우리 모두는 그저 출시 가능한 소프트웨어의 최종 제품을 만드는 데 한 몫을 한 것이다.
그러므로 우리는 모든 성공적인 프로젝트에서 ‘내'가 아니라 ‘우리'임을 끊임없이 상기해야 한다. 나는 아래에 적어놓은 이 재미있는 말장난 같은 인용구를 좋아한다.
“I”와 함께하면 “ILL”(아픔)이 됩니다.
”WE”와 함께하면 “WELL”(잘, 좋게)이 됩니다.
4. 이별이 고마을 때까지 기다리지 마라
추도사는 정말로 그럴 자격이 있는 사람을 제외하고는 그 외의 다른 사람들이 경청할 만한 감사함이다. 이것은 슬프지만, 종종 사실이다.
유사하게 사무실 환경에서 우리가 자주 감사함을 받는 유일한 시간은 그 사람이 떠날 때이다. 그 중에는 떠나지 않기를 간절히 바라는 훌륭한 동료들이 있다. 하지만 그러기엔 너무 늦었다.
이 위대한 동료가 떠날 생각도 하기 전에 모두가 진심으로 감사해하고, 공개적으로 칭찬과 공로를 인정했다면, 떠나지 않았을지도 모른다. 떠나는 대신, 그들은 그 과정에서 합당한 승진을 계속하고, 조직에 기여할 수 있었을 것이다.
위의 내용이 너무 단순한 생각이라는 것을 이해하지만, 필요한 때에 동료에게 진정으로 감사를 표하는 것이 놀라운 일이라는 사실은 변하지 않을 것이다. 감사하는 사람은 좋은 친구가 된다. 사람들은 자신이 높이 평가되는 곳으로 가는 것을 좋아한다.
모두가 서로의 노력에 감사할 때 그것이 하나의 문화가 된다. 결속을 강화한다. 함께 일하는 것이 훨씬 더 의미있는 긍정적인 분위기를 조성하게 된다. 아무도 더 이상 자신을 스스로 칭찬할 필요가 없으며, 모든 사람이 여전히 합당한 보상을 받는 동안 좋은 일에 대해 불안함을 느끼지 않아도 된다.
한 부모에게 사과 먹기를 좋아하는 두 아이가 있다는 이야기가 있습니다.
부모는 그들 각각에게 사과를 줍니다.
자기 사과를 먹지 않고 형이 사과를 동생에게 줍니다.
그 대가로 어린 아이도 큰 아이에게 자기 사과를 줍니다.
모든 사람이 여전히 사과를 가지긴 했지만, 상황은 달라졌습니다.
그들은 지금 사과 뿐 아니라 그 이상의 것을 얻었습니다.
그들은 관계를 구축하였고, 서로에게 감사하고 있습니다.
5. 항상 축하할 일이 있다
금요일과 토요일 밤이 일주일 중 가장 행복한 밤인 이유를 아는가. 사람들이 나가서 파티를 하고, 친구들을 만나고, 서로를 응원하기 때문이다.
종종 사람들은 근무 시간이 ‘진지한'것으로 간주되기 때문에, 사무실과 근무 시간에는 그러한 느낌을 찾지 못한다.
나는 우리가 일하는 동안 파티를 하거나 책임을 소홀히해서는 안된다는 점에는 동의하지만, 그 과정에서 우리가 알고 있는 작은 승리나 성공으로 분위기를 복돋을 수 있다.
우리는 축하하기 위해 메이저 소프트웨어 릴리즈를 기다릴 필요가 없다. 그 때까지 기다리기에는 너무 오래 걸린다. 그것 외에도 함께 축하할 다른 일이 많다.
아래는 몇 가지 예시이다.
- 누군가가 태스크 카드(작은 카드라도)를 완료했다!
- 누군가 PR(Peer Code Review)에서 찾은 훌륭한 코드를 작성했다.
- 누군가의 생일!(맙소사, 이 글을 쓰면서 누군가의 생일을 잊어버렸다는 사실을 깨달았다!) 또는 특별한 경우(그래서 우리는 팀원들을 더 잘 알아야 한다.)
- 새로운 사람이 팀에 합류하거나 팀에 복귀한다.(교대 또는 긴 휴식 후)
- 우리 팀원이 다른 팀원에게 높이 평가될 때
- 100번째 코드 커밋, 200번째 빌드 등과 같이 특정 숫자를 달성하면
- 기록을 깨는 경우(예를 들어 소프트웨어 다운로드 사용자 수, 삭제된 이전 코드의 라인 수 등)
- O년 전 오늘과 같은 특정 기념일(예를 들면 첫 번째 소프트웨어를 출시한 날 등)
- 혹은 간단하지만, 금요일에도!!
- 더 많은 것을 생각할 수 있게, 창의적으로 생각합시다!
함께 성공을 자주 축하하는 팀은 유대감이 훨씬 좋다. 그것은 더 긍정적인 순간을 만들고 사람들은 동기를 느끼고, 더 많이 모이는 것을 좋아한다!
인생은 좋은 순간을 축하하기에도 너무 짧습니다. - 위르겐 클롭
6. 어리석은 질문은 없다
문서화 되어있지는 않지만 소프트웨어 개발자의 역할에 대한 한 가지 기대는 “계속 학습”이다. 배울 것이 너무나도 많다. 아무다 다 알 수는 없다. 누구나 다른 사람이 모르는 것을 알고 있다.
팀을 기술적으로 강하게 만드는 것은 이 그룹 지식이다. 특히 서로를 보완하고, 기꺼이 공유하고, 서로에게서 배우는 경우에 해당한다면 그렇다.
주니어 개발자는 시니어에게 배운다. 마찬가지로 시니어도 주니어 개발자에게 배울 수 있다. 모두가 공유한다. 시니어 개발자 뿐 아니라 모두가 배운다.
아무도 질문을 하거나 자신의 무지를 드러내는 것을 두려워 하지 않는다. 가장 기본적인 질문을 했다고 조롱받는 사람은 아무도 없다. 그냥 아무것도 알지 못하고 넘어가는 것은 괜찮지 않지만 질문하면, 기대가 된다.
모든 사람들은 그들이 알고 있는 한 최선을 다해 답을 기꺼이 제공할 의향이 있으며, 놓치는 것이 있으면 바로잡을 수 있다. 교정은 결코 겸손한 방식으로 이루어지지 않는다.
공유하는 자가 우월하지 않고 구하는 자가 열등한 것이 아니다. 개발자 삶의 일부일 뿐이다. 항상 배우고, 항상 공유한다.
어리석은 질문을 하면, 당신이 어리석게 느껴질 수 있습니다. 어리석은 질문을 하지 않는다면, 당신은 어리석은 것입니다. - 토니 로스만
7. 모든 실수는 모두가 책임져야 한다
어느 날 분석팀은 앱 분석 데이터가 지난 3개월 동안 비정상적인 추세를 보이는 것을 발견했다. 그것은 앱 개발팀에 리포팅되었다. 코드를 작성한 팀원이 장기 휴가중이었다. 따라서 팀장은 코드를 파고들어 버그를 수정해야 했다.
리포팅에 영향을 끼치므로 중대한 사건이다. 따라서 회고를 진행한다. 돌이켜보자면 아래 중 어느쪽이든 갈 수 있다.
A. 아무도 그것을 소유하고 싶어하지 않는다
- 분석 팀은 버그를 만든 앱 팀을 비난한다.
- 팀장은 팀원이 일을 잘하지 못했다고 비난한다. 팀장은 또한 3개월 후에 이 문제를 보고한 분석 팀을 비난한다.
- 팀 구성원은 승인하기 전에 코드를 제대로 검토하지 않은 팀장을 비난하고, 테스트를 돕지 않은 분석 팀을 비난한다.
B. 모든 사람이 소유한다
- 분석 팀은 문제를 더 일찍 감지했어야 했으며, 초기 테스트에서 도움을 주었다고 말했다.
- 팀 리더는 코드 리뷰가 더 철저하게 할 수 있으며, 문제를 방지하기 위해 더 나은 테스트 자동화를 모색할 수 있다고 말했다.
- 팀원들은 자신이 만들고 놓친 버그를 인정하고 앞으로 더 조심할 것이다.
나는 당신에 대해 알지 못한다. 나는 위의 시나리오에서 B팀 처럼 일하는 것을 좋아한다. 모든 사람은 실수를 인정하고 다른 사람의 도메인 문제를 지적하는 대신 자신의 도메인에서 개선할 수 있는 방법을 찾는다.
실수는 때때로 피할 수 없으며, 우리는 서로를 지원하고 함께 배우고 있다.
실수하지 않는 유일한 사람은 아무것도 하지 않는 사람입니다. - 시어도어 루즈벨트
8. 예의를 갖춰라
나는 작업 지향적인 사람이다. 누군가가 무엇인가를 해야할 때, 나는 그들에게 메시지를 보내는 주제로 바로 갈 것이다. 예를 들면, 아래처럼 할 수 있다.
“저를 위해 이 코드를 검토해주시겠습니까?”
아침에 막 출근하는 팀원이 이 문장을 읽었을 때, 어떤 기분이 들 것 같은가. “아 해야할 일이 들어왔네요. 오늘은 완료해야 할 일이 더 많군요.”라고 할 수 있다. 썩 유쾌한 느낌은 아닐 것이다.
서로를 믿고 친하게 지내는 팀이지만, 기본적인 예의는 빼놓지 않아야 할 매너이다.
메시징 대화를 시작할 때 서로 인사를 한다. 상대방도 바쁠 수 있으니 주의하자. 누군가에게 무엇인가를 요청하는 것은 원칙적으로 업무 범위의 일부라 할지라도, 여전히 누군가로부터 친절을 받는 것과 같다.
예를 들면 이렇게 말이다.
“좋은 하루입니다! 시간이 되신다면, 이 코드를 검토하는 데 도움을 주실 수 있을까요? 매우 감사드립니다!”
글이 조금 길어질 수 있지만, 읽어보면 세심한 배려와 재치로 쓴 글임을 알 수 있다. 너무 까다롭게 들리지도 않는다. 그저 감사함을 나타내고 있을 뿐이다.
현대적인 메시징 방식으로는 이모티콘을 추가할 수도 있다. 더 표현력있고, 친근하게 만들자.
“좋은 하루입니다! 🌅 시간이 되신다면, 이 코드를 검토하는 데 도움을 주실 수 있을까요? 🤗 매우 감사드립니다! 🙏🏻”
어떤 이모티콘을 써야할지 고민이 될 때도 있겠지만, 노력과 정성이 보이게 된다.
이것은 예의를 지키는 한 가지 예시일 뿐이다. 지위에 관계없이 서로를 존중하자.
그럴 자격조차 없는 사람들에게 존경을 표하세요. 그들의 성격을 반영하는 것이 아니라, 당신의 성격을 반영하는 것입니다. - 데이브 윌
9. 긍정적인 의도를 가정하라
내가 조적에서 개발자로 처음 시작했을 때, 가장 두려웠던 것 중 하나는 PR(Peer Code Review)이었다. 나에게는 이 과정을 통해 이 영역에서 자신의 ‘우월함'을 강조하는 것처럼 보이는 여러 리뷰어가 있었다.
그들은 종종 겉보기에 중요하지 않은 많은 항목과 때때로 논쟁의 여지가 있는 항목을 리뷰에서 짧게 뽑아내었다. 이것은 코드에서 많은 수의 ‘결함'을 식별하고 나를 무능하거나 게으른 프로그래머처럼 보이게 만들 것이라고 생각했다.
싫었다! 나는 종종 내가 이것을 하는 이유와 그에 대한 대응으로 ‘방어적인' 이유를 생각해 내었다. 전체 리뷰 프로세스는 긴 체인과 이리저리 적법한지 논쟁이 있는 소송과도 같았다. 팀 스피릿에 해로웠다.
나중에, 나는 어떤 것을 배웠다. ‘우수함'을 보여주고 싶어하는 일부 리뷰어가 있을 수 있지만, 대부분은 실제로 어떤 방식으로든 코드를 보다 일관성있게 만들려는 좋은 의도를 가지고 있다. 어떤 사람들은 다른 사람들보다 더 독단적일 수 있지만, 그들 중 누구도 나를 겁주려고 하지 않는다.
사실, 철저하게 리뷰하고 코드를 트집잡는 데에는 상당한 시간이 걸린다. 많은 노력을 기울여야 하고, 희생하는 봉사인 것이다.
게다가 나는 많은 것을 배워야 했다. 발견된 모든 ‘결함'은 나를 개선할 수 있는 기회이다! 때때로 논란의 여지가 있는 리뷰 코멘트나 기존에 없던 리뷰 코멘트가 있을 수 있지만, 실제로 다른 사람들이 어떻게 생각하는지에 대한 더 넓은 시야를 보는 데 도움이 된다. 내 시야를 넓혀주기도 한다.
나는 얻는 것만 있게 된다. 잃는 것은 없다. 내가 그것을 배우는 한, ‘결함’의 수는 확실히 줄어들 것이다.
나의 전체적인 관점이 바뀌었다. 나는 지금 전체 리뷰과정을 매우 긍정적으로 보고 있으며, 어떤 리뷰 코멘트도 환영한다. 누군가가 내 코딩 스타일에 대해 반대 의견을 줄 때에도 나는 그것을 즐긴다.
나는 ‘하드' 리뷰어를 좋아하기 시작하였다. 그들은 최고만을 원하는 헌신적인 팀원이다.
긍정적으로 본다면, 팀과 훨씬 더 잘 어울릴 수 있다.
관점을 바꾸면 세상이 바뀐다!
10. 모두 놀도록 하자
한 단어로 표현하자면, 포괄성(Inclusivity)을 의미한다.
나는 세계의 다양한 지역에서 온 다양한 민족적 배경을 가진 사람들과 함께 일하는 것을 영광으로 생각한다. 많은 흥미로운 문화와 삶의 접근 방식에 대해 배우는 것은 매우 흥미로운 일이다.
고정관념을 피하는 동안 어떤 국가의 사람들은 일반적으로 조용하고, 요청을 받거나 핫한 질문이 있을 경우에만 말을 한다. 또 다른 나라 사람들은 자기 생각을 자기 주장대로 쉽게 하는 사람들도 있다.
따라서 회의 환경에서 어떤 사람들은 더 독단적이며, 또 다른 사람들은 조사해야할 때만 말을 한다. 우리가 조심하지 않으면 회의는 더 독단적인 사람들에 의해 지배될 것이고, 우리는 더 조용한 사람들로부터 받을 수 있는 귀중한 아이디어를 놓치게 될 수도 있다.
이를 염두에 두고, 회의 중에 때때로 조용한 그룹을 지속적으로 조사해야 한다. 가상 회의를 할 때 문의사항 같은 것을 작성하여 메시지를 보내지 않는 분들의 의견도 들을 수 있도록 해야 한다.
좋은 점은 시간이 지나면 사람들이 배운다는 것이다. 더 조용한 그룹은 이제 더 많은 말을 하는 반면, 적극적인 그룹은 다른 사람들이 말할 시간을 주기 위해 때때로 참기도 한다. 우리는 서로에 대해 더 잘 배운다. 모든 사람은 참여할 수 있는 동등한 기회를 얻는다.
이것은 포괄성의 한 측면일 뿐이다. 많은 측면이 있다. 소수 집단이 적을 수록 아무도 뒤쳐지지 않도록 더 주의해야 한다.
우리는 뒤돌아 보지 않습니다. 우리는 아무도 뒤에 남겨두지 않습니다. 우리는 서로 끌어 당깁니다. - 버락 오바마
우리는 문화를 형성한다. 문화가 우리를 만든다.
우리가 내성적이든 외향적이든 한 성격에 관계없이 다른 사람들과의 상호작용은 불가피할 뿐만 아니라 우리를 사람답게 만든다. 우리가 다른 사람들과 상호작용하는 방식이 문화를 형성할 것이다.
긍정적인 근무 문화를 심어주는 것이 중요하다. 직장이 지옥인지 천국인지 판단할 수 있다. 직장에 긍정적인 문화가 있으면 일을 더 의미있고 생산적으로 할 수 있다. 서로를 친구로 생각하고 더 의미있는 삶을 살고 있다.
현재 긍정적인 직장 문화가 없는 직장에서 일하고 있다면, 이것은 우리 자신으로부터 시작될 수도 있다. 항상 변화는 하나에서부터 시작된다.
'[Developer] > Any' 카테고리의 다른 글
성장하는 개발자로서 필요한 3가지 요소 (0) | 2023.02.24 |
---|---|
[Google Cloud 실습] Kubenetes Engine으로 배포 관리 (0) | 2022.07.24 |
Github에서 Keystore를 Secret Key로 반영하기(feat. Android) (2) | 2021.08.14 |
동영상 키프레임 조절 (0) | 2020.07.04 |
구글 머신러닝 스터디잼 - AutoML Vision으로 이미지 분류해보기 (0) | 2019.04.23 |
댓글