Lựa chọn cho một lập trình viên người thích lập trình để dẫn đầu? [đóng cửa]


19

Vào đầu năm nay, tôi đã được đề bạt vai trò nhà phát triển chính sau khi nhà phát triển chính của nhóm chúng tôi chuyển sang một bộ phận khác. Tôi có khoảng 5 năm kinh nghiệm làm việc và do có sẵn và hiệu suất trong quá khứ, tôi là lựa chọn chính của ban quản lý để lãnh đạo dự án. Tôi hơi e ngại nhưng quyết định đó là một cơ hội tốt để thăng tiến nghề nghiệp và kinh nghiệm, vì vậy tôi đã chấp nhận.

Nhưng kết luận của tôi cho đến nay là tôi không thích nó nhiều như vị trí nhà phát triển trước đây của tôi. Mặc dù tôi đã lãnh đạo thành công một nhóm gồm 5 nhà phát triển thông qua một số bản phát hành, tôi gần như không bao giờ chạm vào bất kỳ mã nào. Thay vào đó tôi thực hiện lập kế hoạch và thiết kế và quản lý nhóm, cùng với các đánh giá mã. Sự cần thiết phải theo dõi nhiều thứ nữa, và có kế hoạch nhiệm vụ để chúng có thể được giao cho nhóm, theo nghĩa đen khiến tôi đau đầu nhất mỗi ngày. Mặc dù tôi hiếm khi làm việc ngoài giờ, tôi cảm thấy mệt mỏi nhất mỗi ngày khi tôi nghỉ làm và không nghĩ rằng tôi thậm chí còn tận hưởng thời gian ngoài giờ làm việc nhiều như vậy.

Vì vậy, câu hỏi của tôi: làm thế nào bạn sẽ xử lý, hoặc bạn đã xử lý như thế nào, một tình huống như vậy? Đối với những người trong tình huống tương tự, bạn đã tìm cách quản lý nhóm của mình tốt hơn, nhiệm vụ và thời gian khiến bạn thích công việc chưa? Hay bạn đã tìm ra cách để chuyển trở lại vào một vị trí định hướng phát triển hơn? Tôi biết rằng các vị trí nhà phát triển hàng đầu hầu như luôn trả mức lương cao hơn, nhưng tôi có thể thấy bản thân mình đến một điểm mà tôi ít quan tâm đến tiền và các chương trình khuyến mãi hơn là tôi thích công việc hiện tại của mình.

Tôi đã không thảo luận điều này với bất cứ ai trong quản lý vì tôi nghĩ tôi nên cố gắng điều chỉnh ít nhất một năm.


"Tôi đã không thảo luận điều này với bất cứ ai trong quản lý". Tại sao trên trái đất không ?? Chạy, không đi bộ, để quản lý và giải thích. Một công ty tốt / người quản lý tốt sẽ hiểu và sắp xếp lại mọi thứ theo lợi ích của mọi người - của bạn và của họ. Dù sao bạn cũng không muốn làm việc ở một loại công ty khác
Mawg

Câu trả lời:


16

Câu trả lời tôi cung cấp ở đây là dự đoán tốt nhất của tôi về những gì có thể có khả năng hoạt động, nhưng tôi chưa thấy nó hoạt động khi bản thân tôi đang cố gắng thoát khỏi tình huống tương tự nơi bạn đang tìm thấy chính mình. Toàn bộ điều vẫn là một kinh nghiệm học tập cho tôi nhưng tôi đang nhìn thấy xu hướng tích cực trong nhóm của tôi.

Trong công ty của tôi, tôi đã được đề bạt làm trưởng nhóm (họ gọi đó là "trưởng nhóm thiết kế") và vì thiếu người biết sản phẩm và có đủ kinh nghiệm, tôi đã tình nguyện lãnh đạo 2 nhóm khác nhau. Vài tháng trước "để giúp với lịch trình", ban lãnh đạo đã nhân đôi quy mô của 2 đội này.

