5 điều tôi không thích về việc làm lập trình viên

Bài viết này được xuất bản ban đầu trên trang .cult của Patrick Zawadzki. .cult là một cộng đồng đặt tại Berlin dành cho các lập trình viên. Chúng tôi viết về mọi thứ liên quan đến sự nghiệp, làm các bộ phim tài liệu gốc và chia sẻ rất nhiều câu chuyện chưa kể từ các lập trình viên trên khắp thế giới.

Phát triển phần mềm như một sự nghiệp đã bùng nổ trong vài năm qua. Với sự phổ biến của các trung tâm đào tạo và sự chuyển động ngang bảng, đây là thời điểm tuyệt vời để tham gia.

Tuy nhiên, sau tất cả sự hào nhoáng và lôi cuốn của kỹ sư phần mềm, có một phía không hề quyến rũ. Và nếu bạn giống như tôi, có lẽ bạn muốn biết sự thật bẩn thỉu trước khi dành thời gian, năng lượng và tiền bạc.

Với bất kỳ công việc nào, đều có những ngày tốt và những ngày tồi. Tôi thích nói rằng nếu bạn thích công việc của mình ít nhất 70% thời gian, bạn đang có một công việc tuyệt vời. Cá nhân tôi, tôi yêu thích lập trình; tôi không thể hạnh phúc hơn, nhưng điều đó không ngăn tôi khỏi việc giải quyết phần còn lại 30%... những ngày tồi, những vấn đề lặp đi lặp lại, những khoảnh khắc đấm qua tường.

Có thể xuất hiện nhiều vấn đề với bất kỳ công việc nào qua thời gian, nhưng với lập trình, có một vài vấn đề lặp lại luôn xuất hiện ở một số giai đoạn trong sự nghiệp của tôi. Vậy nên hãy cùng nói về năm điều tồi tệ nhất khi làm lập trình viên (không theo thứ tự cụ thể).

1. Gặp sự cố debug trong một codebase mà bạn không có kiểm soát trực tiếp

Bugs không phải là điều mà mọi người muốn tìm thấy. Tốt khi bạn làm được, nhưng một bug cuối cùng có nghĩa là ở một nơi nào đó, một bước đã bị bỏ qua hoặc một quy trình đã bị hiểu lầm. Trong ngữ cảnh của những loại bug đó, chúng là tập con tốt nhất trong tất cả các bug vì ít nhất chúng ta có thể kiểm soát chúng. Chúng ta có thể tìm ra chúng trong codebase và sửa chúng. Nhưng còn bug được nhập từ một thư viện hoặc bug được nhập từ một nhà cung cấp bên thứ ba?

Debug các vấn đề mà bạn không thể dễ dàng truy cập có thể coi là một trong những phần khó khăn và frustrate nhất khi làm lập trình viên. Có thể đó là một thư viện bạn đã nhập, nhưng thư viện đã được làm nhỏ hoặc biên dịch làm cho nó không đọc được cho mắt người. May mắn thay, thư viện này là mã nguồn mở... đúng không? Không phải lúc nào cũng vậy, và đó là điều tồi tệ nhất trong danh mục này. Bây giờ bạn cần dành thêm thời gian cô lập vấn đề, trong một hệ thống bên ngoài, một cách có thể tái tạo để bạn có thể gửi vấn đề này cho chủ sở hữu của thư viện đó, hy vọng họ có thể sửa chữa nó theo lịch trình bạn cần.

Những thách thức này được đối mặt bởi nhiều đội hàng ngày và cuối cùng không thể tránh khỏi. Bạn có thể giảm nhẹ những lo ngại này bằng cách lựa chọn giải pháp mã nguồn mở hoặc do chính bạn tạo ra khi lựa chọn cho codebase của bạn. Nhưng nếu không có lựa chọn nào, bạn bị đẩy vào góc và phải chấp nhận thực tế.

2. Bảo trì một dự án cũ, mà không có bất kỳ kiến thức ngữ cảnh nào

Hãy tưởng tượng điều này, bạn là một người sống sót đã được đào tạo và có kinh nghiệm quyết định tham gia một chương trình truyền hình giống như Alone với một số thay đổi. Bạn đã làm điều này hàng ngàn giờ, bạn là một chuyên gia trong lĩnh vực bạn làm, và đã có một lịch sử thành công được chứng minh. Đây là điều thay đổi, mùa này, bạn được chọn ngẫu nhiên và thả xuống một khu vực hoàn toàn không quen biết.

