Lập trình viên Solo .NET chuyển sang một nhóm [đóng]

Tôi đã là một lập trình viên .NET solo cho một startup nhỏ trong 8 năm qua. Tôi đã kết hợp một số phần mềm khá tốt và tôi luôn cố gắng cải thiện bản thân và tuân thủ các thực tiễn tốt nhất, bao gồm kiểm soát nguồn (SVN / TFS). Tôi đã làm việc rất chặt chẽ với một nhóm các kỹ sư thuộc các chuyên ngành khác, nhưng khi nói đến phần mềm, tôi là người duy nhất lập trình. Tôi yêu nghề lập trình và thích học những điều mới để mài giũa các công cụ của mình.

Trong 2 tuần nữa tôi sẽ bắt đầu một công việc mới trong một nhóm gồm 20 nhà phát triển .NET. Vị trí của tôi sẽ là trung cấp, và tôi sẽ làm việc dưới một số lập trình viên với nền tảng vô cùng ấn tượng. Một lần nữa, khía cạnh phát triển nhóm sẽ là mới đối với tôi, vì vậy tôi đang tìm kiếm một số mẹo "người mới" nói chung sẽ giúp tôi hiệu quả và dễ dàng hòa hợp nhất có thể ngay từ khi đi.

Bất cứ điều gì đi, bao gồm các mẹo cấp cao, và những điều nhỏ nhặt hàng ngày về giao tiếp.

Chủ yếu là lẽ thường nhưng lời khuyên của tôi sẽ là:

Hãy dành nhiều tuần đầu tiên với mọi người hơn là công nghệ. Đừng lãng phí ngày đầu tiên tùy chỉnh máy tính để bàn của bạn hoặc bất cứ điều gì khác sẽ cách ly bạn khỏi nhóm. Nhận biết càng nhiều đồng nghiệp càng nhanh càng tốt.

Hãy cố gắng tìm ra những con ngựa làm việc và ai là người nhanh chóng. Tránh các lợi ích càng nhiều càng tốt, mọi đội đều có chúng và bạn không muốn được phân loại thành một.

Tham dự bất kỳ sự kiện xã hội nào trong vài tuần đầu tiên, ngay cả khi chỉ là một ly bia sau khi làm việc hoặc ăn trưa.

Nghe và viết mọi thứ xuống, yêu cầu các đồng nghiệp lặp lại các mô tả về các thủ tục sẽ anoy chúng.

Dành 3-6 tháng đầu tiên để làm quen, trừ khi được hỏi cụ thể về một vấn đề cụ thể, không đề xuất thay đổi quy trình / kiến ​​trúc / v.v. Chúng sẽ hoạt động khác với bạn, và một số yếu tố có thể kém - nhưng sẽ có lý do cho điều đó và chúng hiếm khi do sơ suất hoặc thiếu hiểu biết.

Tôi nghi ngờ phía lập trình sẽ thực sự là một vấn đề.

• Học hỏi! Gặp gỡ các lập trình viên mới là một cách tuyệt vời để học các thủ thuật mới. Xem họ gõ sẽ học cho bạn một vài thủ thuật biên tập và nhìn vào mã của họ sẽ cho bạn những ý tưởng mới.

• Đừng làm phiền đồng nghiệp của bạn cứ năm phút một lần nhưng nếu bạn thực sự bế tắc, đừng ngần ngại yêu cầu giúp đỡ. Quá nhiều lập trình viên bị mắc kẹt trong một chương trình trong hai ngày, trong đó yêu cầu hàng xóm của bạn sẽ giải quyết nó trong một giờ.

• Chiến tranh mã là chiến tranh tôn giáo. Cú pháp có thể hơi khác ở đó (bạn có thêm dấu ngoặc vào câu lệnh singe không?) Nhưng hiếm khi đáng để đánh nhau hơn.

• Xã hội hóa. Nếu họ đang uống nước mỗi tuần, hãy chắc chắn tham gia. Điều này có thể đơn giản như ăn cùng nhau .

