Kể từ bài viết 12 điều tôi tin rằng các lập trình viên chuyên nghiệp nên làm, vào tháng 8, tôi bắt đầu lưu ý đến các hành vi, kỹ năng và đặc điểm khác ở những người tôi gặp khi làm việc trong các dự án phần mềm phức tạp. Bên cạnh đó, tôi nhận được khá nhiều đề xuất thông qua Twitter. Vì vậy, hãy cùng nhau thảo luận thêm một số về vấn đề này.

1. Họ không viết code cho mỗi họ hiểu

Câu trả lời rất phổ biến mà tôi nhận được khi tôi yêu cầu developer có kinh nghiệm refactor lại một số function họ viết quá dài là họ không gặp vấn đề gì khi đọc lại code của mình. Nó thậm chí còn tồi tệ hơn việc khi bạn làm việc chung với team nhưng người thì thích lập trình function, người thích viết các callback gọi lại liên tục với nhau, nói chung mỗi người 1 style, thiệt là khổ =)).

Khi một người khác nói với một anh chàng như vậy về sự phản đối của tôi, anh ta đáp lại bằng cách nói rằng code của anh ta chỉ được duy trì bởi những gì tốt nhất. Tôi đoán có một số code ngoài đó yêu cầu các kỹ năng đặc biệt để hiểu và trích xuất code đó cho một component riêng biệt để tận dụng lại ở chỗ khác hoặc dự án khác. Nhưng tôi vẫn tin rằng code chất lượng cao bắt đầu bằng việc chấp nhận từ mọi người chứ không chỉ riêng mỗi mình bạn.

2. Họ không chọn công việc làm cho vui. Họ làm những gì cần phải làm

Một tình huống rất phổ biến là người lãnh đạo kỹ thuật trong nhóm (technical lead) làm tất cả công việc thú vị và đầy thử thách và giao tất cả công việc lặp đi lặp lại cho 'những người bình thường'. Và không có gì đáng ngạc nhiên khi chúng ta thấy điều đó.

Leader có thể trở thành người dẫn đầu vì anh ta có thể dùng kỹ năng của mình để áp dụng công nghệ mới vào codebase hiện có. Anh ấy có lẽ là người giỏi nhất để phân tích những vấn đề khó nhanh nhất. Nhưng tôi không ngạc nhiên vì thái độ này không phải là điều tốt nhất cho tinh thần của team cũng như cho việc chia sẻ kiến ​​thức.

Nếu tôi nhìn vào vai trò hiện tại của mình với tư cách là architect lead, tôi chắc chắn rằng bản thân mình đã phạm phải điều này. Nhưng bên cạnh đó tôi thường xuyên sửa khá nhiều lỗi khó, cả trong quy trình phát triển cũng như những lỗi khách hàng báo cáo. Những điều này có xu hướng bị các nhóm bỏ qua vì chúng khó tái tạo (reproduce) hoặc vì chúng không liên quan trực tiếp đến công việc mà họ đang làm. Nếu tôi tin rằng những thứ này cần sửa chữa cấu trúc (chứ không phải patch) và các thành viên trong nhóm của tôi đang bận rộn, tôi sẽ tự nhận chúng, ngay cả khi điều đó khiến tôi thấy chả mấy thú vị.

3. Họ làm việc chăm chỉ để chia sẻ kiến thức của họ với các lập trình viên ít kinh nghiệm hơn

Một số người nói rằng kiến thức là sức mạnh. Đó có vẻ là ý kiến hay nếu bạn có kiến thức sâu rộng. Nhưng sức mạnh to lớn đi kèm với trách nhiệm lớn, đó là trách nhiệm chia sẻ kiến thức với các lập trình viên ít kinh nghiệm hơn.

Và không cần cho người khác thấy bạn hiểu biết nhiều như thế nào. Bạn chỉ cần cố gắng giải thích cách bạn nghĩ, cách bạn tiếp cận các vấn đề phức tạp, nơi bạn tìm kiếm những thông tin đó, cách cấu trúc công việc và họ cần nói chuyện với ai về chủ đề gì để giải quyết vấn đề. Tôi là một người khá thiếu kiên nhẫn, vì vậy đôi khi tôi phải cố gắng giải thích cách để đi đến kết luận cuối cùng. Đối với họ, kiến thức tại thời điểm đó không quan trọng bằng quá trình, cách thức bạn đi đến mục tiêu.

4. Họ có thể đặt mình vào vị trí của những lập trình viên ít kinh nghiệm hơn

