Embedded

Có một ngày, người quản lý giao cho tôi một tính năng mới.Anh ấy chỉ nói rất đơn giản:"Em thử thiết kế phần này trước nhé."Tôi ngồi trước màn hình gần cả buổi sáng.Không phải vì bài toán quá khó.Mà vì tôi không biết phải bắt đầu từ đâu.Suốt nhiều năm trước đó, công việc của tôi là đọc requirement, tạo vài file mới rồi bắt đầu viết code. Khi gặp bug thì debug, khi thiếu tài liệu thì đọc datasheet, khi hiệu năng chưa tốt thì tối ưu.Tôi khá tự tin với khả năng lập trình của mình.Nhưng lần đầu tiên phải tự thiết kế một hệ thống, tôi mới nhận ra mình hoàn toàn lúng túng.Tôi không biết nên chia module như thế nào.Không biết module nào nên chịu trách nhiệm cho việc gì.Không biết có bao nhiêu state trong hệ thống.Càng không biết vì sao nên chọn một kiến trúc này thay vì một kiến trúc khác.Điều đáng buồn là... không ai dạy những điều đó.Tôi làm trong lĩnh vực Embedded Software.Ở trường đại học, chúng tôi học cấu trúc dữ liệu, giải thuật, vi điều khiển, hệ điều hành...Đi làm, chúng tôi học framework, protocol, RTOS, Linux...Nhưng rất ít nơi dạy cách biến một yêu cầu của khách hàng thành một bản thiết kế có thể triển khai.Trong nhiều năm, tôi từng nghĩ:"Chắc mình code chưa đủ giỏi."Thế là tôi tiếp tục học.Học ngôn ngữ mới.Học framework mới.Học cách tối ưu từng dòng code.Nhưng càng học, tôi càng nhận ra vấn đề của mình không nằm ở coding.Một lập trình viên có thể viết một hàm rất đẹp - Nhưng trước đó, phải có ai quyết định rằng hàm đó nên tồn tại.Một lập trình viên có thể tối ưu bộ nhớ rất tốt - Nhưng trước đó, phải có ai quyết định cách chia dữ liệu.Một lập trình viên có thể implement state machine hoàn hảo - Nhưng trước đó, phải có ai xác định hệ thống có những state nào.Code luôn là bước cuối cùng.Điều khó hơn nhiều là những quyết định diễn ra trước khi dòng code đầu tiên được viết.Khoảng một năm trở lại đây, tôi thay đổi hoàn toàn cách học.Tôi bắt đầu đọc về software architecture thay vì framework.Tìm hiểu state machine thay vì chỉ học API.Quan tâm đến trách nhiệm của từng module thay vì chỉ quan tâm hàm nên viết ở file nào.Thậm chí tôi còn tự xây cho mình một checklist để mỗi khi nhận một feature mới, tôi có thể tự hỏi:Hệ thống này thực sự đang giải quyết vấn đề gì?Có những actor nào?Những state nào sẽ xuất hiện?Event nào làm hệ thống chuyển trạng thái?Module nào nên chịu trách nhiệm?Thành phần nào có thể thay đổi trong tương lai?Ban đầu, việc trả lời những câu hỏi này mất rất nhiều thời gian.Nhưng càng làm, tôi càng nhận ra mình không còn lao vào code ngay nữa.Tôi dành nhiều thời gian hơn để suy nghĩ.Và điều thú vị là tổng thời gian hoàn thành công việc lại ngắn hơn.Ít bug hơn.Ít phải sửa đi sửa lại hơn.Ít tranh luận hơn khi review.Rồi AI xuất hiện.Nhiều người hỏi:"AI viết code tốt như vậy thì lập trình viên còn giá trị gì nữa?"Tôi nghĩ AI khiến tôi nhận ra một điều.Nếu giá trị của tôi chỉ nằm ở việc viết code nhanh, thì sớm hay muộn AI cũng sẽ làm tốt hơn.Nhưng AI vẫn cần một người xác định đúng bài toán.Nó cần ai đó hiểu sản phẩm.Hiểu người dùng.Hiểu những ràng buộc về hiệu năng, bộ nhớ, chi phí và khả năng bảo trì.Nó có thể đề xuất nhiều giải pháp.Nhưng người chịu trách nhiệm chọn một giải pháp phù hợp vẫn là kỹ sư.Có lẽ đó mới là giá trị khó thay thế nhất.Nhìn lại chặng đường của mình, tôi không còn tin rằng chỉ cần code giỏi là đủ.Coding rất quan trọng.Nó là nền tảng.Nhưng nó không phải là tất cả.Khi sự nghiệp phát triển, chúng ta sẽ dành ít thời gian hơn để gõ bàn phím và nhiều thời gian hơn để phân tích, thiết kế, giao tiếp, đưa ra quyết định và chịu trách nhiệm cho những quyết định đó.Có một câu mà tôi rất thích:Code is easy. Deciding what to build is hard.