Chơi Advocate của Devil và tôi sẽ nói chắc chắn rằng đồng đội của bạn có năng lực. Không có gì tệ hơn là làm việc trong một nhóm mà không ai ngoại trừ bạn làm bất cứ điều gì theo cách "chính xác", bởi vì bạn luôn vượt trội so với những người muốn làm sai.

Bạn đề cập đến việc làm việc dưới các nhà phát triển với nền tảng ấn tượng, để nghe có vẻ hứa hẹn và trong trường hợp đó tôi khuyến khích bạn học những gì bạn có thể, nhưng đừng bao giờ quên những gì bạn đã biết vì "tâm lý bầy đàn". Nếu mọi người khác làm điều gì sai và bạn làm đúng, đừng tự thỏa hiệp.

Ngoài Jonno, tôi sẽ nói:

Hãy chuẩn bị cho những thay đổi. Mỗi đội làm việc khác nhau. Đội SW tốt có quy tắc mã hóa. Hãy chuẩn bị để chấp nhận chúng, ngay cả khi ban đầu chúng có vẻ kỳ lạ.

Hãy chuẩn bị cho nhiều giao tiếp hơn. Khi bạn tự làm việc, rất nhiều thông tin chi tiết nằm trong đầu bạn. Ngay khi bạn làm việc trong một nhóm, những chi tiết này (ít nhất là một vài trong số chúng) phải được chia sẻ và truyền đạt và cần có thời gian cho việc này.

Nghe nhiều hơn bạn nói.

Đặt nhiều câu hỏi hơn là bạn cố gắng trả lời (trừ khi các câu hỏi được hướng vào bạn). "Bộ tính giờ cũ" trong nhóm sẽ biết bạn đang tiến bộ bao nhiêu trong việc học mã bằng các câu hỏi bạn đặt ra. Họ có thể có một danh sách tinh thần của các câu hỏi mà họ đang mong đợi.

Viết mã của bạn để phù hợp với phong cách thịnh hành. Điều này áp dụng cho nơi bạn đặt dấu cách, dấu ngoặc nhọn, chữ in hoa, độ dài của tên biến, kích thước trung bình của phương thức, mật độ nhận xét và mọi thứ khác không quan trọng. Nếu bạn có một lý do thực sự tốt để làm những điều khác biệt, thì hãy hỏi một trong những người cũ tại sao nhóm có phong cách nhất định. Bạn có thể tìm hiểu một số điều thú vị về lịch sử và tính cách của đội. Điều này đưa tôi đến điểm tiếp theo.

Tìm hiểu truyền thuyết đội. Nhiều khả năng không có truyền thuyết nào được viết ra ở bất cứ đâu, nhưng đó là kiến ​​thức phổ biến về đội. Nhóm truyền thuyết bao gồm lịch sử về cách dự án đạt đến trạng thái hiện tại, những sai lầm trong quá khứ, những thành công trong quá khứ, những bài học kinh nghiệm trên đường đi. Nó được đề cập đến trong các thống kê ngắn gọn như "âm thanh giống như lỗi frobnitz một lần nữa." Khi bạn thấy / nghe các thành viên trong nhóm đồng ý với nhận xét khó hiểu mà ai đó đưa ra, có lẽ có truyền thuyết nhóm liên quan. Hỏi ai đó.

Đừng chỉ trích mã cho đến khi bạn biết các tính cách và lịch sử liên quan. Bạn không biết bạn có thể đang xúc phạm ai.

Đặt câu hỏi và lắng nghe câu trả lời. Hãy suy nghĩ về câu trả lời cho các câu hỏi trước khi bạn hỏi câu tiếp theo để bạn có thể cố gắng dự đoán câu trả lời.

Phấn đấu để làm công việc tốt nhất bạn có thể. Làm quen với việc tự hỏi những người khác trong nhóm sẽ nghĩ gì về mã của bạn nếu họ phải thay đổi nó vào tháng tới.

Nếu bạn thấy một vấn đề cần được giải quyết, hãy cố gắng hết sức để có một giải pháp hợp lý sẵn sàng đưa ra trước khi bày tỏ quan ngại về vấn đề này. Hãy sở hữu thực hiện một giải pháp khi bạn chỉ ra một vấn đề.