Đây là điều khác với việc bạn chia sẻ kiến thức. Giả sử rằng, trong trường hợp đồng nghiệp có vẻ hiểu bạn đang nói gì, hãy cố gắng xác nhận bằng cách đặt câu hỏi phù hợp. Họ có thể sợ nói với bạn rằng họ không biết điều gì đó. Vì thế đừng hỏi những câu như “Bạn có hiểu ý tôi không?”. Thay vào đó, hãy đặt những câu hỏi như “Trong những gì vừa thảo luận, có phần nào cần được giải thích rõ hơn không?” hoặc “Tôi có bỏ sót điều gì không?”. Đây là những câu hỏi mở có thể giúp họ thoải mái. Và một lần nữa (bây giờ tôi đang nói với chính mình), hãy kiên nhẫn…

5. Họ cung cấp sự tín dụng cho những người xứng đáng

Theo ý kiến ​​của tôi, một trong những thói quen khó chịu nhất mà một lập trình viên, kiến ​​trúc sư hoặc bất kỳ ai khác trong nghề của chúng ta có thể mắc phải, là giả vờ như họ tự nghĩ ra ý tưởng đó. Nếu tôi đăng một bài viết thú vị trên Twitter, tôi sẽ cố gắng Tweet tác giả đó vào bài viết của tôi. Nếu tôi nhận được bài viết thông qua một người nào đó mà tôi biết, tôi sẽ viết kèm "thông qua @whoever".

Đây là cách tôi nói lời cảm ơn tới tác giả hoặc người giới thiệu. Tôi cũng làm như vậy trong các bài đăng trên blog của mình. Ví dụ, tôi đã học được rất nhiều về OWIN từ đồng nghiệp Damian Hickey của tôi. Tương tự, Yves Reynhout đã từng là bạn của tôi về Event Sourcing and Domain Driven Design. Ngay cả việc khởi động lại blog của tôi cũng được lấy cảm hứng từ cuốn sách Soft Skills của John Sonmez.

Trong phạm vi công việc, tôi cố gắng cấp sự tín dụng cho các lập trình viên cá nhân trong các blog nội bộ hoặc các cuộc thảo luận FlowDock của chúng tôi. Điều đó đặc biệt quan trọng đối với sự tự tin của các lập trình viên ít kinh nghiệm. Một người nếu được đánh giá cao về một ý tưởng hoặc một thành tích nào đó có thể tạo ra một thế giới khác biệt.

6.Họ tuân thủ các quy ước code (coding conventions)

Không có gì ngạc nhiên khi tôi là người ủng hộ mạnh mẽ cho các nguyên tắc viết code (hoặc các tiêu chuẩn nếu bạn muốn). Tôi đã tham gia vào những vấn đề này trong nhiều năm và dựa trên những điểm tôi đã thảo luận ở trên, tôi vẫn tin rằng chúng rất có giá trị.

Chúng không làm phiền các lập trình viên hoặc hạn chế khả năng sáng tạo của họ. Thay vào đó, chúng ở đó để giúp họ tránh những lỗi thường gặp, thúc đẩy phát triển lập trình hướng đối tượng và đảm bảo code base với các quy ước đặt tên và layout nhất quán. Một số kiến trúc sư nghĩ rằng mỗi component hoặc dự án có thể xác định các quy ước riêng, nhưng tôi không đồng ý với điều đó. Trong thực tế, một người chuyển từ dự án này sang dự án khác nên sự nhất quán giữa các code base khác nhau là rất hữu ích. Nhưng tôi khá chắc rằng họ không đồng ý với tôi vì họ muốn sử dụng các quy ước của riêng họ…

7.Họ biết rằng không phải mọi vấn đề đều là đinh nếu họ có một cái búa

Thật đáng kinh ngạc về số lần bạn đọc về một số kỹ thuật, framework hoặc library mới được cho là giải quyết được các vấn đề của bạn. Tôi vẫn nhớ khi KnockoutJS được giới thiệu. Sau đó, AngularJS xuất hiện như một framework client-side cuối cùng. Và bây giờ chúng ta có Facebook’s React.

Không có công cụ, framework hoặc library nào có thể giải quyết tất cả các vấn đề của bạn, cũng như không giải quyết được một vấn đề cụ thể trong mọi tình huống. Các ngoại lệ như Git hoặc OWIN tồn tại và chúng có ảnh hưởng sâu sắc đến cách chúng ta xây dựng phần mềm, nhưng hãy thực tế. Chỉ cần đảm bảo rằng bạn hiểu giá trị gia tăng của một giải pháp như vậy, ví dụ: bối cảnh mà nó áp dụng, những tình huống không nên dùng và luôn để mắt đến các lựa chọn thay thế.

