Bạn có thể là một người quản lý và lập trình viên cùng một lúc? [đóng cửa]

Quản lý các lập trình viên khác trong khi bạn là một phần của lực lượng lập trình.

Đó là một kế hoạch rất phổ biến, ít nhất là trong các công ty tôi làm việc.

Bạn có thể trở thành một lập trình viên giỏi hay một người quản lý giỏi nếu bạn làm cả hai cùng một lúc?

Tôi đang đặt câu hỏi về tính hiệu quả của một cá nhân phải có hai vai trò rất khác nhau, đòi hỏi những kỹ năng, môi trường, sự tập trung, tổ chức, v.v.

CẬP NHẬT : câu hỏi của tôi bao gồm quản lý của công ty (đó là trường hợp của tôi), không phải quản lý nhóm cụ thể. Nhưng tôi quan tâm đến cả hai khóa học.

Nó phụ thuộc vào số lượng và loại chương trình bạn được yêu cầu và số lượng cũng như loại nhiệm vụ quản lý bạn phải thực hiện.

Trở thành một người quản lý có nghĩa là rất nhiều gián đoạn, thay đổi của chiến thuật và những thứ như các cuộc họp, v.v.

Nếu chương trình của bạn bị "giới hạn" trong những phần nhỏ của công việc không khẩn cấp thì bạn có thể phù hợp với những điều này xung quanh nhiệm vụ quản lý của mình. Nếu bạn cần dành thời gian "chất lượng" đáng kể cho một nhiệm vụ lập trình thì bạn sẽ không có được thời gian đó do trách nhiệm quản lý của mình.

Nếu nhóm của bạn lớn và / hoặc phức tạp thì bạn sẽ cần dành nhiều thời gian hơn để quản lý nếu bạn là một nhóm nhỏ dành riêng cho một hoặc hai sản phẩm / dự án. Bạn sẽ thấy rằng bạn không có thời gian để thực hiện bất kỳ chương trình có ý nghĩa nào - ngay cả đối với các nhiệm vụ nhỏ.

Trong một công việc trước đây tôi có vai trò này và nó đã làm việc cho tôi vì tôi giữ các nhiệm vụ lập trình của mình nhỏ. Nó thực sự làm việc để lợi thế của chúng tôi.

Đầu tiên, tôi có thể đánh giá tất cả các yêu cầu đến và nếu chúng nhỏ thêm chúng vào hàng đợi của tôi (luôn luôn ngắn) hoặc quay lại máy khách (trong trường hợp này là người quản lý khác) với thời gian chính xác hơn khi công việc sẽ được thực hiện.

Thứ hai, điều đó có nghĩa là các nhà phát triển trong nhóm không liên tục thực hiện công việc hiện tại của họ để sửa các lỗi nhỏ hoặc thực hiện các cải tiến nhỏ.

Thứ ba, các khách hàng rất vui vì các vấn đề khẩn cấp của họ đã được khắc phục khá nhanh.

Nó giữ cho tôi liên lạc với cơ sở mã để tôi có thể có những cuộc trò chuyện có ý nghĩa với nhóm của tôi về các vấn đề và với người quản lý và khách hàng của tôi về thời gian mà không cần phải khiến nhóm tham gia mọi lúc.

Tôi là một phần của một nhóm các nhà phát triển nơi một lập trình viên cũng là người quản lý của chúng tôi. Điều này dẫn đến sự sụp đổ hoàn toàn của bất cứ thứ gì tương tự như năng suất. Nói tóm lại, tất cả các quyết định được đưa ra bởi anh chàng đó + anh ta là một người quản lý vi mô hoàn chỉnh. Bất kỳ ý tưởng và đề nghị nào mà anh ta không đồng ý đã bị bắn hạ hoặc bỏ qua. Điều này cuối cùng đã giết chết tất cả sự sáng tạo và động lực.

