7 năm làm dev có gì hay ho?

Đã bao giờ bạn tự hỏi bản thân rằng liệu mình có yêu thích công việc này hay không? Liệu mình có thể theo đuổi nó trong mỗi quãng thời gian dài hay không? Mình đã tự hỏi bản thân mình như thế mỗi sáng thức dậy, liệu mình đã chọn đúng công việc, đúng con đường hay chưa?

Mình là một lập trình viên – một công việc mà mọi người nhìn vào sẽ nghĩ tới một mức lương cao ngất ngưởng, một công việc rất là “ngầu”, một công việc mà ai cũng phải ngưỡng mộ. Hành trình làm một dev của mình bắt đầu từ năm 2012, với vị trí thực tập sinh C++. Thẳng thắn mà nói, mình thực sự không có một chút ý tưởng nào cho công việc mình đang làm vào thời điểm ấy. Với tâm lý của một thằng thực tập sinh vắt mũi chưa sạch mới đi làm lần đầu, mình thực sự không có một chút định hướng nào cho công việc của mình. Tuy nhiên, mình cũng đã cố gắng theo đuổi và trụ vững tới bây giờ đã được 7 năm. Hôm nay, mình xin chia sẻ lại với các bạn những kinh nghiệm làm lập trình viên quý báu mà mình nhận được thông qua con đường 7 năm này.

Thử đặt câu hỏi: Mình nên dùng ngôn ngữ nào để giao tiếp với mọi người?

Đó là tiếng Anh? Tiếng Tây Ban Nha? Tiếng Trung? Hay là tiếng Nhật? Thời điểm đó mình đã ứng tuyển vào một công nước ngoài, trong công ty có rất nhiều nhân viên đến từ các nước khác nhau. Thực sự mình khá lo lắng đến việc phải dùng ngôn ngữ nào để giao tiếp với họ. Tiếng Anh? Okay Mình chọn ngôn ngữ phổ biến này, may mắn thay đó là ngoại ngữ duy nhất mà mình thành thạo.

Qua vấn đề về ngôn ngữ giao tiếp này, mình muốn khuyên các bạn rằng, khi ứng tuyển vào một công ty nào đó, bạn nên tìm hiểu kỹ môi trường làm việc để chuẩn bị sẵn cho mình tâm lý, cũng như những kỹ năng cần thiết nhất, nhất là vấn đề về ngôn ngữ. Nếu không thể giao tiếp với mọi người, hãy từ bỏ công việc đó. Công ty không thể thuê một nhân viên có thể làm việc nhưng “không thể nói” được.

Nói chuyện với mọi người thật sự còn quan trọng hơn cả nói chuyện với cái đống máy móc kia.

Vẫn là vấn đề về giao tiếp, bạn không thể hoàn thành một dự án chỉ với 1 người. Trong một vài trường hợp đặc biệt nào đó, bạn có thể thấy một sản phẩm tuyệt vời nào đó được tạo ra chỉ bởi 1 người (CodeSandbox làm một ví dụ điển hình) nhưng trong phần lớn các trường hợp, một sản phẩm là sự chung sức của cả một tập thể – và điều bạn cần có đó là một team.

Hãy xem việc lập trình như là một môn thể thao, và team của bạn là một đội chơi. Sẽ xảy ra chuyện gì nếu các thành viên trong team không giao tiếp với nhau hay tệ hơn là họ muốn làm việc độc lập không chịu hợp tác ? Trễ deadine, hỏng dự án, cấp trên phê bình, … đó là những gì có thể dễ dàng tưởng tượng ra được nếu trong team bạn xuất hiện hiện tượng đó. Kỹ năng giao tiếp có thể giúp bạn tạo ra hoặc thậm chí là cũng có thể khiến bạn phá hủy cả một dự án. Vấn đề này hoàn toàn phụ thuộc vào cách giải quyết của bạn với mọi người trong team. Nếu không ai đứng ra giải quyết thì chính bạn là người phải có những biện pháp cải thiện vấn đề đó nếu muốn hoàn thành dự án một cách êm đẹp.

Thế mới nói, kỹ năng mềm chuyên nghiệp có thể trở nên quan trọng hơn so với một kỹ thuật nào đó trong sự thành công của một dự án.

Các bạn cần có một sự hiểu biết sâu sắc về những thứ bạn đang làm cũng như là hãy có những câu hỏi vì sao dành cho nó.

Phần lớn mọi người đều sẽ cảm thấy thỏa mãn khi họ nhận thức được mục đích công việc họ đang làm. Áp dụng điều này trong công việc rất là đúng.

Bạn phải hiểu rằng, mục tiêu của các nhà phát triển đó là giải quyết được các vấn đề về code.

Nếu bạn sở hữu một kiến thức sâu rộng về hệ thống mà bạn đang xây dựng hoặc đang duy trì thì đó sẽ là một lợi thế cho bạn. Bạn có thể có những ý tưởng, những quyết định mang thiên hướng không theo lối mòn trước đây. Hãy thử đặt ra những câu hỏi như: chức năng này có thực sự cần thiết hay không? Đoạn code này đang xử lý cái gì? Vấn đề này có cần phải ưu tiên xử lý ngay từ đầu không?

Lối suy nghĩ này sẽ giúp ích cho bạn rất nhiều trong công việc. Nếu bạn muốn làm tốt công việc của mình thì các bạn không nên chỉ hiểu về mục đích của công việc mà còn phải biết định hình cũng như gây ảnh hưởng đến nó nữa. Hãy tận dụng ưu thế về kiến thức sâu rộng của bạn (nếu có) để vươn cao hơn trong công việc.