Trong thế giới IT đầy rẫy những từ khóa thời thượng như AI, Blockchain hay Cloud, có một nghịch lý đang tồn tại: Chúng ta có quá nhiều thông tin nhưng lại quá ít định hướng.Với tư cách là một người từng đứng ở vạch xuất phát từ kỹ thuật (DevOps) đến quản trị, tôi thấu hiểu nỗi hoang mang của những sinh viên năm cuối hay các bạn Junior. Câu hỏi không còn là "Học cái gì?", mà là "Lộ trình nào dành riêng cho tôi?".1. Bối cảnh: Khủng hoảng định hướng trong "thời đại thừa thãi"Google có thể trả về 10 triệu kết quả cho từ khóa "Lộ trình học Data", nhưng nó không thể nói cho bạn biết liệu với nền tảng Python hiện tại, bạn nên rẽ hướng sang AI hay tập trung vào Data Pipeline.Sinh viên: Mắc kẹt giữa việc "theo trend" hay học căn bản.Junior: Bị kẹt ở ngưỡng "mãi không lên được Mid-level" vì thiếu một vài mảnh ghép kỹ năng mà chính họ cũng không nhận ra.2. Giải pháp: AI Career Copilot – Không chỉ là gợi ý, đó là sự đo lườngTôi đề xuất một concept hệ thống AI Career Copilot. Đây không phải là một chatbot trả lời suông, mà là một công cụ phân tích dữ liệu thực tế dựa trên 3 bước:Bước 1 (Input): Thu thập "dấu vết số" của ứng viên từ CV, GitHub Repositories và kỹ năng hiện có.Bước 2 (Processing): Sử dụng NLP & Embedding để trích xuất thực thể kỹ năng, sau đó mapping với hàng nghìn JD (Job Description) thực tế trên thị trường để xác định "Skill Gap".Bước 3 (Recommendation): Thay vì nói "Bạn nên học AI", hệ thống sẽ đưa ra lộ trình: "Bạn có 70% tố chất Data, nếu hoàn thành thêm 2 dự án về Data Warehouse và tối ưu SQL, bạn sẽ khớp 95% yêu cầu của vị trí Junior Data Engineer tại các tập đoàn lớn".3. Tại sao AI làm tốt hơn con người?Một chuyên gia tư vấn có kinh nghiệm, nhưng AI có dữ liệu real-time. AI có khả năng quét hàng nghìn biến động thị trường trong giây lát để đưa ra lời khuyên dựa trên con số, không dựa trên cảm tính.Kiến trúc đề xuất:LLM (Large Language Models): Phân tích ngữ nghĩa CV và mục tiêu.Vector Database: Lưu trữ embedding của các bộ kỹ năng.Career Score: Một chỉ số đo lường độ khớp (Matching rate) dựa trên: Skill Coverage, Project Depth và Market Demand Index.4. Tác động thực tế: AI for Good là AI vì con ngườiNếu triển khai quy mô lớn, AI Career Copilot sẽ tạo ra những giá trị bền vững:Với cá nhân: Giảm bớt sự mơ hồ, tối ưu hóa thời gian học tập và tăng tỷ lệ apply thành công.Với doanh nghiệp: Nhận được nguồn ứng viên chất lượng, "đúng khớp" với yêu cầu kỹ thuật, giảm chi phí đào tạo lại.Với xã hội: Giảm thiểu tình trạng lãng phí nguồn lực trình độ cao do đi sai hướng.5. Góc nhìn cá nhân: Copilot, không phải AutopilotTôi tin rằng AI không nên đưa ra quyết định thay con người hay gắn nhãn "bạn không phù hợp". AI nên đóng vai trò là một Người dẫn đường (Copilot) – cung cấp dữ liệu, gợi ý lộ trình và cảnh báo rủi ro. Quyết định cuối cùng và sự nỗ lực thực thi vẫn nằm ở mỗi cá nhân.Trong một ngành thay đổi tính bằng ngày như IT, điều đáng sợ nhất không phải là thiếu năng lực, mà là không biết mình đang ở đâu trên bản đồ sự nghiệp. Nếu AI có thể giúp một sinh viên năm cuối không bỏ cuộc, hoặc giúp một bạn trẻ tìm thấy "tần số" thực sự của mình, thì đó chính là ý nghĩa cao đẹp nhất của công nghệ.Bởi vì: AI không thay thế con người, AI giúp con người ra quyết định tốt hơn.

