Sau 20 năm trong ngành và 7+ năm làm tech lead, tôi nhận ra: mentoring junior developers không phải là dạy code, mà là dạy cách suy nghĩ. Nếu bạn chỉ giải quyết các vấn đề cho họ, bạn đang cướp đi cơ hội để họ trở thành independent engineer. Thực ra cách lớn nhất để giúp junior phát triển là cùng học cách giải quyết vấn đề, chứ không phải đưa câu trả lời sẵn.
Không có database "tốt hơn". Có database phù hợp hơn với context của bạn. Tôi dùng SQL Server 20 năm và PostgreSQL 5 năm - cả hai đều excellent, nhưng chúng khác nhau ở những trade-off quan trọng mà architect cần hiểu rõ. Năm 2019, tôi nhận một project mới - một startup fintech đang xây MVP. Họ hỏi tôi: "Anh Son, chúng tôi nên dùng database gì?" Câu hỏi đơn giản. Nhưng tôi không trả lời ngay. Thay vào đó, tôi hỏi lại: "Tech stack của team là gì? Ai sẽ maintain database này sau khi tôi đi? Infrastructure của các bạn là on-premise hay cloud? Budget cho licensing là bao nhiêu?" Họ nhìn tôi hơi ngớ ngẩn. Họ expected một câu trả lời technical - benchmark performance, feature comparison. Tôi lại hỏi về organization và budget. Vì đó mới là thứ thực sự quyết định.
Cache thì dễ thêm vào. Nhưng khi product price thay đổi lúc 11:59 PM trước flash sale lúc 12:00 AM, bạn mới biết cache invalidation khó như thế nào. Bài này đi sâu vào các pattern thực tế và code C# cho product catalog. Phil Karlton có câu nói nổi tiếng: "There are only two hard things in Computer Science: cache invalidation and naming things." Tôi thêm vào: cache invalidation trong e-commerce còn khó hơn cache invalidation ở chỗ khác. Vì trong e-commerce, data thay đổi liên tục - price, stock, promotion - và mỗi inconsistency đều có thể cost bạn money (hoặc cost khách hàng).
Câu trả lời không phải là "có" hay "không" - mà là "code để làm gì". Technical leader cần code đủ để giữ credibility, hiểu trade-off, và không bị sold bởi solutions không phù hợp. Nhưng nếu bạn vẫn code như developer, bạn đang làm sai vai trò. Năm 2019, tôi được promote lên tech lead cho một dự án lớn. Tuần đầu tiên, tôi vẫn code 8 tiếng một ngày như developer. Tôi nghĩ đó là cách đúng - lead by example, lead from the front, v.v. Sau 3 tháng, team tôi frustrated. Không phải vì tôi code tệ. Mà vì: Architecture review bị chậm - tôi bận code feature Họ không có ai unblock khi bị stuck - tôi đang "in the zone" Planning meeting không có đủ context từ stakeholders - tôi không có thời gian 1:1 với business Code review của tôi cực kỳ opinionated về style thay vì về design Một senior dev trong team - người mà tôi trust nhất - nói thẳng với tôi: "Anh Son, anh đang là developer giỏi nhất trong team. Nhưng team cần tech lead, không cần developer giỏi nhất." Câu đó như một gáo nước lạnh.
Conway's Law nói rằng hệ thống bạn build sẽ phản chiếu cấu trúc tổ chức của team. Đây không phải lý thuyết học thuật - đây là lý do tại sao microservices nhiều dự án VN thất bại, và tại sao đôi khi cần thay đổi org chart trước khi thay đổi architecture. Năm 2021, tôi bắt đầu làm tư vấn cho một công ty fintech. Họ muốn chuyển từ monolith sang microservices - xu hướng lúc đó ai cũng nói về. Tôi vào, review codebase, rồi nhìn sang org chart. Và tôi thấy ngay. Monolith của họ có 3 module lớn: Accounting, Lending, và Customer Management. Org chart của họ cũng có 3 team tương ứng: Team Kế toán, Team Tín dụng, và Team Khách hàng. Ba team này không nói chuyện với nhau nhiều - mỗi team có lead riêng, backlog riêng, sprint riêng. Tôi đoán trước microservices của họ sẽ trông như thế nào nếu họ tự migrate: đúng 3 service, tương ứng với 3 team. Không nhiều hơn, không ít hơn. Và đó chính xác là điều xảy ra sau 6 tháng họ tự làm trước khi gọi tôi vào. 3 services, ranh giới business không đúng, coupling vẫn còn đầy, chỉ là coupling giờ đi qua HTTP thay vì function call. Distributed monolith - thứ tệ nhất của cả hai thế giới. Conway's Law đã xảy ra, nhưng không ai để ý.
Lên CEO không có nghĩa là ngừng học kỹ thuật - nhưng cách học phải thay đổi hoàn toàn. Tôi không còn đọc từng dòng tutorial, tôi học theo chiều rộng trước, sâu khi cần thiết, và luôn kết nối kiến thức mới với bài toán thực của công ty. Tháng 9 năm ngoái, trong cuộc họp với team engineering, một junior dev hỏi tôi: "Anh Son, anh có biết về Temporal workflow không? Em đang nghiên cứu cho dự án mới." Tôi dừng lại. Temporal. Tôi nghe tên rồi, nhưng chưa đủ để có ý kiến kỹ thuật. Và trong đầu tôi lúc đó có hai lựa chọn: giả vờ biết (không nên), hoặc thừa nhận và học nhanh (đúng hơn). Tôi nói: "Anh chưa deep dive vào Temporal. Em brief cho anh 5 phút, rồi mình xem fit không với dự án này." Sau cuộc họp đó, tôi dành 2 tối để đọc về Temporal. Không đủ để code được, nhưng đủ để có quan điểm architectural, đủ để hỏi câu hỏi đúng, đủ để không bị "sold" bởi một giải pháp không phù hợp. Đó là cách tôi học công nghệ mới ở tuổi này - ở vai trò này.
TDD (Test-Driven Development) thường được khen ngợi như silver bullet. Tôi áp dụng thực sự trong 6 tháng trên một production project và có kết quả... mixed. Đây là honest assessment từ người đã làm.