Có phải công việc bảo trì chuyên dụng cản trở sự nghiệp của lập trình viên? [đóng cửa]

Phần lớn công việc của tôi trong ba năm qua chủ yếu là về việc duy trì các hệ thống kế thừa cần vá hoặc sửa chữa thường xuyên trước khi được bán lại.

Tôi hiểu vai trò quan trọng của các lập trình viên bảo trì chuyên dụng phải đóng trong các công ty có số lượng lớn các dự án và các nhà phát triển hạn chế trong tay.

Nhưng khi tôi đánh giá sự tiến bộ nghề nghiệp hiện tại của tôi và nhìn vào các đồng nghiệp của tôi; nhà thầu và nhà phát triển doanh nghiệp như nhau; Tôi cảm thấy như thể tôi bị tụt lại rất xa vì tôi đã đạt được rất nhiều về bề rộng về các lĩnh vực tôi đã chạm tới nhưng không có nhiều chiều sâu. Tôi đã bắt đầu giải quyết vấn đề này bằng cách bắt đầu một blog, làm việc trên các dự án git-hub nhỏ của riêng tôi và sắp xếp lại cuộc sống của tôi để có thời gian làm mã hóa cá nhân sau khi làm việc một cách thường xuyên.

Tôi cảm thấy rằng tôi đã phỏng vấn tại các công ty khác để thoát khỏi công việc bảo trì, tôi sẽ phải thể hiện mình là một người khá kém về trình độ kỹ năng vì tôi sẽ không có kiến ​​thức chuyên sâu về một người có ba năm kinh nghiệm tập trung vào một người cụ thể con đường phát triển tính năng sẽ. Vì vậy, một nửa kinh nghiệm làm việc hiện tại của tôi sẽ được tính là không lâu dài.

Nhưng điều này dẫn tôi đến những câu hỏi chính của tôi, lời xin lỗi nếu điều này cảm thấy quá tập trung vào tình huống khó xử cá nhân của tôi ,:

Các vai trò lập trình bảo trì chuyên dụng cuối cùng có gây bất lợi cho sự nghiệp sớm không? Các lập trình viên khác có quyền tránh các vai trò như thế này không? Việc thực hiện công việc này có khóa bạn trong việc thực hiện các nhiệm vụ tương tự trừ khi bạn chuẩn bị bắt đầu lại như một thiếu niên?

Các vai trò lập trình bảo trì chuyên dụng cuối cùng có gây bất lợi cho sự nghiệp sớm không? Các lập trình viên khác có quyền tránh các vai trò như thế này không? Việc thực hiện công việc này có khóa bạn trong việc thực hiện các nhiệm vụ tương tự trừ khi bạn chuẩn bị bắt đầu lại như một thiếu niên?

Trước tiên, bạn nên biết rằng bạn được coi là một thiếu niên trong một thời gian khá lâu. Bạn có thể nhận được các chương trình khuyến mãi tùy ý vì bạn tốt và đây là cách duy nhất để cung cấp cho bạn một khoản lương xứng đáng, nhưng bạn vẫn sẽ được coi là một thiếu niên khi bạn tiếp tục công việc tiếp theo.

Thứ hai, nếu tôi thuê một người có kinh nghiệm 2-4 năm, tôi không thực sự quan tâm liệu công việc của họ có hoàn toàn là bảo trì hay không. Nếu bạn đã dành 10 năm để bảo trì và tôi đang thuê một dự án trên cánh đồng xanh, tôi có thể có câu hỏi, nhưng trong vài năm đầu tiên, tôi thực sự mong đợi điều đó.

Mặt khác, nếu tôi thuê một người KHÔNG BAO GIỜ làm việc bảo trì, tôi sẽ nghi ngờ hơn. Tôi đã có nhiều ứng cử viên cho các công việc đã trải qua 4 năm đầu tiên của họ từ một công việc "tốt" này đến một công việc khác và mọi người đều không biết gì về những gì tạo ra mã duy trì. Và, đừng nhầm lẫn, nếu tôi đang thuê một dự án trên cánh đồng xanh mà tôi dự định sẽ gắn bó, tôi không quan tâm liệu BẠN có duy trì mã hay không, tôi quan tâm rằng bạn biết làm thế nào để duy trì nó cho các nhà phát triển trong tương lai.