Vì vậy, tôi nghĩ rằng đó là một ý tưởng tồi khi có bất kỳ ai trong nhóm phát triển ở vị trí "cao hơn". Trong trường hợp của tôi, anh chàng là một người quản lý chỉ huy và kiểm soát, nhưng tôi thậm chí là một người quản lý tuyệt vời sẽ (vô tình) ảnh hưởng đến các nhà phát triển khác mà cuối cùng dẫn đến hiệu suất thấp hơn. Ít nhất trong nhóm đang báo cáo với anh ta.

Vâng,
tôi đã thấy một vài người quản lý là Lập trình viên và Người quản lý cùng một lúc, Tin rằng tôi làm việc dưới những người này là tuyệt vời.
Trở thành một người quản lý và lập trình viên không chỉ cho phép các nhà quản lý dẫn đầu từ phía trước mà còn thúc đẩy cấp dưới nỗ lực hết mình.
Hầu hết các nhân viên phàn nàn về người quản lý của họ rằng những người quản lý không có giá trị nhưng người quản lý không chỉ Quản lý mà còn viết mã luôn mang lại kết quả tốt nhất.
Hai nhà quản lý mà tôi đã đề cập, lập trình là niềm đam mê của họ không chỉ giúp đỡ người khác mà còn tạo ra một ứng dụng gần như không có lỗi.

Tôi đã là người quản lý dự án lập trình trong nhiều năm, với các công ty, dự án và nhóm khác nhau.

Quản lý dự án và lập trình là loại công việc / vai trò khác nhau, đến mức tôi cho rằng bạn không thể làm cả hai cùng một lúc ở mức "xuất sắc". Đó là một sự thỏa hiệp - làm chủ không, chủ đề của tất cả các giao dịch, loại điều.

Đối với tôi, nỗi đau lớn nhất là sự chuyển đổi bối cảnh giữa chế độ quản lý và lập trình viên. Họ dường như tham gia vào các phần khác nhau của não (hoặc một cái gì đó). Một ngày lập trình, một ngày quản lý tôi có thể làm tốt, nhưng chuyển đổi giữa các vai trò đó liên tục là khó.

Tôi đã thấy cả hai kịch bản. Các nhà quản lý nhà phát triển thực hiện {một số phần trăm thời gian của họ} về mã hóa và một người quản lý nhà phát triển, không thực hiện mã hóa nào cả.

Vấn đề là, bạn càng có nhiều tiền, bạn càng có nhiều khả năng muốn được trả nhiều tiền hơn, và cách duy nhất để có được điều đó ở nhiều nơi là chuyển sang quản lý. (không phải tất cả, nhưng nhiều nơi). Vì vậy, điều này có thể dẫn đến những người thực sự không sẵn sàng trở thành nhà quản lý bị mắc kẹt trong tình huống đó.

(Tất nhiên, có những công ty mà bạn có thể chuyển lên qua Dev, Dev chì - khác với người quản lý Dev tất nhiên - đến các vị trí như Architect, v.v.)

Rất có thể, là một chuyên gia công nghệ, bạn có thể vô dụng trong việc quản lý con người, cộng với đó sẽ đưa bạn đi xa hơn từ mã. Vì vậy, bạn trở thành một người quản lý tồi, và đang làm ít hơn những thứ bạn thích, và có lẽ đã được phát triển cho!

Đối với tôi, để trở thành một người quản lý, bạn thực sự cần phải xử lý mã hóa, nhưng tuyệt đối giữ cho bản thân mình phát triển với công nghệ để ít nhất bạn vẫn có thể nói về các vấn đề mạch lạc.

Khi nó xảy ra, tôi bắt đầu tự do vì lý do chính xác này. Tôi không có hứng thú với việc quản lý con người và tôi nghĩ rằng tôi sẽ không đặc biệt giỏi về điều đó, cộng với việc tôi sẽ không nhận được nhiều mã.

