10 điều lập trình viên nên làm để phát triển sự nghiệp trong tương lai

Khi trở thành lập trình viên, bạn cần nắm rõ các việc dưới đây để hoàn thành tốt vai trò của bản thân trong con đường sự nghiệp phát triển tương lai.

1. Lập trình viên viết code để tất cả mọi người cùng hiểu

Câu trả lời rất phổ biến của đa số lập trình viên khi được yêu cầu 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. Việc này 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.

Một số code 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ừ tất cả mọi người chứ không chỉ riêng mỗi mình bạn.

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

Một tình huống rất phổ biến là leader kỹ thuật trong nhóm làm tất cả công việc thú vị và đầy thử thách, giao các công việc lặp đi lặp lại cho ‘những người bình thường’.

Leader có thể trở thành người dẫn đầu vì 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ó. Đây chắc chắn là người giỏi nhất để phân tích những vấn đề khó nhanh nhất. Nhìn vào vai trò hiện tại của mình với tư cách là architect lead, chắc chắn rằng bản thân bạn đã phạm phải điều này. Nhưng bên cạnh đó bạn phả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ì khó tái tạo (reproduce) hoặc không liên quan trực tiếp đến công việc mà họ đang làm. 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 đang bận rộn.

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

Một số người cho rằng kiến thức là sức mạnh. Đó có vẻ là ý kiến nếu bạn có kiến thức sâu rộng. Nhưng sức mạnh to lớn luô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.

Không cần để 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 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 đề. Nếu bạn là một người khá thiếu kiên nhẫn càng 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 bạn đi đến mục tiêu.

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

Đây là điều khác với việc bạn khi chia sẻ kiến thức. Giả sử rằng, trong trường hợp đồng nghiệp 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 không biết điều gì đó, vì thế tránh 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ó đang bỏ sót điều gì không?”. Đây là những câu hỏi mở giúp họ thoải mái. Và một lần nữa hãy kiên nhẫn ngay cả với chính bản thân bạn.

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

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ó thể mắc phải chính là giả vờ như họ tự nghĩ ra ý tưởng đó. Nếu bạn đăng một bài viết thú vị trên Twitter, hãy cố gắng Tweet tác giả đó vào bài viết của mình. Nếu bạn nhận được bài viết thông qua một người nào đó bạn biết, hãy viết kèm “thông qua @whoever”.

Đây là cách để bạn nói lời cảm ơn tới tác giả hoặc người giới thiệu. Hãy làm như vậy trong các bài đăng trên blog của mình, bạn sẽ học được rất nhiều từ đồng nghiệp của mình. Ví dụ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ũ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, hãy cố gắng cấp sự tín nhiệm 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. Đ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 hơn. Một người nếu được đánh giá cao về ý 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 tắc code (coding conventions)

Không có gì ngạc nhiên khi bạn 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 dễ giải quyết

Thật đáng kinh ngạc về số lần bạn đọc một số kỹ thuật, framework hoặc library mới được cho là giải quyết 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ư framework client-side cuối cùng. Và bây giờ  có Facebook’s React.

Không có công cụ, framework hoặc library nào có thể giải quyết các vấn đề của bạn, cũng như không giải quyết được 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à có ảnh hưởng sâu sắc đến cách xây dựng phần mềm, nhưng hãy thực tế. Chỉ cần đảm bảo 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 nó áp dụng, những tình huống không nên dùng và luôn để mắt các lựa chọn thay thế.

Nói chung, bạn có thể nhận thấy một pattern khi có thứ gì đó mới xuất hiện. Lúc đầu, bạn coi 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. Sau đó, bạn bắt đầu hào hứng và  bạn nói với mọi người về nó, 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 sử dụng chiếc búa mới của mình. Hãy cố gắng sử dụng ở mọi nơi, đơn giản vì bạn chưa tìm ra giới hạn của công nghệ. Cuối cùng, bạn học được ở đâu và khi nào thứ mới đó phù hợp để sử dụng và khi nào thì không.

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

Bạn làm một dự án nào đó trong vài tháng và đượ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 trong 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ứ từ đầu.

Điều tồi tệ nhất có thể xảy ra là những thứ tốt đẹp của bạn sẽ không được ai sử dụng, đơn giản 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 số đông. Thay vào đó, bạn có thể yêu cầu được phản hồi trong một số session demo. Hoặc bạn có thể viết một bài đăng trên blog (nội bộ) về nó. Hoặc 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 đang 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 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à chúng ta thường hay 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ừ đó, bạn đã không 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 khiến 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 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? Có rất nhiều người trong nghề đã cho bạn biết cách cư xử, cách lập trình, cách thiết kế, những phương pháp thực hành để sử dụng hàng ngày. Vì vậy, mặc dù 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ó đồng ý hay không. 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ề lập trình viên.

Lương Thuận – dịch từ Medium0