Có một lầm tưởng trong ngành IT: Nếu bạn không có một công ty để check-in mỗi sáng, không có một danh hiệu trên LinkedIn để khoác lên mình, thì bạn đang "thất nghiệp".Tôi cũng từng trải qua cảm giác đó khi quyết định rời khỏi vị trí DevOps & System Engineer tại một Core Team chuyên nghiệp. Nhưng nhìn lại, đó là giai đoạn tôi làm việc năng suất nhất, không phải cho một ông chủ nào, mà là cho chính mình và những khách hàng tin tưởng tìm đến tôi.1. Từ "người vận hành" đến "người giải quyết vấn đề"Khi còn làm System Admin hay DevOps tại TEL4VN, thế giới của tôi là đảm bảo hệ thống của công ty luôn Up. Nhưng khi bước ra ngoài, đối mặt với các dự án Outsourcing, tôi nhận ra khách hàng không cần một người chỉ biết gõ lệnh. Họ cần một giải pháp.Giai đoạn mà mọi người gọi là "thất nghiệp" thực chất là lúc tôi bắt đầu build những dự án CNTT từ con số 0 cho khách hàng.Thay vì chỉ quản lý một phần hệ thống, tôi phải tự tay thiết kế toàn bộ kiến trúc (Architecture).Thay vì đợi task đổ về, tôi phải tự đi tìm "bug" trong mô hình kinh doanh của khách và dùng công nghệ để sửa nó.Đó không phải là thất nghiệp. Đó là "Freelance with a CEO mindset".2. Tư duy DevOps trong mọi ngóc ngách sự nghiệpDù sau này tôi có giữ vị trí Managing Director hay làm Advisory Board cho các dự án tài chính, cái gốc của tôi vẫn là một người làm kỹ thuật. Tôi mang tư duy của một DevOps vào việc quản trị dự án:CI/CD cho cuộc sống: Tôi không đợi đến khi hoàn hảo mới bắt đầu. Tôi "release" bản thân vào những thử thách mới, nhận feedback từ thị trường, và cải tiến (optimize) mỗi ngày.Automation: Tôi luôn tìm cách hệ thống hóa quy trình, từ việc quản lý dự án cho đến việc kết nối với các "tần số" cùng đam mê.Khi bạn tự mình build dự án cho khách, bạn không còn là một "thợ code" hay một "người trực server". Bạn trở thành một người kiến tạo. Bạn học được cách quản trị rủi ro, cách tối ưu chi phí và cách giao tiếp để khách hàng hiểu được giá trị của những dòng code khô khan.3. Đừng sợ khoảng trống, hãy sợ "lỗi hệ thống" trong tư duyGửi những bạn đang loay hoay với hai chữ "thất nghiệp" trong mùa layoff này:Hệ thống không sập, nó chỉ đang bảo trì: Khoảng thời gian không đi làm công ty là cơ hội tốt nhất để bạn tự build một sản phẩm của riêng mình, hoặc nhận những dự án Outsourcing để thử sức với những Stack công nghệ mới mà ở công ty cũ bạn không có cơ hội chạm vào.Nói chuyện bằng sản phẩm, không phải bằng chức danh: Khách hàng và đối tác tìm đến tôi vì tôi giải quyết được bài toán của họ, chứ không phải vì cái danh thiếp tôi đang mang.Tôi là Thảo – một GenZ trầm tính nhưng luôn sẵn sàng "nói nhiều" bằng những dự án thực tế. Tôi đã từng bước ra khỏi vùng an toàn của một nhân viên chính thức để tự mình "vận hành" sự nghiệp. Và tin tôi đi, khi bạn làm chủ được kỹ thuật và tư duy hệ thống, bạn sẽ không bao giờ thất nghiệp. Bạn chỉ đang bận chuẩn bị cho một đợt "Big Release" của cuộc đời mình thôi.