Nó có thể được thực hiện, nhưng nó đầy những cạm bẫy. Quy mô nhóm và mức độ gián đoạn đóng một vai trò lớn, nhưng rủi ro đáng kể nhất là có người quản lý cũng là người dẫn đầu về kỹ thuật. Quá nhiều ý kiến ​​nặng tay khi không có đủ thời gian / nỗ lực để biện minh cho ý kiến ​​có thể dẫn đến một số quyết định tồi. Và, cuộc tranh luận về phương hướng không phải là một sân chơi bình đẳng giữa người quản lý và phần còn lại của đội.

Đối với những người xem xét con đường này, một số lời khuyên:

• Làm việc theo cách của bạn ra khỏi vai trò kiến ​​trúc và xác định khách hàng tiềm năng trong nhóm của bạn.

• Đừng làm việc trên các mục đường dẫn quan trọng. Sửa lỗi, làm việc trên các nguyên mẫu hoặc các mặt hàng khác có thể được loại bỏ nhanh chóng khi sếp của bạn tìm thấy nhiều 'thứ quan trọng' hơn để đánh lạc hướng bạn.

• Nâng cao mức độ chú ý của bạn và tập trung vào hiệu quả tổng thể, bảo vệ và thúc đẩy đội ngũ, quá trình, tinh thần và các khía cạnh khác cần thiết để có một đội ngũ thành công. Mục tiêu của bạn có thể sẽ không chỉ là một dự án thành công (bất kể ông chủ của bạn, PM hay người khác có thể nói gì).

• Giúp nhóm của bạn phát triển: trở nên độc lập hơn, tự tổ chức, lão luyện kỹ thuật, mức độ nhận thức cao hơn.

• Theo nhiều cách, bạn là cầu nối giữa đội và thế giới bên ngoài. Một phần đáng kể trọng tâm của bạn nên ở bên ngoài nhóm.

Để trả lời câu hỏi, vâng, nó có thể được thực hiện. Không, không dễ dàng và quá nhiều người quản lý mới từ phía kỹ thuật của ngôi nhà, người có thể là người dẫn đầu tuyệt vời, không thể chuyển sang công việc của một người quản lý thành công.

Một người quản lý tốt có thể, vâng. Miễn là bạn vẫn quyết đoán và kiên định, thường không có vấn đề gì.

Nếu nhân viên được yêu cầu đưa ra các vấn đề với đồng đội với người quản lý của họ .. và người quản lý cũng là một đồng đội, điều đó có thể trở nên khó khăn. Điều quan trọng là phải xem tất cả các phản hồi một cách khách quan và nhận ra rằng thỉnh thoảng bạn có thể sai. Bạn cũng nên cung cấp một số loại phương tiện ẩn danh để phản hồi.

Nó là cực kỳ phổ biến (như bạn đã nói) để thấy điều này trong các công ty khởi nghiệp.

Tôi nghĩ rằng không có.

Cả hai công việc đòi hỏi rất nhiều sự tập trung, năng lượng và sự cống hiến. Rất khó để thực hiện cả hai cùng một lúc. Khi tôi phải đảm nhận một số trách nhiệm lãnh đạo nhóm, lượng thời gian tôi dành cho lập trình (và do đó, số lượng công việc liên quan đến lập trình do tôi thực hiện) đã giảm.

Tôi biết một đồng nghiệp khác, người đảm nhận vai trò quản lý từ vai trò lãnh đạo nhóm và hoàn toàn ngừng mã hóa trong vòng một tháng (mặc dù anh ấy đã cố gắng làm cả hai).

Tôi cũng biết một kiến ​​trúc sư đã được yêu cầu trở thành một người quản lý. Ông cũng đã ngừng mã hóa trong vòng một tháng sau khi nhận trách nhiệm quản lý. Kiến trúc sư tương tự sau 8 tháng đã phải quay lại với tiền mã hóa vì các vấn đề quan trọng. Ông đã đóng góp đáng kể trong việc sửa lỗi, nhưng trong vòng một tháng, họ phải tìm một người quản lý thay thế để đảm nhận trách nhiệm quản lý của mình.