Một số điều tôi đã cố gắng làm ...

  1. Hãy nói rõ với mọi người (bao gồm cả quản lý) rằng vị trí của tôi và của mọi người khác không phải là một nhiệm vụ lâu dài. Mọi người đều được chào đón để bước lên tấm, có cái nhìn rộng hơn về dự án và tham gia vào các quyết định kiến ​​trúc / thiết kế. Tôi sẽ có tiếng nói cuối cùng (bây giờ) nếu có bất đồng không có giải pháp, nhưng cho đến nay điều đó chưa bao giờ xảy ra.
  2. Tập trung vào việc giúp đỡ người khác phát triển và phát triển. Tôi đã có các cuộc thảo luận (gần như triết học) với các nhà phát triển khác nhau vào các thời điểm khác nhau về mã hóa và thiết kế và các cách tiếp cận khác nhau để thực hiện. Một số trong những cuộc thảo luận có liên quan đến công việc thực tế, những người khác là những bài tập suy nghĩ thuần túy. Tôi đã có một anh chàng với hơn 20 năm kinh nghiệm, quay trở lại kệ sách của anh ấy và chọn một cuốn sách C ++ vì anh ấy quan tâm đến một số thứ cấp thấp tôi đã làm với lập trình meta mẫu. Các cuộc thảo luận này có phần dễ lây nhiễm và sau khi bạn đưa ra những chủ đề này đủ lần, mọi người bắt đầu nghĩ về công cụ này.
  3. Đại biểu càng nhiều càng tốt cho người khác. Mặc dù tôi xem xét rất nhiều thứ, tôi không tham gia vào mỗi bài đánh giá mã. Thay vào đó tôi thực hiện đánh giá mã cho những người trung gian của chúng tôi và tôi để những người đó thực hiện đánh giá mã cho một số người xanh hơn. Tôi thấy các bài đánh giá mã giống như một công cụ chuyển giao kiến ​​thức hơn là "hãy chắc chắn rằng chúng tôi đã đọc mọi dòng và tìm mọi lỗi có thể xảy ra".
  4. Khi các giao diện được xác định và thiết kế cơ bản được đặt ra, tôi cho phép ngay cả những người mới hơn cũng có thể tự do mã hóa bên trong các lớp. Vâng, rất nhiều mã đó không hoàn hảo, nhưng nó được kiểm tra và nó hoạt động. Nếu nó vượt qua một ranh giới chủ quan nhất định về "mùi mã" và họ không tái cấu trúc nó, tôi sẽ đề nghị rằng các lớp nhất định phải được chia nhỏ hoặc sắp xếp lại. Đôi khi điều đó thật đau đớn, nhưng khi tôi kiểm tra lại vài ngày sau đó và nhận được phản hồi, "Tôi ghét phải thừa nhận nó, nhưng mã này bây giờ trông tốt hơn nhiều", điều đó thực sự mang lại cho tôi cảm giác ấm áp, mờ nhạt.
  5. Thử thách mọi người. Thay vì chỉ gán tính năng cho họ để thêm vào sản phẩm, hãy yêu cầu họ thêm các tính năng đó, nhưng làm như vậy mà không tăng số lượng chức năng / thành viên dữ liệu trong các lớp hiện có. Nếu bạn phải đặt một cái gì đó mới vào, bạn phải lấy một cái gì đó hiện có ra, và dành thời gian để tìm ra nó là gì. Mọi người đều biết về tái cấu trúc, nhưng không có thêm lực ngay từ đầu, có vẻ như mọi người cần giúp đỡ để thực hiện bước nhảy đó để thực sự làm điều đó. Tối thiểu, tôi làm cho nó là một điểm để truy cập điểm này trong suốt mỗi lần xem xét mã.
  6. Tất cả mọi thứ là về CÂN B .NG. Bạn không thể là người cao cấp duy nhất trong nhóm nhìn qua những người khác. Bạn không thể dành cả tuần của bạn trong các cuộc họp và đánh giá. Bạn không thể mong đợi rằng bạn sẽ nắm bắt mọi sai lầm mà nhóm của bạn mắc phải. Vào cuối ngày, bạn cần phân bổ thời gian cho bản thân để trở thành người dẫn đầu, nhưng bạn cũng cần phân bổ thời gian để trở thành một nhà phát triển. Tôi sẽ phát điên nếu tôi không thể viết mã. Ngay cả với mọi thứ khác, tôi vẫn đảm bảo rằng tôi có thời gian để viết mã và không chỉ mã mà một số thứ thực sự, thực sự tiện lợi. Tôi vừa chạm tay vào sách lập trình meta mẫu và bắt đầu đào sâu vào Boost. Những kẻ nghĩ ra thứ đó phải điên loạn (một cách tốt). Nếu quản lý của bạn bắt đầu làm phiền bạn về lý do tại sao không phải mọi thứ đang được xem xét hoặc tại sao một noob đang xem xét một mã noobs khác, bạn chỉ cần giải thích toàn bộ sự cân bằng và nhóm chỉ đơn giản là không có đủ người có kinh nghiệm và vào cuối ngày "đó là những gì". Nếu nhóm của bạn có những người có thâm niên, thì đã đến lúc trao quyền và cho họ tự do thực hiện các thiết kế / đánh giá của riêng họ / giúp đỡ người khác và đừng coi họ như những người tạo mã đơn giản. Với sự trao quyền đến tự do và mọi người yêu tự do. Nếu bạn có các nhà phát triển không quan tâm đến tự do / trao quyền, điều đó tốt. Mỗi đội vẫn cần những lập trình viên thuần túy, chỉ cần đảm bảo bạn phấn đấu cho sự cân bằng. Đã đến lúc trao quyền và cho họ tự do thực hiện các thiết kế / đánh giá của riêng họ / giúp đỡ người khác và không coi họ là những người tạo mã đơn giản. Với sự trao quyền đến tự do và mọi người yêu tự do. Nếu bạn có các nhà phát triển không quan tâm đến tự do / trao quyền, điều đó tốt. Mỗi đội vẫn cần những lập trình viên thuần túy, chỉ cần đảm bảo bạn phấn đấu cho sự cân bằng. Đã đến lúc trao quyền và cho họ tự do thực hiện các thiết kế / đánh giá của riêng họ / giúp đỡ người khác và đừng coi họ là những người tạo mã đơn giản. Với sự trao quyền đến tự do và mọi người yêu tự do. Nếu bạn có các nhà phát triển không quan tâm đến tự do / trao quyền, điều đó tốt. Mỗi đội vẫn cần các lập trình viên thuần túy, chỉ cần đảm bảo bạn phấn đấu cho sự cân bằng.
  7. Thời gian của bạn là có giá trị. Vì vậy, yêu cầu nhóm gửi e-mail cho bạn tất cả các câu hỏi quan trọng không phải thời gian mà họ có thể đợi trong vài giờ trước khi nhận được câu trả lời. Khi câu hỏi được hỏi, toàn bộ đội nên được sao chép trên đó. Cuối cùng, khi bạn nghỉ ngơi trong ngày, bạn có thể xem xét vấn đề và giúp đỡ người đó, nhưng nhiều lần, người khác có thể đã đánh bại bạn để trả lời và bạn không phải làm gì cả. Rõ ràng là người dẫn đầu, tôi vẫn sẵn sàng và nói rõ điều đó bởi vì tôi tin rằng một trong những mục tiêu của tôi là đảm bảo không ai trong đội bị mắc kẹt trong một thời gian dài mà không tiến bộ.
  8. Hãy chắc chắn rằng nhóm của bạn sử dụng càng nhiều công cụ càng tốt để truyền thông hiệu quả hơn. Ví dụ: chúng tôi có một trang wiki và bất cứ khi nào cùng một vấn đề phát sinh nhiều lần, tôi hỏi người cuối cùng tôi đã giúp tạo một trang wiki.

