Đã đăng vào khoảng 21 giờ trước 16 phút đọc

[Chuyện nghề] Nhìn lại năm đầu tiên đi làm: 1 năm, 5 công nghệ và hành trình tìm ra "chìa khóa vạn năng"

Năm đầu tiên đi làm của tôi: Từ Oracle, Java đến C++ và bài học về khả năng thích nghi

Năm 2011, tôi bước chân vào nghề Software Developer.

Xuất phát điểm của tôi không phải là ngành Khoa học máy tính mà là Kỹ thuật máy tính (Computer Engineering). Khi còn là sinh viên, tôi cũng không nghĩ rằng sau này mình sẽ dành phần lớn thời gian để viết phần mềm.

Nhưng đi làm rồi mới hiểu một điều khá đơn giản:

Việc của mình, nếu mình không làm thì sẽ chẳng có ai làm giúp.

Không còn bài tập có đáp án, không còn giảng viên đứng bên cạnh chỉ từng bước. Có một vấn đề cần giải quyết thì phải tự tìm cách giải quyết.

Và năm đầu tiên đi làm của tôi bắt đầu bằng một chuỗi thay đổi công nghệ mà lúc đó tôi không hề nghĩ rằng nó lại trở thành một trong những nền tảng quan trọng nhất cho sự nghiệp sau này.

1. Món quà chào sân mang tên Oracle Database

Những ngày đầu tiên đi làm, nhiệm vụ đầu tiên tôi nhận được là cài đặt Oracle Database trên chiếc máy tính được công ty cấp.

Nghe thì có vẻ đơn giản.

Nhưng với một người mới ra trường, cầm trên tay một tập tài liệu hướng dẫn cài Oracle dày cộp, những thứ như environment variable, listener, tnsnames.ora, database instance... lúc đó chẳng khác gì một đống mật mã.

Tôi cứ cài.

Không được thì gỡ.

Rồi cài lại.

Không được nữa thì đọc lại tài liệu.

Rồi tiếp tục cài.

Sau vài ngày vật lộn, cuối cùng khoảnh khắc đáng nhớ cũng đến: công cụ PL/SQL Developer kết nối được vào database local.

Nhìn thấy dòng kết nối thành công lúc đó thực sự có cảm giác như vừa hoàn thành một dự án lớn.

Sau đó tôi tiếp tục làm việc với Oracle Forms & Reports, một công nghệ rất phổ biến trong các hệ thống doanh nghiệp thời điểm đó.

Nhìn lại, bài học đầu tiên tôi học được không phải là Oracle.

Mà là:

Đừng sợ một công nghệ mà mình chưa biết. Cứ bắt tay vào làm, gặp lỗi thì tìm nguyên nhân, làm lại cho đến khi hiểu.

Một công nghệ mới ban đầu có thể rất đáng sợ.

Nhưng khi đã tự tay cài đặt, cấu hình và xử lý được lỗi đầu tiên, nó bắt đầu trở nên quen thuộc.

2. Java, Play Framework và bài học "không giấu dốt"

Tôi chưa ngồi ở nhóm Oracle được bao lâu thì được chuyển sang nhóm Java.

Công việc ban đầu là phát triển ứng dụng desktop bằng Java.

Rồi chưa kịp quen với môi trường mới, cả nhóm lại chuyển hướng sang Play Framework để phát triển ứng dụng web.

Thời điểm đó Play Framework là một công nghệ khá mới đối với tôi.

Từ Java desktop chuyển sang web framework, cách suy nghĩ và cách tổ chức ứng dụng cũng thay đổi khá nhiều.

Nếu lúc đó cứ cố tỏ ra mình biết mọi thứ thì có lẽ tôi đã mất rất nhiều thời gian.

Tôi chọn một cách khác:

Không biết thì hỏi. Không hiểu thì nói là không hiểu.

Nghe rất bình thường, nhưng với một người mới đi làm, đây lại là một bài học khá quan trọng.

Ở trường, đôi khi chúng ta sợ hỏi vì sợ người khác nghĩ mình không giỏi.

Nhưng đi làm thì khác.

Nếu không hiểu một vấn đề mà cứ im lặng, cuối cùng vấn đề vẫn còn đó. Thậm chí có thể trở thành lỗi của cả hệ thống.

Tôi dần hình thành một thói quen:

Không sợ người khác biết mình chưa biết. Chỉ sợ mình không chịu tìm hiểu để biết.

3. PHP, MySQL, SharePoint và ASP.NET Web Forms

Tưởng rằng sau Java và Play Framework thì mọi thứ sẽ ổn định.

Không.

Công nghệ tiếp tục thay đổi.

Tôi được đưa vào một dự án cũ sử dụng PHP và MySQL.

Sau đó lại có cơ hội làm việc với SharePoint, rồi tiếp xúc với hệ sinh thái Microsoft như C# và SQL Server.

Và tất nhiên không thể thiếu những ứng dụng ASP.NET Web Forms với Page Lifecycle, ViewState và một loạt thứ mà nếu nhìn vào lần đầu tiên rất dễ cảm thấy... hơi choáng.