Nếu các bạn xem việc đánh giá code trong team của mình là một việc căng thẳng thì các bạn đang có lối suy nghĩ sai lầm rồi, thật sự rất sai lầm.

Đối với một nhà phát triển, việc đưa code của mình ra cho cộng đồng đánh giá và thu lại những phản hồi thật sự là những trải nghiệm độc đáo. Cộng đồng có thể chê, có thể khen, có thể giúp bạn cải thiện cũng như tối ưu các đoạn code mà bạn tạo ra. Đừng lo lắng về những lời chê, tất cả mọi người đều có quyền lo lắng về những trải nghiệm của họ đối với sản phẩm, và những sản phẩm đó được tạo ra dưới bàn tay của bạn thì bạn phải có trách nhiệm đảm bảo cho họ có được một sự trải nghiệm tốt nhất có thể.

Bạn đánh giá code của các thành viên trong team và nhận thấy chức năng này hoàn toàn sai nhưng tất cả mọi người lại không có phản ánh gì.

Chúng ta cần một buổi gặp mặt riêng tư, hãy hẹn riêng một người nào đó trong team, nói chuyện và tìm hiểu lý do xem tại sao họ lại thực hiện đoạn code đó theo cách này.

Tất nhiên với tư cách là một nhà phát triển thì không ai muốn viết nên một đoạn code tệ hại cả. Nhưng nếu họ làm vậy, có lẽ họ đang mắc phải một số vấn đề gì đó mà bạn không biết. Nếu họ thật sự không giỏi trong việc lập trình ( có thể là chưa giỏi thôi nhé ), tới lúc cho bạn tỏa sáng dưới vai trò là một người cố vấn rồi đấy.

Một vài rắc rối sẽ xảy ra, hãy luôn trong tư thế chuẩn bị.

Định luật Murphy có một câu ngạn ngữ rằng: “Bất cứ điều gì đó có thể sai sẽ trở thành sai.“

Câu nói đó thật sự rất đúng. Hãy luôn luôn cho rằng một cái đó sẽ xảy ra và phá hủy hệ thống mà bạn đang xây dựng.

Nếu bạn đang thiết kế một form đăng nhập, thử giả định rằng một người dùng nào đó sẽ sao chép và dán toàn bộ nội dung của một cuốn sách nào đó vào phần mật khẩu. Nghe thật tệ cho hệ thống của bạn.

Nếu bạn đang xây dựng một cửa sổ WYSSIWYG, thử tưởng tượng một người nào đó sẽ cố gắng phá hủy nó, và hãy xem như là họ sẽ thành công trong việc đó đi nhé.

Nếu bạn đang có một cơ sở dữ liệu, nó có thể sẽ sập nguồn ở một thời điểm nào đó. Trước đó bạn chưa từng thử phục hồi nó từ dữ liệu sao lưu, chuyện gì sẽ xảy ra? Dữ liệu sao lưu đó có chắc chắn là sẽ hoạt động tốt như bạn nghĩ ?

Hãy lường trước mọi rắc rối mà có thể xảy ra – trong khả năng của bạn, lên kế hoạch sẵn sàng cho những rắc rối đó. Tin mình đi, việc này không hề thừa thãi vô ích đâu.

Đừng sợ khi phải nói “Mình không biết”

Điều tốt nhất khi bạn có một người cấp trên ở bên cạnh trong công việc đó là bạn có thể nói: “Mình không biết, mình chưa bao giờ thử nó trước đây. Mình sẽ xem xét lại và phản hồi sớm nhất lại cho bạn “

Khi mình còn là một junior, mình thực sự rất sợ khi phải nói “ Mình không biết “ về một vấn đề nào đó. Kết quả của nỗi sợ đó là gì, mình phải tốn thêm thời gian để tìm hiểu về các vấn đề mình không hiểu thay vì thú nhận với cấp trên là mình không biết gì về nó và cần họ giúp đỡ. Tin mình đi, không ai phê bình bạn khi bạn nói câu “ Mình không biết “ cả, trung thực sẽ tốt cả hai bên. Bạn hiểu được vấn đề nhanh hơn, đỡ mất thời gian, cấp trên thì đảm bảo dự án của họ sẽ được hoàn thành đúng hạn và chất lượng được đảm bảo.

Học từ cộng đồng

Đã bao giờ bạn nghĩ bạn sẽ chia sẻ những kiến thức mình ra cho cộng đồng ? Bạn có tự tin là mọi kiến thức bạn biết là đã quá đủ ? Hãy thử viết blog, quay một video, hay tạo một sự kiện về chia sẻ kiến thức gì đó ở công ty hoặc thậm chí đơn giản là … chia sẻ kiến thức với một người bạn trong một buổi cà phê ngẫu hứng nào đó. Tin mình đi, kết quả thu về sẽ khiến bạn bất ngờ đấy, có thể sẽ xuất hiện ra những phản hồi thú vị nào đó, những thủ thuật hay ho mà bạn chưa hề biết, thậm chí là một phản bác nào đó khiến bạn phải chú ý và thảo luận với họ về nó. Học hỏi luôn là một điều tốt, nếu bạn nghĩ rằng phải có sự rõ ràng giữa cấp trên với cấp dưới thì hãy bỏ ngay đi nhé. Ngay cả những người cấp trên cũng có một cái gì đó để học hỏi từ những người mới bắt đầu và ngược lại.

Chỉ bảo là một hành động đáng để thử để thể hiện được sự đảm bảo về độ hiểu biết của bạn về chủ đề đang nói.

Và bây giờ, những bài học nào mà các bạn đã có được khi là một nhà phát triển?

Xem thêm việc làm Software Developers mới nhất trên TopDev

TopDev