1
+1 câu trả lời tuyệt vời, rất nhiều lời khuyên thiết thực. Đoàn và cân bằng là những kỹ năng cực kỳ quan trọng, không ngừng phát triển và hoàn thiện.
Péter Török

Lời khuyên tuyệt vời. +1 đặc biệt cho # 4; Tôi đã thấy mọi người lãng phí quá nhiều thời gian do không nghĩ theo cách này.
DarenW

Tôi bị thu hút bởi ý tưởng của bạn về việc thêm các tính năng mà không cần thêm thành viên lớp mới. Bạn có thấy rằng chiến lược này hoạt động tốt?
Tối đa

@Maxpm: Ngoài giờ làm việc tôi thích làm việc trên ô tô. Tôi cũng đã cố gắng học hỏi về điện tử và phần cứng. Tôi mang rất nhiều thứ về nhà. Cách tiếp cận của tôi với các lớp học, là cách tiếp cận mà vợ tôi mang theo: "nếu bạn mang thứ gì đó vào, bạn phải lấy thứ gì đó ra". Tôi không nói không bao giờ thêm một biến hoặc phương thức mới, nhưng có một ngưỡng nhất định mà bạn không thể thêm vào. Nếu mã của bạn trở nên lớn, nhiều khả năng bạn có thể lấy một đoạn lớn và chia nó thành một hoặc nhiều đơn vị độc lập. Sau đó, thay vì nguyên khối lớn, bạn sẽ có các khối xây dựng và bạn có thể di chuyển và sắp xếp lại khi cần
DXM

