Dành cả 10 năm đầu tiên trong quãng đời tuổi trẻ của mình để làm coder, tôi nghĩ mình có thể hiểu tâm thế của các bạn dev trẻ khi bước vào các dự án mới. Chúng ta là developer. Chúng ta có thể vượt qua mọi thử thách. Chúng ta sẽ di chuyển từ domain này sang domain khác, dù đó là tài chính ngân hàng, điện nước, xăng dầu hay y tế.
Mọi thứ có vẻ đơn giản. Cứ bắt tay vào làm là sẽ giỏi, dự án sẽ thành công.
Đó là một trong những suy nghĩ mà tôi đã từng gặp hơn một lần ở các bạn dev trẻ tuổi. Dĩ nhiên, tôi không phải là bất đồng với suy nghĩ đó. Đã làm phần mềm là không được sợ khó. Bất cứ là việc gì, đầu tiên là phải suy nghĩ "Phải bắt tay vào làm". Dù thế nào, mình cũng sẽ làm được một điều gì đó, học được một điều gì đó.
Nhưng đôi khi, sự tự tin/tinh thần vượt khó sẽ dễ dàng biến thành những suy nghĩ chủ quan, khinh địch. Bạn trải qua một, hai dự án, bạn nghĩ bạn có thể hiểu được bất kỳ một domain nào. Bạn nghĩ, cứ làm là bạn sẽ thực sự hiểu những vấn đề chuyên môn khó nhằn của những ngành nghề mà bạn là người "ngoại đạo".
Bạn không nhận ra rằng đó cũng là những lĩnh vực mà người ta phải mất tới hàng chục năm để master.
Kết quả là đôi khi các developer sẽ đưa ra những lựa chọn thiết kế họ tưởng là hợp lý nhưng lại đi ngược lại với yêu cầu của khách hàng. Hoặc, tệ nhất là hết dự án rồi, họ chỉ hiểu được bề nổi của tảng băng mà vẫn nghĩ mình hiểu được phần chìm. Sang những dự án mới, những gì họ biết không thể giúp họ tiến sâu hơn vào những mảng kinh doanh cốt lõi (nhiều tiền hơn). Họ không thể biến mình thành một developer "không thể thiếu" của khách hàng.
Khi "đánh hơi" được những suy nghĩ chủ quan như vậy, tôi thường hỏi các bạn trẻ một câu: "Em thử nghĩ xem, nếu ai đấy không học phần mềm và họ hỏi 'API là gì', em sẽ trả lời như thế nào?".
API là gì?
Dĩ nhiên, tôi hỏi không phải là để biết các bạn hiểu về API như thế nào. Tôi cũng dám chắc rằng câu hỏi này không có câu trả lời đúng hoàn toàn, chính xác hoàn toàn. Cũng giống như những khái niệm khác của phần mềm, API cũng là một khái niệm có nhiều cách hiểu khác nhau.
Nhưng tôi lựa chọn API để yêu cầu các bạn dev giải thích cho kẻ ngoại đạo là bởi, nếu không phải là coder bạn sẽ rất, rất khó để hình dung ra API là gì, có vai trò rõ ràng như thế nào với một hệ thống phần mềm. Ngay cả khi công việc, cuộc sống của bạn xoay quanh các sản phẩm phần mềm như iOS, Android, Windows, Microsoft Office, Chrome... bạn vẫn phải là một người có hiểu biết nhất định về code để có thể thực sự hình dung ra khái niệm API.
Các ngành nghề khác cũng có những khái niệm như vậy. Bạn đã thử lên Wiki tiếng Anh đọc định nghĩa và mô tả của một căn bệnh nào đó? Bạn có thực sự hiểu các bản vẽ xây dựng để đưa ra các gợi ý giao diện chuẩn nhất? Đến cả một lĩnh vực tưởng như "thường thức" là kế toán, bạn có dám chắc bạn hiểu tất cả những gì khách hàng của bạn nói khi họ mô tả về hệ thống cân sổ họ cần có?
Để thực sự hiểu những lĩnh vực ấy, vài giờ ngồi code ở công ty là không đủ (bất kể đó là 10 giờ hay 12 giờ). Nếu bạn thực sự muốn thành một developer hiểu rõ về một lĩnh vực nào đó để biến mình thành tài sản vô giá trị với khách hàng của lĩnh vực đó, bạn buộc phải bỏ thêm thời gian để tìm hiểu cả về những ngành dọc mà mình sẽ tham gia.
Xu thế càng ngày càng đi sâu hơn, chuyên biệt hơn vào từng domain là xu thế tất yếu của ngành gia công phần mềm. Thực tế, tại các quốc gia như Mỹ hay Nhật, các thành viên cốt cán nhất của các bộ phận phần mềm tại các công ty không phải là phần mềm cũng luôn là những người đã gắn bó với công ty đó trong một thời gian dài. Họ không chỉ biết code, họ còn hiểu rất rõ về domain của công ty họ. Vậy nên họ quan trọng đến mức không thể bị thay thế.
Chúng ta đứng trước một cơ hội. Dev có thể thiếu ở Việt Nam nhưng không thiếu ở nước ngoài. Tìm một coder đã từng bay nhảy qua vài dự án, vài domain không hẳn là quá khó. Nhưng sự thật là nếu bạn thực sự sành sỏi về một domain, nhất là với những domain khó, bạn sẽ trở thành một tài sản vô cùng quý báu của cả công ty bạn và khách hàng của bạn.
Nguồn: Genk.vn