Những lập trình viên khác mà bạn đề cập, những người tránh những công việc như thế này, thường tránh họ vì họ ít vui chứ không phải vì nó cản trở sự nghiệp của họ.

Cuối cùng, bạn nên biết rằng một tỷ lệ rất lớn (tôi sẽ đoán một cách dè dặt khoảng 80%) các công việc phát triển phần mềm là hơn 50% bảo trì.

Vì vậy, để vượt qua tất cả những điều đó và trả lời câu hỏi của bạn: Không, tôi không nghĩ nó sẽ cản trở sự nghiệp của bạn. Trừ khi bạn ở đó quá lâu. Nguyên tắc chung là "một khi bạn bắt đầu cảm thấy như bạn nhận được cùng một năm kinh nghiệm mỗi năm, đó là lúc để đi." Nếu bạn cảm thấy, mỗi năm, giống như bạn là một nhà phát triển tốt hơn bạn năm ngoái, bạn vẫn ổn (và điều đó đối với tôi, 20 năm trong sự nghiệp của tôi, cũng như bạn).

Trong bất kỳ công việc nào, kinh nghiệm bạn nhận được là cụ thể cho những gì bạn đang làm, điều này giới hạn phạm vi khả năng của bạn khi áp dụng cho các công việc khác dựa trên kinh nghiệm đó. Nó không cụ thể để bảo trì. Tôi nghĩ các câu hỏi khác có liên quan nhiều hơn là việc bảo trì hay phát triển phần mềm mới:

• Làm thế nào rộng rãi là các công nghệ cụ thể mà bạn đang làm việc với? Nếu bạn đang duy trì thứ gì đó lỗi thời và hiếm khi được sử dụng ở nơi khác, thì điều đó sẽ hạn chế cơ hội nghề nghiệp trong tương lai của bạn (nhưng cũng sẽ phát triển phần mềm mới cho hệ thống / nền tảng / công nghệ không được sử dụng rộng rãi).
• Làm thế nào để công việc hiện tại của bạn trang bị cho bạn cho công việc bạn muốn làm trong tương lai? Công việc bảo trì, như bạn đã chỉ ra, rất quan trọng và sẽ luôn ở bên. Không có gì sai khi có một sự nghiệp tập trung vào loại lập trình này; sẽ luôn có rất nhiều khả năng cho các nhà bảo trì hệ thống. Nhưng có lẽ nó không phải là những gì bạn muốn làm. Đó là một mối quan tâm nếu công việc hiện tại của bạn không chuẩn bị cho bạn những gì bạn quan tâm.

Tuy nhiên, tôi sẽ không quá lo lắng. Một điều bạn nói là:

Tôi đã đạt được rất nhiều chiều rộng về các lĩnh vực tôi đã chạm tới nhưng không có nhiều chiều sâu.

Đừng nghĩ đây là một vấn đề, bởi vì nó có thể được sử dụng để lợi thế của bạn. Có kinh nghiệm rộng có nghĩa là có rất nhiều điều mà bạn có thể nói "vâng, tôi đã làm điều đó". Rất nhiều công việc yêu cầu kinh nghiệm trong một số công nghệ và nhiệm vụ khác nhau. Bạn có thể có lợi thế hơn một nhà phát triển có kinh nghiệm rất sâu về một công nghệ.

Hơn nữa, rất nhiều công việc liên quan đến một hỗn hợp của bảo trì và phát triển mới. Nếu bạn muốn thực hiện thêm phát triển mới, bạn có thể sử dụng kinh nghiệm bảo trì hiện tại của mình để chuyển sang vai trò hỗn hợp sẽ cung cấp cho bạn nhiều kinh nghiệm phát triển hơn.

Tóm lại, sơ yếu lý lịch của bạn có lẽ tốt hơn bạn nghĩ. Rất nhiều điều sẽ được đưa ra để bạn phân tích những điểm mạnh của trải nghiệm của mình như thế nào, và sau đó truyền đạt những điểm mạnh đó trong quá trình nộp đơn và phỏng vấn.

