Sự khác biệt giữa lập trình viên thông minh và lập trình viên khôn ngoan

“Không ai ngu ngốc hơn kẻ nghĩ mình khôn ngoan; không ai khôn ngoan hơn kẻ luôn nghi ngờ mình là kẻ ngốc.” – Marguerite de Valois

Hầu hết các lập trình viên đều rất thông minh trong việc viết code, trong nhiều tình huống sự thông minh này là một điểm mạnh và cũng là điểm yếu.

Lý trí, sự khôn ngoan, thực tế và kinh nghiệm có thể giúp các lập trình viên tránh được vấn đề thay vì giải quyết chúng. Biết khi nào nên viết code và khi nào nên từ chối yêu cầu.

Biết khi nào nên im lặng, khi nào nên đấu tranh và khi nào nên chạy trốn và ẩn mình mang lại lợi thế cho lập trình viên khôn ngoan (senior) so với lập trình viên thông minh (junior).

Bởi vì có rất nhiều bài nói về so sánh giữa fresher và senior rồi nên tôi hi vọng bài viết này có thể thêm một góc nhìn cho bạn về việc so sánh giữa junior và senior.

Senior vs Junior
Senior vs Junior

Sự khác biệt giữa thông minh và khôn ngoan là gì?

Các lập trình viên chỉ dành 50% thời gian để viết code.

  • Các lập trình viên junior nhận các yêu cầu đơn giản và tạo ra code phức tạp
  • Các lập trình viên senior nhận các yêu cầu phức tạp và tạo ra code đơn giản

Nói chung có thể gọi các lập trình viên senior là khôn ngoan và các lập trình viên junior là thông minh nhưng chưa mắc đủ sai lầm để trở nên khôn ngoan. Sự khác biệt giữa lập trình viên junior và lập trình viên senior là kinh nghiệm, kiến thức và kỹ năng.

Kinh nghiệm là sự khác biệt. Một khi lập trình viên mắc sai lầm, họ (hy vọng) tránh được nó bằng cách không mắc lại sai lầm đó trong tương lai. Điều này khiến họ sẽ mắc những sai lầm mới và qua thời gian, lập trình viên sẽ biết cách tránh được nhiều sai lầm hơn.

Sai lầm trong phát triển phần mềm có thể khó thấy trước vì hậu quả và nỗi đau nằm ở tương lai xa. Những sai lầm đơn giản cho phản hồi nhanh, bạn sẽ có thể tìm thấy nó và sửa chữa nó nhanh chóng. Nhưng những sai lầm không đơn giản như việc hard code một giá trị và ban đầu dường như không có gì khó khăn khi khối code còn nhỏ. Một thời gian sau khi bạn cần phải chỉnh sửa lại toàn bộ để thay đổi giá trị đó và bạn có thể sẽ phải trả giá cho quyết định này rất nhiều lần.

Tránh vấn đề thay vì giải quyết

Người thông minh giải quyết vấn đề. Người khôn ngoan tránh nó — Albert Einstein

Tất cả các lập trình viên đều muốn viết code. Đó là những gì họ giỏi và đó là những gì họ thích làm. Kỹ năng mà các lập trình viên senior học được là khi nào nên viết code, khi nào nên làm rõ và khi nào không cần viết code.

Các lập trình viên junior giống như người có một cái búa vàng, mọi yêu cầu và vấn đề dường như là cơ hội để viết code. Khi gặp một vấn đề hoặc một yêu cầu bạn nghĩ ngay tới việc sử dụng code để giải quyết vấn đề.

Viết code nên là lựa chọn cuối cùng vì mỗi dòng code được tạo ra sẽ trở thành gánh nặng cho dev team. Một khi bạn viết thêm code, nó phải được maintain và làm tăng sự phức tạp của code base.

Trong ngắn hạn, code là giải pháp tuyệt vời nhưng trong dài hạn nó khiến chúng ta mất nhiều thời gian hơn, tăng sự phức tạp và thêm gánh nặng bảo trì.

Hiệu quả hơn là viết ít code, điều này sẽ giảm thiểu khả năng tạo ra lỗi lầm. Các lập trình viên senior biết rằng bạn chỉ nên viết code khi bạn buộc phải làm và khi bạn đã xác nhận yêu cầu.

Lập trình viên khôn ngoan giảm thiểu code được tạo ra bằng cách chỉ làm các yêu cầu bắt buộc và bỏ qua các yêu cầu vô thưởng vô phạt kiểu “có cũng được, không có cũng chẳng sao”.