Nếu mỗi lần gặp công nghệ mới tôi đều nghĩ:

"Phải học lại từ đầu."

thì có lẽ tôi sẽ chẳng bao giờ học xong.

Đến thời điểm đó, tôi bắt đầu nhận ra một điều quan trọng hơn.

Công nghệ khác nhau nhưng bài toán thường giống nhau

Một ứng dụng cuối cùng vẫn phải:

nhận dữ liệu;
xử lý dữ liệu;
kiểm tra điều kiện;
thực hiện nghiệp vụ;
lưu dữ liệu;
trả kết quả cho người dùng hoặc hệ thống khác.

Ngôn ngữ có thể thay đổi.

Framework có thể thay đổi.

Database có thể thay đổi.

Nhưng logic của bài toán không thay đổi quá nhiều.

Từ đó, tôi bắt đầu tập trung nhiều hơn vào business logic thay vì chỉ tập trung vào cú pháp.

Ví dụ, thay vì chỉ hỏi:

"C# viết đoạn này như thế nào?"

tôi bắt đầu hỏi:

"Dữ liệu này từ đâu đến? Nó phải đi qua những bước nào? Điều kiện nào làm cho kết quả thay đổi? Nếu dữ liệu sai thì hệ thống phải xử lý thế nào?"

Đó là một thay đổi khá lớn trong cách tôi học lập trình.

4. Debug quan trọng hơn việc thuộc cú pháp

Một kỹ năng khác tôi học được trong giai đoạn này là debug.

Khi chương trình chạy sai, thay vì đoán:

"Có lẽ đoạn này sai."

tôi bắt đầu đặt breakpoint và đi theo dòng chảy của dữ liệu.

Biến này có giá trị gì?

Nó được truyền từ đâu?

Đến đây tại sao lại thành null?

Điều kiện này tại sao lại false?

SQL trả về dữ liệu gì?

Sau đó tôi nhận ra debug thực chất không chỉ là một tính năng của IDE.

Nó là một cách suy luận về hệ thống.

Bạn có một kết quả sai.

Bạn quay ngược lại:

Kết quả → dữ liệu → logic → input → nguyên nhân.

Càng debug nhiều, khả năng đọc code và suy luận hệ thống càng tốt.

Và kỹ năng này gần như không phụ thuộc vào việc bạn đang dùng Java, C#, PHP hay C++.

5. Từ Oracle đến MySQL, SQL Server: nhận ra những phần kiến thức có tính nền tảng

Sau khi làm việc với nhiều hệ quản trị cơ sở dữ liệu, tôi bắt đầu nhận ra rằng giữa chúng có một nền tảng chung khá lớn.

Các khái niệm như:

SELECT, INSERT, UPDATE, DELETE;
JOIN;
GROUP BY;
transaction;
index;
quan hệ giữa các bảng;
thiết kế dữ liệu;

đều có những điểm tương đồng rất rõ ràng.

Tất nhiên Oracle, MySQL, SQL Server hay các hệ quản trị khác vẫn có rất nhiều khác biệt về cú pháp, kiểu dữ liệu, transaction, optimizer, function/procedure và các tính năng riêng.

Nhưng một khi đã hiểu được bản chất của cơ sở dữ liệu và SQL, việc chuyển sang một hệ quản trị khác không còn đáng sợ như lúc mới bắt đầu.

Đây cũng là lúc tôi bắt đầu hiểu một nguyên tắc quan trọng:

Đừng chỉ học cách sử dụng một công cụ. Hãy cố hiểu vấn đề mà công cụ đó đang giải quyết.

Nếu hiểu được vấn đề, công cụ có thể thay đổi.

6. Trận chiến với Windows CE và 128 MB RAM

Nếu những công nghệ phía trên giúp tôi thay đổi cách học thì dự án tiếp theo lại dạy tôi một bài học khác hoàn toàn.

Đó là một hệ thống chạy trên thiết bị chuyên dụng nhận dạng vân tay.

Thiết bị sử dụng Windows CE 5.0, bộ nhớ RAM chỉ khoảng 128 MB, và phần mềm được phát triển bằng C++/MFC.

Ngày nay nhìn con số 128 MB có thể thấy rất nhỏ.

Nhưng thời điểm đó, đó là môi trường mà chúng tôi phải làm việc thực sự.

Ứng dụng có nhiệm vụ lấy dữ liệu vân tay, thực hiện đối soát cục bộ. Nếu không tìm thấy kết quả phù hợp thì gửi dữ liệu lên server thông qua API.

Vấn đề bắt đầu xuất hiện khi ứng dụng chạy trong thời gian dài.

Một lần crash.

Rồi thêm một lần nữa.

Có lúc chương trình đang chạy bình thường thì hệ điều hành kết thúc ứng dụng.

Nguyên nhân không phải lúc nào cũng rõ ràng.