Các vai trò lập trình bảo trì chuyên dụng cuối cùng có gây bất lợi cho sự nghiệp sớm không?

Thường xuyên hơn không - CÓ, giả sử:

• rằng sự nghiệp ở đây có nghĩa chuyên môn trong nhiều kỹ năng chuyên môn khác nhau.
• rằng bạn dành hơn X năm ở đó, trong đó X đủ để "thiết lập" cách suy nghĩ của bạn.
• rằng bạn không làm bất cứ điều gì sang một bên.
• rằng "người bảo trì chuyên dụng" (xem EDIT, bên dưới) có nghĩa là bạn không mã để duy trì cũng như mã hóa những thứ mới, nhưng bạn hầu như luôn luôn mã để duy trì hoặc thậm chí làm việc trên một dự án trong chế độ bảo trì - không có tính năng mới, ít nhất là bắt buộc thay đổi mã để sửa lỗi.

Điều này không có nghĩa là luôn luôn như vậy.

Những người duy trì phần mềm hiếm khi được khuyến khích (xem EDIT, bên dưới) để nghiên cứu, hiếm khi có thể cắm vào thư viện mới hoặc DB và dành vài ngày để tìm hiểu cách thức hoạt động của nó. Đó (thường) là một công việc ổn định đòi hỏi những thay đổi tối thiểu đối với cơ sở mã hiện có và do đó "định hình" cách bạn tiếp cận vấn đề sau này. Tôi có thể kể tên khá nhiều công ty có chính sách duy trì phần mềm tuyên bố rõ ràng "ít thay đổi trong mã = ​​tốt hơn", mặc dù những điều tồi tệ này có thể mang lại.

Các lập trình viên khác có quyền tránh các vai trò như thế này không?

Tôi biết những người bảo trì rất giỏi, những người thích công việc của họ và sẽ không muốn xin việc khác một cách chính xác bởi vì họ cảm thấy thoải mái khi ở đó. Không phải ai cũng thích học những điều mới mọi lúc mọi nơi. Vì vậy - tránh hoặc tìm kiếm nó tùy thuộc vào sở thích của bạn.

Việc thực hiện công việc này có khóa bạn trong việc thực hiện các nhiệm vụ tương tự trừ khi bạn chuẩn bị bắt đầu lại như một thiếu niên?

Thường xuyên hơn không - CÓ. Bởi vì bạn đã có kinh nghiệm làm việc đó, vì bạn đã "biết những sợi dây" v.v ... Nhưng sự thay đổi là hoàn toàn có thể và có thể xảy ra mà không cần ứng tuyển vào vị trí cấp dưới. Bạn đã bắt đầu làm mọi thứ sang một bên, giữ nó! Điều đó thực sự rất đáng giá và có thể thu hẹp 'khoảng cách kỹ năng' mà bạn nhận thấy.

EDIT: Dan đã chỉ ra (rất đúng), rằng các nhiệm vụ bảo trì thường có thể được thực hiện VỚI nghiên cứu. Điều đó đúng. Tôi đã thay đổi câu trả lời ở hai nơi để giải quyết vấn đề này tốt hơn.

Những nhiệm vụ như vậy chắc chắn COULD được thực hiện theo cách này và nếu chúng là - tuyệt vời! Tuy nhiên, hầu hết các nhà bảo trì hệ thống LEGACY của AFAIK đều có các chính sách hoặc kỳ vọng quản lý và thời hạn - một lần nữa, thường xuyên hơn - không buộc họ phải giải quyết vấn đề với ít thay đổi nhất có thể. Thường thì áp lực đủ cao đến mức ngay cả khi bạn có thể làm theo cách này, bạn có thể không muốn. Đặc biệt nếu đó không phải là mã CỦA BẠN: không có lý thuyết (theo Ryle và Naur) đằng sau nó, bạn có nguy cơ làm hỏng nhiều hơn bạn sửa.