Một vài yêu cầu có thể xử lí được bằng cách thay đổi quy trình kinh doanh hoặc chỉ đơn giản là trao đổi với khách hàng thay vì viết code. Đừng tự động hóa mọi thứ, đôi khi lựa chọn thủ công là lựa chọn tốt nhất.

Như tôi thường nói với dev team của mình

“Cách tốt nhất để code là đừng code”

Biết khi nào nên viết code

Bạn phải biết khi nào nên giữ lại, khi nào nên từ bỏ, khi nào nên rời đi, khi nào nên chạy trốn. — Kenny Rogers

Các lập trình viên khôn ngoan (senior) biết khi nào nên viết code, khi nào nên xác nhận, kiểm tra và không viết code. Các lập trình viên junior giỏi viết code và họ muốn sử dụng những kỹ năng này càng thường xuyên càng tốt.

Điều này làm nổi bật sự khác biệt trong sản phẩm đầu ra nhưng có một sự khác biệt lớn hơn giữa lập trình viên junior (thông minh) và lập trình viên senior (khôn ngoan) là biết khi nào nên viết code.

Đơn giản hóa

Các lập trình viên junior muốn viết code ngay lập tức, thường trước khi họ hiểu lý do tại sao khách hàng cần code và nó cần làm gì.

Các lập trình viên senior tìm kiếm các giả định và xác nhận yêu cầu. Không quan trọng bạn viết code tốt như thế nào nếu nó đang làm sai điều cần làm.

Bạn tạo phần mềm, website nhanh hơn bằng cách viết code với các yêu cầu đã được xác nhận. Có rất nhiều việc cần làm với code như cập nhật các phần code phụ thuộc, code liên quan, kiểm tra, build, tài liệu. Đôi khi dev team sau này sẽ đi nhanh hơn bằng cách khởi đầu chậm hơn và tạo ra những sản phẩm “gãi đúng chỗ ngứa”.

Với tôi khi bạn có khả năng chạy code trong đầu thay vì phải thực sự chạy debug để tìm ra output value thì bạn đang có level middle trở lên rồi.

Lắng nghe và hiểu rõ mục đích

Nguyên tắc đầu tiên là bạn không được tự lừa dối mình và bạn là người dễ bị lừa dối nhất. — Richard P. Feynman

Thợ mộc đo hai lần và cắt gỗ một lần. Các lập trình viên hiếm khi cẩn thận như vậy.

Các lập trình viên khôn ngoan (senior) hiểu rằng họ là chuyên gia trong việc tạo phần mềm và người dùng là chuyên gia trong doanh nghiệp của họ. Tạo phần mềm là sự hợp tác giữa chuyên gia trong lĩnh vực kinh doanh và công nghệ.

Các lập trình viên junior quên và lắng nghe một số yêu cầu, ngừng lắng nghe và chuyển sang suy nghĩ về  các giải pháp kỹ thuật. Các lập trình viên senior tập trung vào mục tiêu và quy trình kinh doanh để hiểu được mục đích của phần mềm. Chỉ khi bạn hiểu được mục đích của doanh nghiệp, đội ngũ và vai trò cá nhân, bạn mới có thể tạo phần mềm để giúp họ.

Sai lầm phổ biến xảy ra khi các lập trình viên junior đọc đủ yêu cầu để tìm ra con đường thuận lợi và tạo ra điều đó. Sau đó, khi con đường không thuận lợi và các ngoại lệ xuất hiện, lập trình viên junior phải liên tục thay đổi code để sửa lỗi này sau lỗi khác (Tôi thường gọi đó là work around).

Điều tưởng chừng sẽ tạo nên sự tiến bộ nhanh ở giai đoạn ban đầu nhưng dần dần sẽ tạo nên lỗi lên lỗi xuống khiến công việc bị chậm lại. Một lập trình viên senior tốt tạo code một lần duy nhất và nó hoạt động trơn tru.

Các lập trình viên senior biết khi nào nên đặt câu hỏi, khi nào nên lắng nghe và khi nào nên nói.

“Sự im lặng là bài học từ nhiều nỗi đau của cuộc đời.” — Seneca

Làm tốt công việc của mình

Phát triển phần mềm cần một đội ngũ để thực hiện, và điều đó cần mọi người làm công việc của mình.

