팀으로 이동하는 Solo .NET 프로그래머 [닫기]

나는 지난 8 년간 소규모 스타트 업을위한 독창적 인 .NET 프로그래머였습니다. 나는 꽤 괜찮은 소프트웨어를 만들었고, 항상 소스 컨트롤 (SVN / TFS)을 포함한 모범 사례를 따르고 더 나아지기 위해 노력했다. 다른 분야의 엔지니어 팀과 매우 긴밀히 협력했지만 소프트웨어에 관한 한 유일한 프로그래밍이었습니다. 나는 프로그래밍 기술을 좋아하고 도구를 연마하기 위해 새로운 것을 배우는 것을 좋아합니다.

2 주 후에 20 명의 .NET 개발자 팀에서 새로운 직업을 시작할 것입니다. 저의 입장은 중급 수준이며, 매우 인상적인 배경을 가진 일부 프로그래머들과 함께 일하게됩니다. 다시 한 번, 개발의 팀 측면은 나에게 새로운 것이기 때문에, 나는 가능한 한 효율적이고 쉽게 접근 할 수 있도록 도와주는 일반적인 "새로운 사람"팁을 찾고 있습니다.

높은 수준의 팁과 일상적인 의사 소통에 관한 모든 것을 포함하여 모든 것이 진행됩니다.

대부분 상식이지만 조언은 다음과 같습니다.

기술보다는 사람들과 함께 첫 주를 보내십시오. 데스크탑을 커스터마이징하거나 팀에서 당신을 격리시킬 수있는 어떤 것도 첫날 낭비하지 마십시오. 가능한 한 많은 동료를 가능한 한 빨리 알리십시오.

일하는 말이 누구인지, 부랑자가 누구인지 빨리 알아보십시오. 가능한 한 많은 범프를 피하십시오. 모든 팀에는 해당 범프가 있으며 하나로 분류되기를 원하지 않습니다.

직장이나 점심 식사 후에 맥주를 마시더라도 처음 몇 주 동안 모든 사교 행사에 참석하십시오.

듣고 내용을 적어 놓고 동료들에게 절차에 대한 설명을 반복하도록 요청하십시오.

특정 문제에 대해 특별히 요청하지 않는 한 처음 3-6 개월을 숙지하고 절차 / 아키텍처 등의 변경을 권장하지 마십시오. 그것들은 당신에게 다르게 작동 할 것이고, 일부 요소는 열악 할 수 있습니다-그러나 그 이유가있을 것입니다.

프로그래밍 측면이 실제로 문제가 될지 의심됩니다.

• 배우다! 새로운 프로그래머를 만나는 것은 새로운 기술을 배우는 좋은 방법입니다. 입력 유형을 살펴보면 몇 가지 편집 요령을 배우고 코드를 보면 새로운 아이디어를 얻을 수 있습니다.

• 5 분마다 동료를 괴롭히지 말고 멈췄다면 주저하지 말고 도움을 요청하십시오. 이틀 동안 너무 많은 프로그래머가 프로그램에 갇혀 이웃에게 1 시간 안에 문제를 해결했을 것입니다.

• 코드 전쟁은 종교 전쟁입니다. 구문은 약간 다를 수 있지만 (단일 줄에 괄호를 추가합니까?) 싸울 가치가 거의 없습니다.

• 사교. 그들이 매주 음료를 마시고 있다면 반드시 참여하십시오. 함께 먹는 것만 큼 ​​간단 할 수 있습니다 .

Devil 's Advocate를 플레이하면 팀원이 유능한 지 확인해야합니다. "올바른"방식으로 일을하는 사람 외에는 아무도 잘못하고 싶어하는 사람들이 항상 숫자보다 많기 때문에 팀에서 일하는 것보다 나쁜 것은 없습니다.

당신은 인상적인 배경을 가진 개발자들과 함께 일하는 것을 언급하므로 유망한 소리가 나는 경우에 당신이 할 수있는 것을 배우는 것이 좋습니다. 다른 사람들이 무언가 잘못하고 올바른 일을한다면 타협하지 마십시오.

Jonno 외에도 다음과 같이 말합니다.

변화에 대비하십시오. 모든 팀은 다르게 작동합니다. 훌륭한 SW 팀에는 코딩 규칙이 있습니다. 처음에는 이상해 보일지라도 받아 들일 준비를하십시오.

더 많은 의사 소통을 준비하십시오. 혼자서 일할 때 많은 세부 정보가 머리에 있습니다. 팀에서 일하자마자 이러한 세부 사항 (적어도 일부)을 공유하고 전달해야하며이를 위해서는 시간이 필요합니다.

말보다 더 들어 봐

답변을 시도하는 것보다 더 많은 질문을하십시오 (질문이 지시되지 않는 한). 팀의 "이전 타이머"는 질문에 의해 코드 학습에 얼마나 많은 진전이 있는지 알 수 있습니다. 그들은 아마도 그들이 기대하고있는 질문들의 정신적 인 목록을 가지고있을 것입니다.

일반적인 스타일에 맞게 코드를 작성하십시오. 공백, 중괄호, 대문자, 변수 이름 길이, 평균 메서드 크기, 주석 밀도 및 중요하지 않은 모든 항목을 넣는 위치에 적용됩니다. 다른 방식으로 일을해야 할 충분한 이유가 있다면, 구식 중 한 명에게 왜 팀에게 주어진 스타일이 있는지 물어보십시오. 당신은 팀의 역사와 성격에 대한 흥미로운 것들을 배울 수 있습니다. 다음 단계로 넘어갑니다.

팀의 지식을 배우십시오. 대부분의 지식은 어디에도 기록되어 있지 않지만 팀에 대한 일반적인 지식입니다. 팀 지식에는 프로젝트의 현재 상태, 과거의 실수, 과거의 성공, 그 과정에서 얻은 교훈에 대한 역사가 포함됩니다. "frobnitz 버그처럼 다시 들리는 소리"와 같은 간단한 문구로 언급됩니다. 팀원이 누군가가하는 비밀스러운 의견에 동의하거나 보거나들을 때, 팀에 대한 지식이있을 수 있습니다. 누군가에게 물어봐.

관련된 성격과 역사를 알 때까지 코드를 비판하지 마십시오. 당신은 누가 당신을 화나게할지 모릅니다.

질문하고 답변을 들으십시오. 다음 질문을하기 전에 이전 질문에 대한 답을 생각하여 답을 예상하십시오.

최선을 다해 최선을 다하십시오. 다음 달에 변경해야 할 경우 팀의 다른 사람이 귀하의 코드에 대해 어떻게 생각할 것인지 스스로에게 물어보십시오.

해결해야 할 문제가있는 경우 문제에 대해 우려를 표하기 전에 합리적인 해결책을 제시 할 수 있도록 최선을 다하십시오. 문제를 지적 할 때 솔루션 구현을 소유하십시오.