Coding nhàm chán, trừ khi...

Là một lập trình viên trẻ, bạn có đam mê, bạn có nhiệt huyết, sẵn sàng xông pha nhiều dự án, học hỏi nhiều thứ ngôn ngữ, nhiều mảng lập trình thú vị khác nhau, bạn thích vọc vạch làm web, bạn thích có một ứng dụng mobile, và tất nhiên bạn cũng mong muốn mình có thể trở thành một chàng hacker tài năng như trong phim Mỹ. Vâng có bao giờ đó đã là ước mơ của bạn ? anh chàng, cô nàng lập trình viên mới vừa ra trường, luôn tràn trề năng lượng, muốn cống hiến và đạt được ước mơ? Và rồi,

...

Sao bao lâu kể từ ngày bạn tham gia những dự án, viết những ứng dụng cho công ty bạn, để bạn bắt đầu cảm thấy đường đi thật dài, quá nhiều cản trở, đam mê ngày nào giờ đây bị những deadline chèn ép, những dòng code hối hả, không còn cảm xúc, bạn nhận thấy rằng công việc hiện tại làm mình bắt đầu cảm thấy chán? Bạn muốn tìm kiếm lại cảm xúc, mơ ước ngày nào, bạn quyết định chuyển công ty, HR, PM cố gắng thuyết phục bạn, nhưng bạn đã thực sự chán công việc hiện tại, bạn nhận ra mình không thể ở lại và ra đi tìm phương trời mới là cách tốt nhất. Hãy suy ngẫm cùng nhau phân tích để xem đâu là nguyên nhân gây ra cảm giác chán nản trong bạn, xem bạn là ai trong bài phân tích hay của tác giả @kiendinang về Tại sao nhân viên bỏ việc nhé (Just kidding!).

OK, bỏ qua phần dài dòng, chúng ta hãy cùng Bruno Marnette CTO của Enki phân tích đâu là nguyên nhân và giải pháp khác phục việc nhàm chán trong công việc của bạn.

“boredom” doesn’t feel like an urgent concern. But it never does at the start. Instead, boredom tends to creep in with time, and hit you at the worst possible moment.

"nhàm chán" không cảm thấy như một thứ gì đó khẩn cấp. Nhưng nó không bao giờ có ngay từ lúc bắt đầu. Thay vào đó, sự nhàm chán có xu hướng biến mất theo thời gian, và đánh bạn vào thời điểm tồi tệ nhất có thể.

Đây là lý do tại sao chúng ta cần giải quyết vấn đề này sớm, bằng cách xây dựng một nền văn hoá (culture), thứ mà sẽ cứu chúng ta khỏi sự nhàm chán trong công việc.

Too Long; Didn’t Learn

Nguyên nhân phổ biến và rõ ràng nhất gây chán cho các developer là một dự án kéo dài quá lâu.

Tôi đã có kinh nghiệm đầu tay trong công việc đầu tiên của tôi. Nhóm của tôi chuẩn bị và phục vụ dữ liệu tài chính thông qua một API thuận tiện. Ban đầu thật sự thú vị vì sự phức tạp và quy mô của dữ liệu. Tôi đã học về phân tích dữ liệu hiệu năng cao và thiết kế API. Nhưng sau một năm, chúng tôi vẫn đang làm việc với cùng số liệu giống hệt nhau, cùng với các công nghệ tương tự. Tôi đã trở thành một chuyên gia về một cái gì đó quá cụ thể. Không có gì mới mẻ cho tôi để học.

Tôi không thể thay đổi team hoặc dự án vì lẽ hợp lý, công ty muốn tôi tiếp tục tại nơi mà tôi bắt đầu. Tôi biết quá nhiều dữ liệu và công nghệ để có thể được thay thế (vị trí hiện tại trong dự án). Tôi không thể biện minh cho việc thay đổi công nghệ chỉ để học cái mới. Tôi bày tỏ sự nhàm chán và thất vọng của mình, nhưng vấn đề không được giải quyết, vì vậy tôi phải tiếp tục.

Làm thế nào để ngăn chặn cảm giác đó ?

Trong nhóm, chúng tôi luôn cố gắng và ngăn mọi người làm việc cùng những đoạn code, sản phẩm hoặc dữ liệu giống nhau trong hơn ba tháng. Giai đoạn này có thể tùy ý và có lẽ là quá ngắn cho những công ty lớn hơn. Nhưng chúng tôi thường tin tưởng vào việc sự xoay vòng nhanh này.