@Maxpm: quên thêm ... Vâng, chiến lược đó hoạt động rất tốt và đó là cốt lõi của các nguyên tắc RẮN mà tôi muốn mọi người nên làm quen. Đã khá lâu kể từ khi tôi phải đối phó với sự thối rữa trong mã của mình.
DXM

4

Tôi đã không thảo luận điều này với bất cứ ai trong quản lý

Tôi nghĩ rằng bạn biết điều này có thể sẽ giúp. Truyền đạt sự khó chịu của bạn với một vị trí không nhất thiết phải chỉ định bất cứ điều gì cụ thể. Nó cho phép quản lý biết họ giữ những thẻ nào và nếu đó là quản lý tốt, họ sẽ thử và tìm cách sử dụng tiềm năng tốt nhất của bạn. Đừng giải quyết cho ít hơn.


3

Khi dự án của bạn kết thúc, hãy tìm một tư thế định hướng lập trình viên nhiều hơn trong công ty của bạn hoặc bên ngoài nó.

Thảo luận với ban quản lý rằng bạn muốn quản lý ít hơn và "kỹ năng" kỹ năng hơn.

Nghe có vẻ như bạn ở vị trí PM so với nhà phát triển chính. Tôi sẽ xem xét một nhà phát triển chính để được mã hóa nhiều hơn.


Vâng, tôi cũng vậy. Thật không may, một số dự án là như vậy, tôi chỉ là không như vậy. Có đủ công cụ kỹ thuật để quản lý mà tôi phải làm điều đó 95% thời gian. Tôi sẽ cố gắng thay đổi điều này trong tương lai.
William Fontaine

3

Quan điểm của nhà tuyển dụng :

Nếu bạn thích công việc hiện tại và có một lịch sử tốt ở đó thì tôi sẽ muốn giữ bạn lại và sẽ tìm một nơi cho bạn vì vậy tôi sẽ không lo lắng nhiều về việc nói chuyện với họ.

Một nhà phát triển tuyệt vời là một điều có giá trị, nhưng bạn cần bán cho họ rằng bạn đáng làm mã hóa hơn và có thể thiết kế hơn bạn là hành động tung hứng.

Cung cấp cho họ một con đường để hỗ trợ bạn bằng cách thiết lập kế hoạch kế nhiệm. Về cơ bản, bạn tìm thấy một người nào đó trong nhóm hiện tại quan tâm đến việc thực hiện những điều khiến bạn đau đầu, trong 6-9 tháng tới, bạn sẽ huấn luyện họ, giao nhiệm vụ cho họ một lần.

Chọn thứ gì đó dễ dàng trước tiên, như cập nhật trạng thái hàng tuần:

  • Ngồi bên cạnh bạn khi bạn cập nhật trạng thái.
  • Ngồi bên cạnh họ khi họ thực hiện cập nhật trạng thái tiếp theo.
  • Hãy để họ tự làm và xem xét nó trước khi nó đi ra cho trận chung kết.