Việc giúp đỡ có hai mặt, nó có thể giúp người khác trong ngắn hạn nhưng sẽ làm tổn hại bạn trong dài hạn. Bạn càng làm công việc của người khác, bạn càng ít thời gian để làm công việc của mình. Làm công việc của người khác có nghĩa là bạn đảm nhận hoặc tham gia vào các nhiệm vụ hoặc trách nhiệm không thuộc phạm vi công việc hoặc vai trò của bạn. Điều này có thể xảy ra vì nhiều lý do, chẳng hạn như muốn giúp đỡ đồng nghiệp, thiếu sự phân công công việc rõ ràng, hoặc không có ai khác để thực hiện nhiệm vụ đó.

Ví dụ:

  • Tình huống: Một lập trình viên nhận được yêu cầu thay đổi từ khách hàng và thay vì chuyển yêu cầu này cho bộ phận hỗ trợ khách hàng hoặc người quản lý dự án, họ tự mình giải quyết yêu cầu đó.
  • Hậu quả: Lập trình viên mất thời gian quý báu để giải quyết các vấn đề ngoài phạm vi công việc của mình, có thể dẫn đến việc không hoàn thành các nhiệm vụ chính đúng thời hạn. Đồng thời, không thông qua bộ phận hỗ trợ khách hàng có thể làm mất đi sự nhất quán trong quản lý yêu cầu khách hàng.

Các lập trình viên khôn ngoan đảm bảo rằng hiểu rõ ai làm trách nhiệm gì trong dự án và để họ thực hiện công việc đó.

Các lập trình viên cần bảo vệ thời gian của mình và đẩy trách nhiệm và quyết định cho những người chịu trách nhiệm về điều đó. (Ví dụ PO, QA… thay vì tự gánh vác một mình)

Các lập trình viên junior bị cuốn vào việc làm công việc của người khác, bị mắc kẹt và hết thời gian để làm công việc của mình. Nếu bạn làm điều này đủ nhiều, bạn sẽ làm việc nhiều giờ hơn và hướng đến sự kiệt sức.

Thích ứng với thực tế

“Hôm qua tôi thông minh, vì vậy tôi muốn thay đổi thế giới. Hôm nay tôi khôn ngoan, vì vậy tôi đang thay đổi chính mình.” — Rumi

Mọi thứ sẽ sai, vấn đề sẽ xảy ra, kế hoạch sẽ sai và thiết kế sẽ thay đổi. Bạn không thể chống lại thực tế. Tôi từng rất ghét việc đang code hoặc code xong thì BA lại thay đổi yêu cầu và tôi lại phải code lại từ đầu hoặc chỉnh sửa rất nhiều phần code của mình. Nhưng cuộc sống của người lập trình viên là vậy, công việc này là vậy và bạn không thể tránh né nó. Bạn chỉ có thể thích nghi với môi trường và thay đổi theo nó.

Các lập trình viên junior chống lại thực tế, các lập trình viên senior thích nghi với nó.

Bạn không thể ngăn chặn vấn đề, lỗi và sự cố, nhưng bạn có thể chuẩn bị cho chúng và đảm bảo rằng chúng không kết thúc trong thảm họa. Chuẩn bị tinh thần cho những điều xấu nhất xảy ra rất quan trọng để khi incident xảy ra, bạn đã sẵn sàng các công cụ và kế hoạch để xử lí nó ngay lập tức. Hãy luôn cảnh giác.

Dù chưa gặp incident trong suốt 3 năm qua nhưng đây là những gì tôi và cả team đã chuẩn bị để nó xảy ra gây thiệt hại nhỏ nhất có thể và thời gian xử lí nhanh nhất có thể:

  • Sao lưu cho phép chúng tôi khôi phục và giảm thiểu mất dữ liệu
  • Đảm bảo chúng ta không có một source code fail nào.
  • Các phần code quan trọng luôn có thể catch lỗi và có cơ chế retry.
  • Kiểm soát source code tốt, back up các version liên tục để có thể rollback bất cứ lúc nào
  • Luôn luôn có phần check build problem.
  • Thường xuyên sử dụng unit testing và auto testing để tìm bug mỗi lần thay đổi code
  • Cảnh báo thường xuyên các dịch vụ đang ngừng hoạt động và giảm thời gian ngừng hoạt động của chúng.
  • DevOps giúp giảm lỗi deploy thủ công (CI CD)
  • Viết tài liệu bàn giao rõ ràng và kiểm tra các quyền truy cập khi có người rời khỏi dự án

Add a Comment

Scroll Up