Để làm điều này có thể, chúng tôi thúc tiến một nền văn hóa full-stack. Mỗi developer trong team có thể làm việc trên bất kỳ phần nào của code base (hoặc có thể nhanh chóng tìm hiểu chúng).

Một yếu tố khác để phòng ngừa là việc thảo luận về những điều này một cách liên tục. Chúng tôi có cuộc thảo luận trực tiếp, cởi mở, một--một trong mỗi tuần. Nếu một thành viên bắt đầu cảm thấy quá thoải mái hoặc quá chuyên biệt, đó là thời điểm thích hợp để xoay vòng.

Maintaining legacy code is boring

Bạn có thể biết khi nào dự án đang ở chế độ bảo trì - chính thức hay không - đó là khi các developer dành 90% thời gian fix bug thay vì phát triển các tính năng mới.

Một số người sẽ nói rằng bảo trì là điều không thể tránh khỏi. Code cũ cần được hỗ trợ. Xây dựng phần mềm cũng giống như xây dựng một ngôi nhà. Bạn cần phải bảo trì ngôi nhà đã cũ và sửa chữa chúng theo thời gian, đúng chứ?

Câu trả lời là Có và không. Vấn đề thường gặp ở đây là vấn đề thái độ.

Tôi từng có một người mentor, anh ấy đã hoài nghi về điều này. Anh ấy đảm bảo rằng không có gì có thể hoàn thành được. Đó là cách phát triển phần mềm hoạt động. Life sucks, get used to it

Làm thế nào để giảm thiểu điều này ?

Maintenance đôi khi là kết quả của các quyết định kỹ thuật kém, kết hợp với sự thiếu can đảm.

Khối code base lớn cùng với những mối quan hệ phức tạp đòi hỏi thêm nhiều công sức để bảo trì. Ngược lại, nếu cơ sở hạ tầng micro-service có kiến trúc tốt hơn sẽ linh hoạt hơn. Khi một micro-service bị lỗi, bạn có thể thay thế nó. Bạn có thể viết lại nó từ đầu, sử dụng một ngôn ngữ hoặc công nghệ khác. Bằng cách này, bạn học được cái gì đó mới thay vì phải fix bug đống code được thừa kế. Và nếu kiến trúc của bạn không cho phép điều này, bạn có thể thực hiện các bước để cải thiện nó, và học một số kỹ năng DevOps trong quá trình hoàn thành nó.

Chiến lược micro-service chỉ là một trong số những cách khác nhau có thể tiếp cận vấn đề của việc "nhàm chán" lúc maintainance. Một vài nơi, họ xây dựng các tools thông minh để làm cho việc bảo trì trở nên thú vị và hiệu quả hơn. Một ví dụ điển hình đó là những gì Facebook đã làm với đống code base bằng PHP đồ sộ của họ. Họ xây dựng trình biên dịch riêng và ngôn ngữ đánh máy riêng (Hack) dựa trên PHP, để vừa tạo điều kiện bảo trì vừa nâng cao kinh nghiệm cho developer.

Tôi nghi ngờ việc nó đã không thể "giải quyết" các vấn đề kế thừa một cách hoàn toàn, nhưng chắc chắn rằng nó làm cho công việc có âm sắc thú vị hơn.

Copy/pasting is boring

There is coding, and then there is coding.

Trước đây, tôi đã từng viết script Groovy và Python để tích hợp dữ liệu. Dữ liệu phức tạp, với hàng chục lược đồ không nhất quán, không cho phép tự động hóa nhiều. Vì vậy tôi phải viết rất nhiều code, và các đồng nghiệp của tôi cho rằng tôi đã học được rất nhiều.

Nhưng không phải vậy. Tại sao?

Bởi vì 50% code của tôi (hơi cường điệu tý!) là copy/paste trực tiếp từ Stack Overflow. Và 40% khác là copy/paste từ các script khác, hoặc là các script của đồng nghiệp hoặc của riêng tôi. Nó lặp đi lặp lại. Và sự thật có rất ít sự sáng tạo hoặc học tập liên quan trong này.

Chúng ta làm gì để cố gắng giảm thiểu điều này ?

Là một nhóm, chúng tôi chú ý đến code được viết bởi những người khác. Chúng tôi làm điều đó trong quá trình code reviews, syncs và retrospectives. Nếu ai đó dành một tuần để viết những dòng code không quá sáng tạo, chúng tôi phải cố gắng hiểu tại sao.