Sau đó dần dần cung cấp cho họ các nhiệm vụ bổ sung cho đến khi bạn đã bàn giao trách nhiệm bổ sung của bạn.

Lý do những công việc ít mong muốn này được trả nhiều tiền hơn là vì nếu họ không ai sẽ làm chúng, không cần thiết bởi vì chúng đòi hỏi trình độ kỹ năng cao hơn ... cung và cầu.

Để giữ cho bạn trả cao hơn mặc dù ... Nếu là tôi, tôi muốn nghe rằng bạn đang ở xung quanh, bạn sẽ giúp đỡ người này khi được yêu cầu, sẽ là người cố vấn cho những người mới hơn, sẽ là người thiết kế / bộ não chính / chuyên gia tên miền hơn là dẫn dự án. Về cơ bản đây là một vị trí có giá trị, một người khác có thể thực hiện hành động chạy xung quanh và tung hứng (rõ ràng là phải trả nhiều tiền hơn).

Tôi nghĩ rằng nếu bạn trình bày cho chủ nhân của mình một kế hoạch 6-9 tháng cho biết

  • Giải thích tốt về lý do tại sao bạn nghĩ rằng sẽ tốt hơn nếu bạn quay lại tập trung vào mã hóa trên các phản hồi khác.
  • Ai là người tham gia ... hoặc họ phải tìm ai đó ... đây sẽ là một người quyết định chính tôi nghĩ.
  • Tháng Rạch trong 6 tháng, bạn sẽ giao trách nhiệm gì cho người mới
  • Những phản hồi nào bạn sẽ giữ vai (như thiết kế, có thể ngồi trong đánh giá mã, v.v.).
  • Một ý tưởng về việc giảm tiền lương mà bạn sẽ sẵn sàng nhận (ở đâu đó giữa bản gốc và bây giờ) mặc dù hãy để họ đưa ra điều này.

Nếu bạn lấy đó làm kế hoạch cho tôi, với tư cách là một nhà tuyển dụng, tôi sẽ hạnh phúc hơn khi làm việc với bạn trong việc biến điều đó thành hiện thực.

Chúc may mắn.


1

Tôi đã ở trong hoàn cảnh của bạn. câu trả lời thuộc về mối quan hệ bạn có với người quản lý của bạn. Trong trường hợp của tôi, đó là một điều rất tốt, vì vậy một ngày nọ tôi đã gạt anh ấy ra và nói rằng tôi không thích công việc này, cảm thấy quá căng thẳng và muốn quay trở lại với tiền mã hóa. Anh ấy đã rất vui khi nghe điều đó hơn là để tôi bước vào và bỏ cuộc. Vì vậy, chúng tôi đã vạch ra một kế hoạch để người khác tiếp quản với tư cách là Trưởng nhóm và tôi quay lại viết mã.


0

2 câu hỏi không rõ ràng từ bài viết của bạn:

  • Bạn có ở một công ty kiếm tiền trực tiếp từ phần mềm bạn viết (như Google, Microsoft hoặc Fog Creek) hoặc bạn đang ở trong một công ty con (như tại ngân hàng hoặc công ty thực phẩm)?

  • Giám đốc điều hành có phải là một nhà công nghệ, hoặc một người nào đó vươn lên nhờ vai trò kinh doanh?

Nếu bạn là một công ty phần mềm với Giám đốc điều hành công nghệ, đừng lo lắng. Ban lãnh đạo công ty sẽ biết ai là nhà phát triển có giá trị và sẽ làm mọi cách để giữ chân họ. Nếu những người thực thi là tất cả những người có sọc "quản lý con người" hoặc "quản lý ngân sách", hãy quan tâm. Hãy quan tâm gấp đôi nếu bạn ở trong một bộ phận CNTT nội bộ. Nếu đây là trường hợp, thì bạn phải chấp nhận rằng một sự cân bằng cuộc sống công việc tốt là phần thưởng cho việc ở lại một nhà phát triển.

Một điểm cuối cùng - làm những gì sẽ làm cho bạn hạnh phúc. Lời khuyên của mọi người khác về lựa chọn nghề nghiệp như thế này là về những gì sẽ khiến họ hạnh phúc - và đây là về bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.