Để trở thành người sống sót thành công, bạn cần biết bạn đang đi đâu, đó là như thế nào, và có thể thậm chí là một số phương pháp để đạt được thành công. Bạn cần biết tại sao bạn mang theo một số mục nhất định, cách chúng có thể hữu ích, và có thể thậm chí là nói chuyện với một số đồng đội sống sót đã trải qua môi trường như thế trước đây. Cái gì đã hoạt động, cái gì không hoạt động, và có thể thậm chí là một số mánh khéo léo đặc trưng về môi trường này. Nhưng không, mùa này của "Alone+" sẽ thử nghiệm kỹ năng của bạn đến tận cùng.

Việc làm lập trình viên rơi vào một dự án mới, mà không có bất kỳ ngữ cảnh nào hoặc không có ai mà bạn có thể đặt câu hỏi cũng khá giống như điều này. Điều về phần mềm là có nhiều cách tiếp cận một vấn đề duy nhất và đôi khi con đường quyết định của ai đó để chọn cách tiếp cận của họ là hệ thống và được thảo luận sâu sắc.

Tham gia một dự án mà không có bất kỳ ngữ cảnh hoặc người bạn có thể đặt câu hỏi có nghĩa là bạn có thể gặp những điều lạ lẫm và gặp khó khăn để hiểu tại sao chúng ở đó. Có phải là một lập trình viên lười biếng? Có phải là một giải pháp tạm thời hoặc một phương pháp mà họ cần thực hiện để hoàn thành một deadline? Có phải do một ràng buộc bên ngoại buộc mã nguồn phải được thiết kế theo cách này không? Không thể nói, nó đơn giản là mất trong hư vô. Sự thay đổi trong tất cả điều này là bạn vẫn cần phải học cách thành công trong môi trường này vì thành công của bạn làm lập trình viên phụ thuộc vào nó.

Những loại dự án này có thể, không may, đẩy nhiều lập trình viên đến giới hạn và làm cho một số người ghét công việc của họ. Những dự án này khởi đầu chậm và dường như như cố gắng điều hướng mù quáng trong một chiến trường mìn. Điều này làm tại sao việc viết mã được viết tốt và mã có tài liệu cập nhật là rất quan trọng.

Nếu bạn đang đọc điều này, bạn có lẽ là một lập trình viên hoặc đang muốn trở thành một. Hãy cố gắng là người ghi chú về những điều kỳ lạ này trong codebase của bạn để người tiếp theo tương tác với nó sẽ dễ dàng hơn khi ghép những thứ lại với nhau, cho dù bạn có ở đó để trả lời câu hỏi hay không.

3. Khi những người KHÔNG hiểu về phát triển phần mềm đưa ra quyết định

Một đội ngũ phần mềm điển hình bao gồm các nhà phát triển phần mềm, một quản lý dự án và một loại chủ sở hữu sản phẩm. Có thể quản lý dự án và chủ sở hữu sản phẩm là cùng một người, nhưng cuối cùng có người viết code và có người có tầm nhìn về những gì họ muốn sản phẩm trở thành. Trong hầu hết các tình huống, người có tầm nhìn là người chủ tri cuộc họp với bên liên quan, thiết lập các khung thời gian, và cuối cùng "bán" sản phẩm cho người khác.

Mối quan hệ giữa loại người này và lập trình viên là khá quan trọng đối với sự thành công của dự án và đôi khi là niềm vui của lập trình viên trong một nhóm. Quá thường xuyên, lập trình viên được xem như "đồng dạng mã" trên dự án và yêu cầu đơn giản được đẩy xuống họ mà không có nhiều cuộc thảo luận, và đôi khi với hạn chế thời gian không thực tế. Điều này dẫn đến sản phẩm vội vã, kỳ vọng không đạt được, và cuối cùng là một sản phẩm thất bại vì nó không thực hiện điều mà doanh nghiệp đã nghĩ trong đầu và liên tục gặp sự cố.

Với một lập trình viên, việc tìm kiếm một đội có mối quan hệ làm việc cân đối giữa quản lý dự án/chủ sở hữu sản phẩm là quan trọng không chỉ đối với sự thành công của một sản phẩm, mà còn là niềm vui của lập trình viên trong vai trò của họ.

4. Không có đủ thời gian liên tục trong ngày của bạn

Có rất nhiều nhiệm vụ tuyệt vời bao quát vai trò của lập trình viên, và hầu hết lập trình viên thường trân trọng những phần này trong công việc hàng ngày của họ. Khả năng tạo ra một tầm nhìn và biến nó thành hiện thực trong vài phút là một trong những phần hấp dẫn nhất của việc làm lập trình viên.

