#1percentbetter

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.

Không có một LLM nào tốt nhất cho mọi use case. Dùng nhiều models - đúng model, đúng task - là pattern đang emerge trong production AI systems. Đây là framework tôi đang dùng sau nhiều tháng thực chiến.

Azure Event Hub không phải message queue - đây là streaming platform. Sự khác biệt này ảnh hưởng đến mọi design decision. Bài này là architecture và code cho order processing pipeline dùng Event Hub - từ kinh nghiệm thực tế.

Tôi từng review code như một "quality gate" - tìm lỗi, reject, approve. Sau một sự việc với junior developer, tôi hiểu ra: Code review là opportunity tốt nhất để mentor mà không cần lên lịch buổi 1-on-1 riêng.

Read replica và sharding đều là cách scale database - nhưng giải quyết hai vấn đề hoàn toàn khác nhau. Chọn nhầm thì sau này migrate cực kỳ đau. Đây là cách tôi quyết định, dựa trên kinh nghiệm thực tế.

Mỗi lần có technology wave lớn, lại có câu hỏi "programmer có bị thay thế không?". Tôi đã chứng kiến 4-5 waves như vậy trong 20 năm. Câu trả lời luôn là: kỹ năng nào bị thay thế, kỹ năng nào lên giá trị. Và lần này với AI cũng không khác.