Nói chung, bạn có thể nhận thấy một pattern bất cứ khi nào có thứ gì đó mới xuất hiện. Lúc đầu, bạn coi nó như một giải pháp khác cho cùng một vấn đề và từ chối sử dụng nó hoặc xem giá trị gia tăng của nó. Sau đó, bạn bắt đầu hào hứng với nó, bạn nói với mọi người về nó, và biến nó thành một chiếc búa nổi tiếng. Trong giai đoạn tiếp theo, mọi vấn đề sẽ trở thành cái đinh để bạn có thể sử dụng chiếc búa mới của mình. Bạn cố gắng sử dụng nó ở mọi nơi, đơn giản vì bạn chưa tìm ra giới hạn của công nghệ. Nhưng có ánh sáng ở cuối đường hầm đó. Cuối cùng, bạn học được ở đâu và khi nào thứ mới đó là thứ phù hợp để sử dụng và khi nào thì không. Nó chỉ trở thành một tool khác trong toolbox của bạn.

8. Họ không ngại chia sẻ thành tích của mình

Bạn làm một dự án tuyệt vời nào đó trong vài tháng và nó được coi là nền tảng cấp độ tiếp theo cho dự án hoặc sản phẩm khác. Bây giờ là lúc để chia sẻ công việc của bạn và thực hiện một chút marketing (nội bộ). Nói về thành tích của bạn quan trọng hơn so với việc nói về cách xây dựng mọi thứ ngay từ đầu.

Điều tồi tệ nhất có thể xảy ra là món đồ chơi đẹp đẽ của bạn sẽ không được ai sử dụng, đơn giản là vì bạn chưa thuyết phục được mọi người. Bạn không nhất thiết phải trình bày bài bản trước một lượng lớn khán giả. Thay vào đó, bạn có thể yêu cầu phản hồi trong một số session demo. Hoặc bạn có thể viết một vài bài đăng trên blog (nội bộ) về nó. Bạn thậm chí có thể yêu cầu ai đó trong nhóm làm phần công việc đó giúp bạn. Vì chia sẻ công việc là một phần quan trọng trong nghề lập trình.

9. Họ không chỉ trích hiện trạng cho đến khi họ hiểu bản chất và lịch sử của nó

Một trong những sai lầm lớn nhất mà tôi nghĩ rằng tôi đã mắc phải là tham gia vào một tổ chức và chỉ trích cách họ đã làm việc hoặc xây dựng một cái gì đó. Kể từ đó, tôi nhận ra rằng mọi người thường cố gắng làm tốt nhất có thể trong hoàn cảnh mà họ đang ở. Vì vậy, nếu họ đưa ra quyết định mà bạn không đồng ý, hãy nhìn vào thực tế.

Tôi không nhận ra điều này cho đến khi tôi là người bị chỉ trích (hay nói cụ thể hơn, công việc của tôi chứ không phải cá nhân tôi). Trong một số trường hợp, lời phê bình của bạn có thể đúng và cần có những thay đổi. Nhưng trong nhiều trường hợp khác, họ có thể đã lập kế hoạch để thực hiện những hành động đúng đắn, nhưng những hành động đó lại bị theo dõi bởi áp lực dự án hoặc thương mại. Thậm chí tệ hơn, họ có thể bị quản lý quá mức mà thường không thực sự hiểu tại sao phát triển phần mềm liên quan đến nhiều hơn là chỉ thêm chức năng.

10. Họ tự suy nghĩ

Một bài viết nói về cách hành xử nhưng điều cuối cùng lại khuyên bạn phải tự suy nghĩ. Thật nực cười phải không? Nhưng tôi đã kết thúc bài đăng này với mục đích đó. Có rất nhiều người trong nghề của chúng ta cho bạn biết cách cư xử, cách viết code, cách thiết kế, những phương pháp thực hành để sử dụng. Vì vậy, mặc dù tôi tin rằng những điều được đề cập ở trên là những thói quen thường thấy của các lập trình viên chuyên nghiệp, nhưng bạn có quyết định đồng ý hay không. Tôi hy vọng bạn có thể suy nghĩ lại thói quen của bản thân và cách bạn bước chân vào nghề này.

Bài viết này được dịch từ: 10 more things professional software developers do