Đôi khi, gốc rễ của vấn đề là kỹ thuật. Chúng tôi có thể đang làm nhiều script hoặc cấu hình công việc nhiều hơn chúng tôi nên làm. Trong trường hợp này, chúng tôi thêm nhiều phần tự động hóa hơn. Lần khác, chúng tôi đã copy/paste vì một lý do nào đó. Trong trường hợp này, chúng tôi cố gắng chia sẻ tải trọng của công việc nhàm chán để hoàn thành nó.

Internal tools are usually boring

Là những developer, chúng ta muốn tạo ra các công cụ nội bộ tuỳ chỉnh để giải quyết các vấn đề cụ thể, bởi vì việc tạo ra những thứ mới mẻ thật thú vị. Ngoài ra, xây dựng các giải pháp phù hợp thường cảm thấy trong sáng hơn là sửa lại cái hiện có. Nhưng học một công cụ độc quyền là khoảng 10 lần kém thú vị hơn so với học một công nghệ mã nguồn mở phổ biến.

Tại sao?

Bởi vì bạn không thể nói chuyện với bạn bè về nó (internal tools), bạn không thể khoe khoang về việc biết nó, bạn không thể đọc về nó trên Hacker News, bạn không thể sử dụng nó trong hackathons, bạn không thể sử dụng nó trong dự án riêng của bạn. Tuy nhiên, rất nhiều công ty rơi vào bẫy của việc tạo ra những thứ không đáng để rồi tạo ra sự nhàm chán. Nói cách khác: họ giải quyết một sự thất vọng ngắn hạn chỉ để gây ra nhiều nỗi thất vọng dài hạn. Tôi đã thấy điều này trước mắt trong một công việc trước đây. Tôi đã bị hạn chế là phải sử dụng DSL do công ty phát triển để tích hợp dữ liệu quy mô lớn. Tất cả những gì tôi học được là một thuật ngữ SQL-like-ish (giống SQL) khác. Tôi có thể sẽ thích sử dụng và học một công nghệ mã nguồn mở cấp thấp như Spark hơn. Tôi sẽ bận rộn hơn gấp 10 lần, và ngay cả khi code của tôi đã được rườm rà gấp đôi, nhưng nó sẽ vẫn tạo cho tôi 5 lần hiệu quả hơn.

Loại văn hoá nào có thể ngăn ngừa điều này ?

Chúng tôi cố gắng giữ một sự thiên vị mạnh mẽ cho các công nghệ mã nguồn mở. Nếu chúng tôi có thể sử dụng lại một cái gì đó có liên quan và thú vị, chúng tôi làm điều đó. Chúng tôi không tránh khỏi những rắc rối. Chúng tôi vứt bỏ code tùy chỉnh của chúng tôi ngay khi một công nghệ mã nguồn mở trở nên đủ chín chắn để thay thế nó. Và khi code tùy chỉnh của chúng tôi trở nên đủ chung chung, chúng tôi sẽ biến nó thành mã nguồn mở.

Thỉnh thoảng chúng tôi mắc sai lầm. Ví dụ: chúng tôi đã sử dụng thư viện agenda.js trong một thời gian để schedule cho backend jobs bởi vì nó cảm thấy hiện đại và thú vị. Nhưng nó trở nên phức tạp hơn mọi thứ, vì vậy chúng tôi chuyển về một công nghệ cũ hơn, đáng tin cậy hơn. Tuy nhiên, chúng tôi không hối hận khi thử nghiệm nó, bởi vì đó là một kinh nghiệm học tập có giá trị.

Being a code-monkey is boring

Một nguyên nhân phổ biến khác gây ra sự nhàm chán của developer là việc quản lý người tệ hại. Cụ thể hơn: từ trên xuống, là việc quản lý một cách độc tài.

Người giám sát (supervisor) với những ý định cao quý, đôi khi có thể sử dụng kiểu quản lý này mà không hề nhận ra nó. Đặc biệt là khi một dự án không tiến triển tốt, hoặc deadline cận kề. Dưới áp lực, một phản xạ tự nhiên chỉ vì mục đích tiết kiệm thời gian và hoàn thành mọi việc, họ bỏ đi các phép thử, cố gắng và cắt ngắn các cuộc thảo luận, giảm thiểu động não, và nói cho mọi người biết chính xác những gì cần làm mà không hề có tranh luận hoặc giải thích.

