Tôi sẽ học gì trước, nếu được bắt đầu lại từ đầu theo kiểu tự học

Tôi tự học lập trình mà không có nền tảng nào trong ngành. Swift là ngôn ngữ đầu tiên, học từ các bài blog, khóa học miễn phí và YouTube, và tôi bắt đầu công việc đầu tiên vào tháng 3 năm 2022.

Bốn năm sau, những lỗ hổng thật sự khiến tôi trả giá không phải những thứ tôi dành cả buổi tối để lo lắng. Đây là điều tôi sẽ nói với chính mình lúc mới bắt đầu.

Những thứ không quan trọng như tôi từng sợ

Không có bằng đại học. Nó xuất hiện đúng một lần trong một buổi phỏng vấn, dưới dạng câu hỏi về cách tôi học chứ không phải một lời phản đối. Thứ người ta hỏi là công việc — một ứng dụng đã phát hành, đoạn code họ đọc được.

Không biết sâu về thuật toán. Tôi đã không viết nổi một cây đỏ đen và chuyện đó chưa bao giờ cần đến. Biết rằng một lượt tra bảng băm là O(1) còn một lượt quét tuyến tính là O(n) — và để ý khi một cái nằm lồng trong một vòng lặp — thì cần đến liên tục. Đó là một khối kiến thức nhỏ hơn nhiều so với những gì chữ “thuật toán” gợi ra.

Không biết ngôn ngữ thứ hai sớm. Tôi từng thấy mình tụt lại vì chỉ biết Swift. Trong thực tế, đào sâu một ngôn ngữ dạy tôi nhiều ý tưởng chuyển giao được hơn là một chuyến dạo nông qua bốn ngôn ngữ.

Những thứ quan trọng hơn nhiều so với tôi tưởng

1. Cái máy thật sự hoạt động ra sao

Lỗ hổng lớn nhất. Không phải hợp ngữ — mà là hình dạng của mọi thứ.

Con trỏ là gì. Vì sao cấp phát trên ngăn xếp thì rẻ còn cấp phát trên heap thì không. Một dòng cache là gì và vì sao duyệt một mảng nhanh hơn lần theo một danh sách liên kết. Một lời gọi hệ thống tốn gì. Vì sao sao chép một mảng lớn chậm hơn sao chép một tham chiếu tới nó.

Không có những thứ này thì “hiệu năng” là một tập quy tắc học thuộc. Có chúng rồi thì phần lớn câu hỏi về hiệu năng trở thành thứ bạn lập luận được từ nguyên lý đầu tiên. Nó cũng khiến những phần của Swift trông có vẻ tùy tiện — copy-on-write, ngữ nghĩa giá trị, inout, ARC — trở nên hiển nhiên là cần thiết.

Thứ tôi sẽ đọc: Computer Systems: A Programmer’s Perspective, đọc chậm, sáu chương đầu. Hoặc xây một thứ nhỏ bằng C hay Rust, nơi chẳng có gì bị giấu đi.

2. Git, cho tử tế

Tôi dùng add, commit, push, pull suốt hai năm, và mọi tình huống bất thường đều là một cuộc khủng hoảng.

Học được một commit thật ra là gì — một bản chụp cộng một con trỏ tới cha — khiến rebase, cherry-pick, reflog và bisect đều trở thành hệ quả hiển nhiên chứ không còn là bốn câu thần chú riêng biệt. Nó tốn một buổi chiều và nó dẹp đi một nỗi sợ âm ỉ tái diễn.

Riêng git reflog đã cứu tôi nhiều lần hơn tôi đếm nổi. Bạn không thể mất công việc đã commit, và việc không biết điều đó lấy đi giấc ngủ của bạn.

3. Kiểm thử, và cụ thể là kiểm thử cái gì

Tôi không viết test nào suốt một năm, rồi viết test tệ suốt một năm nữa — khẳng định rằng một getter trả về đúng thứ mà setter vừa đặt vào.

Thứ tôi ước mình học sớm hơn là một bài test là một công cụ thiết kế trước khi nó là một lưới an toàn. Code khó kiểm thử thường là code có các phụ thuộc rối vào nhau, và bài test đang nói cho bạn biết về thiết kế. Việc muốn viết một bài test cho tầng mạng chính là thứ đã dạy tôi tiêm phụ thuộc, hiệu quả hơn mọi bài viết về tiêm phụ thuộc.

Quy tắc giúp nhiều nhất: hãy kiểm thử thứ mà nếu nó hỏng thì bạn sẽ ngượng. Không phải độ phủ — mà là hậu quả.

4. Đọc code của người khác

Tôi né các codebase lớn suốt nhiều năm vì chúng đáng sợ. Đó là một sai lầm, và khi sửa nó thì đó là thói quen làm thay đổi tốc độ tiến bộ của tôi nhiều nhất.

Thư viện chuẩn của Swift đọc được. Phần lớn swift-corelibs cũng vậy, và mọi package mã nguồn mở được bảo trì tử tế cũng thế. Đọc phần cài đặt của Array dạy tôi về copy-on-write trong một giờ nhiều hơn một tuần đọc blog.

Kỹ năng ở đây không phải đọc cả một codebase. Nó là chọn một hàm bạn dùng hằng ngày rồi lần theo nó xuống hai tầng.

5. Viết

Khả năng giải thích một quyết định kỹ thuật bằng văn xuôi rõ ràng đã ảnh hưởng tới sự nghiệp của tôi nhiều hơn bất kỳ kỹ năng kỹ thuật đơn lẻ nào.

Phần mô tả pull request, báo cáo lỗi, một tài liệu thiết kế khiến cả phòng đồng ý, một email khiến khách hàng gửi đúng thông tin bạn cần. Và giải thích một thứ là cách nhanh nhất để phát hiện ra bạn chưa hiểu nó — đó cũng là phần lớn lý do website này tồn tại.

Thứ tự tôi sẽ làm

1. Phát hành một thứ gì đó. Một thứ nhỏ, hoàn chỉnh, đã công bố thì hơn sáu tháng học tutorial. Việc hoàn tất dạy bạn những phần chẳng ai làm khóa học — phát hành, sự cố, người dùng làm những điều bạn không lường trước.
2. Rồi đi xuống một tầng với bất cứ thứ gì bạn vừa dùng. Bạn dùng một cơ sở dữ liệu — chỉ mục là gì? Bạn dùng một thư viện mạng — bắt tay TCP là gì?
3. Rồi học công cụ cho tử tế. Git, trình gỡ lỗi, trình đo hiệu năng. Mỗi thứ tốn một ngày và mỗi thứ hoàn vốn hằng tuần.
4. Rồi một ngôn ngữ thứ hai, cố tình chọn thứ khác hẳn cái đầu. Swift rồi Rust dạy tôi đâu là Swift và đâu là lập trình. Swift rồi Kotlin đã dạy tôi ít hơn nhiều.

Thứ quan trọng nhất

Sự đều đặn thắng sự dữ dội, và không sát sao chút nào. Một giờ mỗi ngày trong một năm là khoảng 365 giờ và nó cộng dồn lãi; một cuối tuần mười bốn tiếng là 14 giờ và bạn nhớ được rất ít.

Sau bốn năm, tôi vẫn chủ yếu đang lấp các lỗ hổng, và tôi cho rằng điều đó sẽ đúng vĩnh viễn. Hóa ra đó là trạng thái bình thường của nghề này chứ không phải triệu chứng của việc đã bắt đầu mà không có bằng cấp — và đó là điều tôi mong được biết nhất lúc mới bắt đầu.