Nhật ký kỹ sư, Sydney (2026)

26/06/2026

Góc làm việc vẫn vậy.
Dây điện vẫn rối.
Sticky note vẫn đầy.
Bugs vẫn nhiều hơn tiền trong tài khoản ngân hàng. 😂

Mục tiêu từ giờ đến cuối năm rất đơn giản:
📈 Có thêm nhiều người dùng.
💰 Kiếm được thêm doanh thu.
✈️ Và hy vọng đủ tiền bay về Việt Nam ăn Tết cùng gia đình.

Chặng đường mới chính thức bắt đầu! 🚀

05/06/2026

Hard work paid off with a dream WWDC26 ticket in hand. 

24/05/2026

Có một loại bug mà hầu như ai cũng đã từng gặp phải - không phải vì không biết xử lý, mà vì quên xử lý.

Bạn mở file, đọc dữ liệu, rồi return sớm vì có lỗi. File vẫn đang mở. Không ai đóng nó lại.

defer sinh ra để giải quyết đúng vấn đề này. Block code bên trong defer sẽ luôn chạy khi scope kết thúc - dù function return bình thường, return sớm, hay throw error. Không có ngoại lệ.

Thay vì phải nhớ gọi closeFile() ở mọi exit point, bạn khai báo một lần ngay sau khi mở file. Từ đó không cần nghĩ đến nó nữa - defer lo phần còn lại.

Nhưng defer không chỉ dùng cho file. Bất cứ thứ gì cần được dọn dẹp sau khi scope kết thúc đều là ứng viên:
- Loading state là ví dụ điển hình. Bạn set isLoading = true trước khi gọi API, rồi phải set lại false sau khi xong — dù request thành công hay throw error. Đặt defer { isLoading = false } ngay sau dòng set true, mọi thứ tự động về đúng trạng thái.
- Lock/unlock, begin/commit transaction, start/stop tracking — tất cả đều theo pattern này. Mở ở đầu, đóng ở defer, không bao giờ quên.

Một điều ít người để ý: nếu bạn có nhiều defer trong cùng một scope, chúng chạy theo thứ tự ngược lại - cái khai báo sau chạy trước. Giống như stack. Hiểu điều này giúp bạn tránh được những bug thứ tự cleanup rất khó trace.

defer là một trong những keyword thể hiện rõ nhất triết lý của Swift: làm cho ý định của bạn tường minh ngay tại chỗ khai báo, thay vì phân tán logic cleanup ra khắp function.

Bạn đang dùng defer cho pattern nào trong project hiện tại? Hãy cùng nhau chia sẻ phía dưới phần cmt nhé 👇

24/05/2026

Nhiều iOS dev dùng `` để tắt warning của compiler.

Cách đó không hẳn sai, nhưng nếu chỉ xem nó là “công cụ tắt warning” thì rất dễ dùng sai chỗ.

Trong Swift, khi một function trả về giá trị, compiler mặc định muốn caller phải quan tâm đến giá trị đó. Warning không xuất hiện để làm phiền bạn, mà để nhắc rằng: “Kết quả này có thể quan trọng, đừng vô tình bỏ qua nó.”

`` nên được hiểu như một cách khai báo ý định thiết kế của function: “Function này chủ yếu tạo ra side effect. Return value chỉ là thông tin phụ. Caller muốn dùng hay bỏ qua đều hợp lý.”

Ví dụ, `saveToCache()` tồn tại chủ yếu để lưu dữ liệu vào cache.

Nó có thể trả về `Bool` để báo lưu thành công hay thất bại. Nhưng trong nhiều trường hợp, caller chỉ cần gọi để lưu cache rồi đi tiếp. Nếu cần kiểm tra kết quả thì kiểm tra, không cần thì bỏ qua cũng ổn.

→ Đây là một case hợp lý cho ``.

Nhưng `withdraw()` thì khác.

Một function rút tiền mà trả về `true/false` để báo thành công hay thất bại thì kết quả đó không còn là thông tin phụ nữa. Nó là một phần quan trọng của business logic.

Nếu caller bỏ qua kết quả, app vẫn compile, vẫn chạy, nhưng logic có thể sai trong im lặng.

Với những case như vậy, `throws` hoặc `Result` thường phù hợp hơn, vì compiler sẽ buộc caller phải đối mặt với cả hai trường hợp: thành công và thất bại.

Cái nguy hiểm của việc dùng sai `` là nó không làm app crash ngay.

Nó chỉ âm thầm cho phép những kết quả quan trọng bị bỏ qua, rồi bug xuất hiện ở nơi khó debug nhất: production.

Một annotation rất nhỏ, nhưng nó nói khá nhiều về cách bạn thiết kế API:

Function này chủ yếu để tạo side effect?

Hay return value mới là thứ caller bắt buộc phải xử lý?

Trong codebase của bạn, có `` nào đang được dùng chỉ để che đi một warning đáng ra nên được xử lý không?

23/05/2026

Mình đã được mời tham dự WWDC26 tại Apple Park. 

Khi đọc xong email đó, mình đã ngồi lặng đi một lúc khá lâu.

Không phải vì đây là một sự kiện công nghệ lớn, mà bởi vì khoảnh khắc ấy khiến mình nhớ lại toàn bộ hành trình đã đi qua để theo đuổi con đường iOS Engineering.