Theo kinh nghiệm hạn chế của tôi, tôi chưa tìm thấy ai quản lý các lập trình viên và mã khác như một lập trình viên đầy đủ.

Theo ý kiến ​​của tôi mặc dù có thể trong hầu hết các kịch bản, đó không phải là một sự sắp xếp tốt. Có rất nhiều bài viết về cách những người thành thạo như các nhà phát triển được chú ý và đưa lên vai trò quản lý nhóm mặc dù đây không phải là kỹ năng cụ thể của họ hoặc thậm chí là một vị trí mong muốn. Họ đấu tranh với việc tập trung vào "quản lý" vì họ thấy "công việc" là hoàn thành việc lập trình, không tạo báo cáo và đi họp.

Spolsky đã viết trong bài viết của mình về Lớp trừu tượng dành cho nhà phát triển như sau:

"Với một công ty phần mềm, ưu tiên hàng đầu của quản lý cần phải tạo ra sự trừu tượng đó cho các lập trình viên."

Trong bài viết, (tôi nghĩ nhưng có lý do rõ ràng), vai trò của người quản lý không phải là nhập mã hay phát triển phần mềm mà là tạo ra một môi trường nơi những người sản xuất nó có thể tập trung hoàn toàn vào nó.

Sếp cũ của tôi đã cố gắng. Có quá nhiều sự can thiệp từ vai trò quản lý của anh ấy.

Ông vẫn là một trong những nhà phát triển tốt nhất mà tôi biết.

Hoàn toàn bạn có thể, nhưng điều đó không có nghĩa là nó dễ dàng. Cần một loại người nhất định để trở thành một nhà phát triển giỏi, cần một loại người nhất định để trở thành một người quản lý tốt và một loại người nhất định để trở thành cả hai. Nếu bạn có thể tìm thấy người đó (hoặc là người đó), có những lợi thế nhất định. Các nhà quản lý cấp một hoặc cấp hai của các lập trình viên cần thực sự hiểu những gì người của họ làm và gặp phải mỗi ngày. Khó thực hiện nếu bạn không phải là nhà phát triển và khó giữ liên lạc / cập nhật mà không tiếp tục phát triển.

Người quản lý tốt nhất tôi từng có (tôi đã ở trong biz ~ 25 năm), là một nhà phát triển tích cực, người quản lý của tôi và là chủ sở hữu một nửa của công ty (khoảng 40 emps). Anh ấy đặc biệt nhưng rõ ràng anh ấy đã thành công ở câu hỏi này.

ĐỐI VỚI SỐ KHÔNG !!

Bạn có thể thử, nhưng cuối cùng bạn sẽ quản lý nhiều hơn bất cứ thứ gì. Vấn đề là bạn không thể mã hóa khi mọi người gọi cho bạn cứ sau 5 phút hoặc cố gắng thực hiện các cuộc họp "trạng thái" mỗi giờ. Thật nực cười ... Tôi đang làm điều đó bây giờ, đó là lý do tại sao tôi tình cờ gặp chủ đề này.

Mặc dù người quản lý tại một công ty công nghệ NÊN .. không ... PHẢI biết cách viết mã. Bạn sẽ không thể ước tính hoặc hiểu vấn đề của khách hàng. Mã hóa và quản lý là hai loại người. Một bên là những người lập dị và vụng về với mọi người (đối mặt với nó, những người bạn biết tôi đang nói về điều gì), và một bên là tốt với mọi người. Bạn phải chọn một bên. Bạn sẽ không nhận được mã hóa nếu bạn làm cả hai. Nếu bạn yêu thích tiền mã hóa và có thể làm điều đó 24/7 nếu vợ bạn không cản trở bạn, HÃY CẨN THẬN TỪ QUẢN LÝ. Thậm chí hãy giảm lương nếu bạn phải. Tôi sắp làm điều này, nhưng tôi không nghĩ các ông chủ sẽ thích điều này bởi vì tôi làm cho cuộc sống của họ dễ dàng hơn khi làm phần quản lý. Tôi sẽ phải quay lại làm việc tự do nếu họ không đồng ý vì hạnh phúc và làm những gì bạn yêu thích quan trọng hơn tiền bạc và những ảo tưởng mà nó mua.