Tuy nhiên, cần lưu ý: Tôi không có dữ liệu toàn cầu cứng, tôi nói từ kinh nghiệm của chính mình - Tôi đã làm việc trong một tình huống như OP, tôi đã tuyển dụng những người có 4 - 10 năm kinh nghiệm làm người bảo trì, tôi đã nói chuyện với nhiều người bảo trì và tôi biết những người làm việc như những người duy trì tận tâm . Không chỉ những người viết mã mới mà còn mã để duy trì dự án - những người bảo trì chuyên dụng, công việc duy nhất của họ là sửa lỗi và vá lỗi và thậm chí không phải là một tính năng mới, bởi vì đó là dự án cũ và giờ chỉ ở "chế độ bảo trì".

Tôi sẽ phải thể hiện mình là một người khá kém về trình độ kỹ năng vì tôi sẽ không có kiến ​​thức chuyên sâu về một người có ba năm kinh nghiệm tập trung vào một con đường cụ thể trong phát triển tính năng

Chính xác. Bạn sẽ không thể nói "3 năm kinh nghiệm thiết kế hệ thống từ đầu bằng X, Y và Z", bạn phải nói "3 năm kinh nghiệm hệ thống MAINTAINING từ đầu bằng X, Y và Z" trừ khi bạn muốn nằm ngay trên CV của bạn.

Tôi cảm thấy rằng tôi đã phỏng vấn tại các công ty khác để thoát khỏi công việc bảo trì, tôi sẽ phải thể hiện mình là một người khá kém về trình độ kỹ năng vì tôi sẽ không có kiến ​​thức chuyên sâu về một người có ba năm kinh nghiệm tập trung vào một người cụ thể con đường phát triển tính năng sẽ

Nếu bạn muốn nói "Tôi thiết kế và xây dựng các hệ thống từ đầu" thì có, bạn sẽ phải tự học lớp mình.

Điều khá phổ biến trong CNTT, (và tôi không nói đây là những gì bạn đang làm) là để mọi người cho rằng vì họ đã làm việc được X năm, họ có kinh nghiệm X năm và sau {số năm không xác định} họ nên được coi là nhà phát triển Senior {Widget}.

Bây giờ, đừng hiểu sai ý tôi, không có gì sai với công việc bảo trì, mọi người phải làm điều này lúc này hay lúc khác, nhưng điều bạn nhận ra là việc bị mắc kẹt làm điều đó quá lâu có thể sẽ khiến bạn khó thực hiện thoát khỏi vai trò đó trong tương lai. Điều này thường đi đôi với việc bị "mắc kẹt" khi không học các công nghệ / công cụ / phương pháp mới hơn.

Lý tưởng nhất, bạn muốn kết hợp công việc hệ thống "mới" và công việc kế thừa.

Một lưu ý tích cực, có lẽ bạn đã thấy rất nhiều kiến ​​trúc khác nhau (tốt và xấu), cách tiếp cận khác nhau, làm thế nào các quyết định tồi tệ có thể làm cho các lập trình viên kế thừa làm việc chăm chỉ hơn sau này. Đây là tất cả các tích cực hơn có thể được nhấn mạnh.

Chúc may mắn!

Nhìn vào điều này từ một góc độ khác, tôi nghĩ rằng bán mình như một chuyên gia bảo trì là một cơ hội thị trường.

Là chủ sở hữu của một công ty phần mềm có nhiều dự án đang hoạt động, một trong những rủi ro lớn nhất tôi phải giảm thiểu là các nhà phát triển nhảy tàu và bảo trì mã của họ sau đó.

Vì vậy, giả sử bạn có khả năng phát triển đam mê công việc bảo trì (mà tôi đoán là trường hợp kể từ khi bạn chuẩn bị viết blog về trải nghiệm của mình), nếu bạn đến với tôi cung cấp dịch vụ của bạn như một chuyên gia bảo trì - đảm bảo sẽ đánh bóng tất cả trong số các dự án khác nhau của các nhà phát triển của tôi bằng cách tái cấu trúc, tối ưu hóa và ghi lại mã của họ để duy trì lâu dài - và bạn đã có một hồ sơ theo dõi để sao lưu bảo lãnh của mình, tôi sẽ thuê bạn trong nháy mắt.

Lời khuyên của tôi sẽ là thử một cách thích hợp. Định vị bản thân như một chuyên gia bảo trì và trau dồi blog của bạn. Bạn có thể đang ở một cái gì đó.