Một phần khác thực sự tuyệt vời có thể được mô tả là “dòng chảy”. Đó là cảm giác gần như hoàn toàn chìm đắm mà người ta trải qua khi đào sâu vào công việc và quá trình tư duy của họ. Đó là một phần rất phổ biến của việc đạt được một cấp độ sáng tạo và tiến triển sâu và là một phần của lập trình mà nhiều lập trình viên cần để hiệu quả.

Trong thế giới làm việc hiện đại, tuy nhiên, việc thường xuyên được thêm vào các cuộc họp hoặc nhận tin nhắn không đồng bộ với câu hỏi/quan ngại trong suốt ngày là điều dễ dàng. Điều ngẫu nhiên về “dòng chảy” là nó có thể khó khăn để bắt đầu, nhưng dễ dàng bị đánh bại.

Ngoài ra, phát triển phần mềm là một loại công việc có tính cá nhân cao, trong ý nghĩa là bạn là người đóng góp cá nhân được giao nhiệm vụ và vấn đề và mong đợi hoàn thành chúng. Với việc liên lạc không đồng bộ liên tục và các cuộc họp liên tiếp, việc tìm đủ thời gian để bắt đầu dòng chảy và duy trì nó đủ lâu để hoàn thành nhiệm vụ là thách thức. Chìa khóa ở đây là một khoảng thời gian "không bị gián đoạn" trong ngày của bạn, vì ngay cả việc chuyển đổi ngữ cảnh để thực hiện các nhiệm vụ nhỏ trong suốt ngày cũng làm kiệt sức.

Tìm ra khoảng thời gian không bị gián đoạn, có lẽ 3-4 giờ là lý tưởng nơi bạn có thể hoàn toàn chìm đắm vào không gian của mình và tập trung vào công việc là rất quan trọng. Những ngày đầy cuộc họp hoặc, điều tồi tệ hơn nữa, cuộc họp cách nhau 30-45 phút làm tổn thương sự hiệu quả và năng suất của nhiều lập trình viên trên toàn thế giới.

5. Hội chứng giả mạo

Đối với nhiều lập trình viên trên toàn thế giới, không may mắn khi nói rằng sớm muộn gì họ sẽ trải qua một mức độ nào đó của hội chứng giả mạo trong sự nghiệp của họ. Có thể là bắt đầu một dự án mới, tham gia một nhóm mới, hoặc chỉ đơn giản là một sự kết hợp đột ngột của những cảm xúc xấu trong một ngày làm cho sự tự nghi ngờ xâm nhập vào quyết định của bạn và ảnh hưởng đến những lựa chọn bạn đưa ra suốt cả ngày.

Theo từ điển Merriam Webster, hội chứng giả mạo được định nghĩa như sau:

... một trạng thái tâm lý được đặc trưng bởi sự nghi ngờ kiên trì về khả năng hoặc thành tựu cá nhân kèm theo nỗi sợ bị phát hiện là một kẻ lừa dối mặc dù có bằng chứng về sự thành công liên tục.

Đây là một tình huống khá phản sản và nghịch lý mà nhiều người vẫn cố gắng vượt qua. Một số người trải qua nó thường xuyên và một số không bao giờ. Một số người trải qua nó thường xuyên hơn họ mong đợi. Dù sao, điều tuyệt vời ở cộng đồng phần mềm là nhiều người đã trải qua nó ở mức độ nào đó tại một giai đoạn nào đó trong sự nghiệp của họ và nhiều người sẵn sàng giúp đỡ.

Tóm tắt

Kỹ thuật phần mềm là một lĩnh vực tuyệt vời với nhiều lợi ích đối với nhiều người và đó là một lĩnh vực thú vị với cơ hội dường như không ngừng. Tuy nhiên, mọi lĩnh vực và sự nghiệp đều có những ưu và nhược điểm của mình. Hầu hết thời gian mọi người chỉ nói về ưu điểm của một sự nghiệp nhưng hiếm khi nói về nhược điểm, hãy thật trung thực, đôi khi nhược điểm có thể lớn hơn ưu điểm. Và nhược điểm đối với một số người có thể không phải là nhược điểm đối với người khác.

Bất kể tình hình của bạn là gì, tôi hy vọng việc nhìn thấy một số khía cạnh tiêu cực từ một nhà phát triển phần mềm có thể giúp mang lại cái nhìn cho bất kỳ ai đang nghĩ đến tham gia lĩnh vực này và bất kỳ ai mới bắt đầu trong lĩnh vực. Điều này không phải là để làm sợ ai đó—chỉ là một chút ánh sáng chiếu vào những góc tối không thường chia sẻ. Cuối cùng, việc nhận thức về những vấn đề và những điều có thể ảnh hưởng đến bạn thường hay hơn là không nhận thức.