Mình vẫn còn nhớ những ngày đầu tiên học lập trình iOS - mở Xcode lên nhưng gần như không hiểu gì về storyboard, architecture hay vòng đời của một ứng dụng. Những lần build failed liên tục, những đêm ngồi debug đến rất khuya chỉ để sửa một issue rất nhỏ, hay cảm giác áp lực khi nhận ra càng học thì càng thấy bản thân còn quá nhiều điều chưa biết.

Software engineering chưa bao giờ là một công việc dễ dàng hay hào nhoáng như nhiều người vẫn nghĩ. Phía sau một ứng dụng hoạt động ổn định là rất nhiều giờ làm việc âm thầm, rất nhiều lần xử lý production issues, rất nhiều áp lực phải liên tục học hỏi để không bị bỏ lại phía sau trong một ngành thay đổi từng ngày.

Tuy vậy, đây cũng là công việc mang lại cho mình rất nhiều cảm xúc đặc biệt.
- Đó là cảm giác khi những dòng code mình viết ra thực sự hoạt động.
- Là cảm giác khi một sản phẩm mình xây dựng có người sử dụng.
- Và cũng là cảm giác mỗi ngày bản thân đang tiến thêm một chút trên con đường mình đã lựa chọn.

Vì vậy, lời mời từ Apple ngày hôm nay, đối với mình, không chỉ đơn thuần là một tấm vé tham dự WWDC. Nó giống như một cột mốc để nhìn lại và tự nhắc bản thân rằng những nỗ lực, áp lực và sự kiên trì trong suốt thời gian qua đều hoàn toàn xứng đáng.

Từ một người bắt đầu bằng những video tutorial trên Internet, đến hôm nay có cơ hội đặt chân tới Apple Park - nơi mà trước đây mình chỉ từng thấy qua các keynote và Apple Events.

Mình biết phía trước vẫn còn rất nhiều điều phải học, rất nhiều mục tiêu cần theo đuổi và rất nhiều thử thách đang chờ đợi. Nhưng có lẽ, đây sẽ là một trong những kỷ niệm đáng nhớ nhất trong hành trình làm iOS của mình.

See you at WWDC26. 

19/05/2026

Bỏ phố về quê, mình nuôi bò và trồng thêm rau 🐂 🌱

17/05/2026

Xin chào mọi người, chào các anh em kỹ sư nói chung và kỹ sư phần mềm nói riêng 😃

Mình hiện đang là một Software Engineer làm việc tại Sydney, Australia.

Sau một khoảng thời gian học tập và đi làm, mình nhận ra nghề kỹ sư phần mềm có rất nhiều điều để kể. Không chỉ là code, công nghệ hay những dòng log khó hiểu, mà còn là áp lực, cảm xúc, những lần bế tắc, những bài học lớn nhỏ và cả hành trình trưởng thành của mỗi người trong nghề.

Càng học nhiều, mình càng thấy bản thân biết quá ít.

Càng đi làm lâu, mình càng hiểu software engineering không đơn giản chỉ là ngồi viết code mỗi ngày. Đó còn là việc học cách giải quyết vấn đề, học cách chịu trách nhiệm với những gì mình làm ra, học cách làm việc cùng đồng đội, và đôi khi là học cách bình tĩnh giữa những deadline, production issue hay những ngày mọi thứ không diễn ra như mong muốn.

- Có những ngày ngồi trước màn hình hàng giờ chỉ để tìm ra một lỗi rất nhỏ.

- Có những khoảng thời gian áp lực tới mức chỉ nhìn vào laptop thôi cũng thấy mệt.

- Cũng có những đêm đã tắt máy đi ngủ nhưng trong đầu vẫn nghĩ về công việc, về bug chưa fix xong hay một feature còn dang dở.

Nhưng đổi lại, ngành này cũng mang đến rất nhiều cảm giác mà có lẽ chỉ những người làm kỹ thuật mới hiểu được.

- Đó là cảm giác vui khi giải quyết được một vấn đề khó sau nhiều ngày loay hoay.

- Là những lần cùng đồng đội thức khuya để chạy deadline.

- Là những cuộc trò chuyện rất dài về công nghệ, sự nghiệp và tương lai.

- Và cũng là cảm giác bản thân đang tốt hơn một chút sau mỗi lần vượt qua khó khăn.

Mình tạo ra page này như một góc nhỏ để chia sẻ lại những điều đó - những câu chuyện đi làm, những bài học engineering, những trải nghiệm trong nghề, những lúc stress vì production, vài dòng tâm sự lúc nửa đêm, và cả những meme mà chắc chỉ dân kỹ thuật mới hiểu 😄

Nếu bạn cũng đang học code, đang đi làm, hoặc đang cố gắng trở thành một kỹ sư tốt hơn mỗi ngày, thì hy vọng chúng ta có thể đồng hành cùng nhau ở đây.

Chào mừng bạn đến với “Nhật ký kỹ sư” ☕

Nếu những nội dung trên page phù hợp với bạn, đừng quên follow và like page để ủng hộ mình nhé 👋

Nhật ký kỹ sư

26/06/2026

05/06/2026

24/05/2026

24/05/2026

23/05/2026

19/05/2026

17/05/2026

Address

Website

Alerts

Shortcuts

Share

Category