Người bị giám sát hiểu biết sẽ không nhất thiết phải bối rối bởi điều này, trên thực tế, một số người sẽ (đôi khi) đánh giá cao sự đơn giản của việc mà đã được chỉ chính xác phải làm gì. Giả sử điều tất nhiên là nó được yêu cầu theo một cách thức mà họ cảm thấy phù hợp.

Tuy nhiên, có một chi phí ẩn.

Biết được chính xác những gì để code trước khi code sẽ làm biến đổi quá trình trí tuệ và sáng tạo thành một quá trình cơ học, (tôi hay gọi vui đó là công việc tay to) hay nói cách khác, nó biến các developer thành những chú khỉ biết code (hay code bắt chước). Quan trọng hơn, các developer tham gia muốn hiểu "tại sao" họ đang làm việc theo cách này chứ không phải là một cách khác. Trừ khi, tất nhiên, nó chỉ là một hack nhỏ để work around một trường hợp cạnh, hoặc một miếng vá tạm thời. Nhưng một developer, người mà ngưng quan tâm đến những quyết định quan trọng và những lý do đằng sau đó, sẽ là người mà họ đã sẵn sàng thay đổi công việc.

Làm thế nào để ngăn chặn điều này ?

Điều cần thiết chính là văn hoá khuyến khích các cuộc thảo luận cởi mở. Với một diễn đàn thường xuyên để tranh luận, lập kế hoạch và lên kế hoạch như một nhóm những gì cần phải làm. Và để bảo vệ một nền văn hoá như vậy, tất cả mọi người trong nhóm phải thận trọng. Đó là khi những thời điểm khó khăn (hoặc các deadline đang đến gần), người mentees cần phải nói to hơn và các mentor cần lắng nghe cẩn thận hơn.

The day-to-day always gets boring

Cuối cùng nhưng không kém phần quan trọng: các thói quen của một môi trường kín là sát nhân tuyệt đối của niềm vui.

Điều này không cụ thể đối với developer hoặc ngành công nghệ cao. Nó ảnh hưởng khá nhiều cho bất kỳ công việc hậu văn phòng nào. Mỗi ngày, trong cùng một phòng, cùng những người giống nhau, cùng một nền văn hoá, cùng một vai trò ... Ngay cả trong một môi trường phát triển nhanh, và thậm chí khi tất cả mọi thứ nói trên đều "tốt" một cách khách quan, thì mọi người cũng bắt đầu cảm thấy được hưởng những phần tốt và thất vọng bởi những phần không tốt.

Làm thế nào để chúng ta chiến đấu chống lại điều này ? Một thành phần quan trọng ở đây là sự đa dạng, thuê những người có tính cách và nguồn gốc khác nhau (ví dụ như nhóm của chúng tôi là 6 người hiện đang là Anh, Pháp, Nga và Hy Lạp). Nhìn thấy cùng một người mỗi ngày chắc chắn là thú vị hơn nếu mỗi một người trong số những người này có thể mang lại một cái gì đó khác cho văn hóa hiện tại. Ngoài ra, chúng tôi cố gắng tạo ra cơ hội thường xuyên để bước ra ngoài hàng ngày.

Ví dụ: Chúng tôi cũng có các dự án phụ và đóng góp cho các công cụ mã nguồn mở yêu thích của chúng tôi. Thỉnh thoảng, chúng tôi thậm chí giúp đỡ cho phần còn lại của nhóm với công việc ít mang tính kỹ thuật hết lần này đến lần khác (ví dụ: tuyển dụng, tiếp thị, phân phối ...). Không phải vì tất cả chúng ta đều giỏi về điều này, nhưng vì mục tiêu là sự thay đổi. Đôi khi, chúng tôi cùng nhau suy nghĩ một ý tưởng mới. Đôi khi chúng tôi chỉ chơi League of Legends. Hoặc chúng tôi đi đến quán rượu. Vẻ đẹp của nó đến từ thực tế là chúng tôi không biết những gì chúng tôi sẽ làm cho đến phút cuối cùng, khi chúng tôi quyết định cùng nhau.

Có chút hỗn loạn là thành phần cuối cùng trong công thức của chúng tôi chống lại sự nhàm chán. Và như mọi công thức, không bao giờ có thể thực sự hoàn thiện. Hãy tinh chỉnh liều lượng, thay thế các thành phần và lặp lại.

HAPPY CODING !

Source: https://blog.enki.com/coding-is-boring-unless-4e496720d664