Với môi trường desktop hiện đại, chúng ta có rất nhiều công cụ hỗ trợ profiling và theo dõi memory.

Nhưng trong môi trường thiết bị hạn chế lúc đó, việc tìm lỗi memory leak không hề dễ dàng.

Tôi phải dựa rất nhiều vào debug, theo dõi từng đoạn code cấp phát và giải phóng bộ nhớ, quan sát trạng thái của chương trình rồi suy luận xem vấn đề có thể nằm ở đâu.

Có những lỗi tưởng như rất nhỏ.

Một vùng nhớ được cấp phát nhưng không giải phóng đúng cách.

Một con trỏ bị giữ lại lâu hơn dự kiến.

Một luồng xử lý tạo ra dữ liệu nhưng vòng đời của nó không được quản lý tốt.

Trong môi trường bộ nhớ hạn chế, những lỗi nhỏ như vậy có thể nhanh chóng biến thành lỗi lớn.

Sau rất nhiều lần chương trình crash, tôi dần hình thành một thói quen mà sau này vẫn còn sử dụng:

Đừng coi tài nguyên máy tính là vô hạn.

CPU mạnh hơn.

RAM nhiều hơn.

SSD nhanh hơn.

Nhưng điều đó không có nghĩa là chúng ta có thể viết phần mềm một cách thiếu trách nhiệm.

Đặc biệt với những hệ thống xử lý dữ liệu lớn hoặc chạy lâu dài, việc quản lý bộ nhớ, tài nguyên, connection, file handle, thread... vẫn rất quan trọng.

7. Vậy "chiếc chìa khóa vạn năng" là gì?

Nhìn lại năm đầu tiên đi làm, nếu hỏi tôi đã học được bao nhiêu công nghệ thì có lẽ tôi sẽ không nhớ chính xác.

Oracle.

Java.

Play Framework.

PHP.

MySQL.

SharePoint.

C#.

SQL Server.

ASP.NET Web Forms.

C++/MFC.

Windows CE.

Có vẻ khá nhiều.

Nhưng đó không phải thứ quan trọng nhất tôi nhận được.

Điều quan trọng hơn là tôi bắt đầu hiểu rằng:

Một lập trình viên không nên phụ thuộc hoàn toàn vào một ngôn ngữ, một framework hay một database.

Công nghệ rồi sẽ thay đổi.

Framework từng rất hot có thể một ngày nào đó trở thành công nghệ cũ.

Database có thể thay đổi.

Ngôn ngữ lập trình có thể thay đổi.

Nhưng một số năng lực nền tảng vẫn đi theo chúng ta rất lâu.

Đối với tôi, đó là ba thứ:

1. Hiểu bài toán và luồng nghiệp vụ

Trước khi nghĩ đến code, hãy hiểu hệ thống cần làm gì.

2. Biết debug và suy luận

Khi hệ thống sai, đừng đoán mò.

Hãy đi từ kết quả ngược về nguyên nhân.

3. Không giấu dốt

Không biết thì hỏi.

Chưa hiểu thì tìm hiểu.

Gặp công nghệ mới thì bắt tay vào làm.

Không cần phải biết tất cả ngay từ đầu.

8. Nhìn lại sau nhiều năm

Bây giờ nhìn lại những ngày đầu đó, tôi thấy mình khá may mắn.

Không phải vì tôi được làm những công nghệ "hot" nhất.

Thực tế có những công nghệ trong số đó bây giờ gần như đã đi vào lịch sử.

Tôi may mắn vì đã được đặt vào những tình huống buộc mình phải học cách thích nghi.

Một ngày có thể làm Oracle.

Ngày khác làm Java.

Rồi PHP, C#, SQL Server.

Sau đó lại nhảy sang C++ trên một thiết bị chỉ có 128 MB RAM.

Nếu lúc đó tôi chỉ quan tâm:

"Công nghệ này có còn hot không?"

thì có lẽ tôi đã bỏ lỡ rất nhiều bài học.

Bởi cuối cùng, thứ còn lại không phải là tên của framework.

Mà là cách mình giải quyết vấn đề.

Kết

Nếu có một điều tôi muốn nói với những bạn mới bước vào nghề Software Development, thì đó là:

Đừng cố trở thành người giỏi một ngôn ngữ nhất. Hãy cố trở thành người có khả năng giải quyết vấn đề bằng nhiều công cụ khác nhau.

Bạn có thể bắt đầu với Java.

Sau đó chuyển sang C#.

Có thể một ngày phải đọc Python.

Một ngày khác phải xử lý SQL.

Hoặc thậm chí phải mở một project C++ cũ mà mình chưa từng nhìn thấy.

Điều đó không đáng sợ.

Bởi nếu bạn hiểu bài toán, biết cách đọc code, biết debug và quan trọng nhất là biết cách tự học, thì việc học thêm một công nghệ mới chỉ là vấn đề về thời gian.

Công nghệ có thể thay đổi rất nhanh.

Khả năng thích nghi mới là thứ đi cùng một lập trình viên lâu dài.