Lời chúc tốt nhất với nỗ lực của bạn và xin vui lòng tiếp tục những bài viết này. Các bạn thật tuyệt vời.

Đọc phần "Thiếu một con đường sự nghiệp lập trình trung tâm" tại trang web này. Công cụ khá tốt và rất phù hợp: http://c2.com/cgi/wiki?ProgrammingIsNotFun

Có thể một người có cả người quản lý tốt và kỹ năng lập trình tốt, mặc dù câu nói "một người tất cả là bậc thầy của không" xuất hiện trong tâm trí ...

Tuy nhiên, kết hợp cả hai chức năng cùng một lúc dường như tôi dễ làm cả hai công việc. Nó phụ thuộc vào số lượng quản lý phải được thực hiện, nhưng chắc chắn bạn đang tung hứng với hai nhiệm vụ có tính chất hoàn toàn khác nhau và sự thay đổi trọng tâm mà nhu cầu này là khá lớn. Tôi nhận thấy rằng tôi thực hiện khá ít trong phần mã hóa khi tôi có một số nhiệm vụ quản lý cũng phải làm (trong trường hợp của tôi, quản lý các khóa học và viết báo cáo).

Một điều đáng tiếc nữa là bạn đang quản lý một nhóm, nhưng bạn cũng là một bên liên quan trực tiếp. Đôi khi điều đó được đền đáp, đôi khi điều đó có thể gây ra những rắc rối lớn. Nếu các lập trình viên khác không đồng ý với công việc của bạn, thì thực tế là bạn là người quản lý có thể khiến họ không hoàn toàn mở.

Sau đó, một lần nữa, khi bạn đang mã hóa trên cùng một dự án mà bạn đang quản lý, bạn sẽ có cảm giác hơn một chút với chính mã đó, vì vậy trong trường hợp đó, bit lập trình thực sự có thể giúp quản lý bit. Mọi thứ phụ thuộc vào những gì bạn phải quản lý, thời gian cần thiết và mức độ liên quan đến mã bạn đang làm việc.

Vì vậy, tôi đoán không có câu trả lời rõ ràng, nhưng tôi có xu hướng tránh trộn lẫn cả hai quá nhiều. 2 xu của tôi

tốt, tôi đã đọc rằng các nhà quản lý của các dự án phần mềm chắc chắn nên là chính các lập trình viên.

Tôi nghĩ rằng một người quản lý là một người quản lý vì một lý do - để quản lý. Tôi sẽ coi đây là quy tắc của ngón tay cái ... một số có thể là con dao hai lưỡi.

Tôi biết một trường hợp nó hoạt động. Người đàn ông này là một người làm việc, vì vậy anh ta làm việc toàn thời gian như một người quản lý, và gần như toàn thời gian như một lập trình viên.

Xem xét giờ làm việc bình thường, tôi không nghĩ rằng vai trò kép như vậy là một ý tưởng tốt. Một lập trình viên quản lý (hoặc người quản lý lập trình) luôn sẵn sàng tự mình làm nhiều công việc lập trình, thay vì bắt các lập trình viên của mình làm việc đó. Luôn có lý do này "mất nhiều thời gian để giải thích hơn là làm" nhưng về lâu dài, công việc lập trình viên 50% mà anh ta làm bị thiếu trong phần quản lý, do đó các lập trình viên khác hoạt động kém hiệu quả hơn.