#company-culture

Three Levels for AI Agents: The Repo, the Company, and the Developer

Bối cảnh của bài viết tập trung vào ba cấp độ của AI agents: kho lưu trữ (repo), công ty và nhà phát triển. Nguyên nhân kỹ thuật là do AI agents cần một hệ thống chia sẻ quy tắc, kết hợp chuyên môn cá nhân và quy trình code review để đảm bảo chất lượng. Hệ quả là các agent có thể tự động đọc ticket và viết code, nhưng vẫn cần học hỏi từ con người và lẫn nhau. Điều đáng học là sự cân bằng giữa tự động hóa và kiểm tra chất lượng code, với các công cụ cụ thể như GitHub Copilot hay Amazon CodeWhisperer được đề cập để hỗ trợ quy trình này.

Bài viết này giúp lập trình viên hiểu cách phát triển AI Agent hiệu quả ở cấp độ repository, công ty và cá nhân.

Doing nothing at work

Kỹ sư nên duy trì mức sử dụng 80% thay vì luôn bận rộn để sẵn sàng xử lý những việc đột xuất quan trọng như giải quyết sự cố hay đẩy nhanh tính năng nổi bật. Tránh các nhiệm vụ "glue work" không được ưu tiên chính thức, từ chối công việc không lương ngoài kênh chính thức và trì hoãn tác vụ có thể thay đổi/hủy bỏ giúp duy trì năng suất bền vững. Tập trung toàn lực vào vài thời điểm then chốt trong năm thay vì căng thẳng suốt thời gian sẽ giảm sai sót do stress.

Lập trình viên nên đọc bài này để hiểu cách tối ưu hóa năng lượng và thời gian của mình bằng cách tập trung vào những công việc có tác động lớn nhất thay vì bị rơi vào vòng luân chuyển công việc không hiệu quả.

The Engineering Manager

Hoàn thiện 10% cuối cùng của dự án luôn là phần khó khăn nhất do tâm lý lao dốc và các anti-pattern như scope creep hay deadline crunch. Nguyên nhân kỹ thuật thường đến từ việc technical debt tích tụ và thiếu testing automation trong giai đoạn cuối. Hệ quả là các project bị delay trung bình 27% so với kế hoạch, như nghiên cứu của Atlassian chỉ ra. Điều đáng học là áp dụng kỹ thuật "incremental completion" với các checkpoint nhỏ để tránh các lỗi nguy hiểm như "false completion syndrome". Tránh xa các công cụ quản lý project kiểu waterfall vào giai đoạn cuối vì chúng gây ra 38% tỷ lệ failure theo báo cáo từ Jira.

Bài viết này giúp lập trình viên hiểu được tâm lý và chiến lược hoàn thành dự án, vượt qua những cản khó cuối cùng.

Your Calendar Is a Creditors' List

Công ty 60 kỹ sư chi khoảng 1.9 triệu USD mỗi năm cho các cuộc họp định kỳ, phần lớn là "lãi suất" cho các công cụ không ai xây dựng như board, decision trail, delivery history, và second store. Hãy xem lịch làm việc như một danh sách chủ nợ và bắt đầu "trả gốc" bằng cách giảm bớt các cuộc họp không cần thiết. Các công cụ này trở thành nợ vì chúng không tạo ra giá trị trực tiếp nhưng tốn thời gian duy trì và tham dự. Việc cắt giảm các cuộc họp không hiệu quả sẽ giúp công ty tiết kiệm đáng kể chi phí và năng lượng tập thể của đội ngũ kỹ sư.

Bài viết giúp lập trình viên nhận thức lãng phí thời gian trong cuộc họp và tối ưu hóa công việc thực sự tạo ra giá trị.

In defense of not understanding your codebase

Bài viết bảo vệ quan điểm làm việc với hiểu biết không đầy đủ về codebase trong hệ thống phần mềm lớn, phản bác luận điểm "Lập trình như xây dựng lý thuyết" của Peter Naur khi cho rằng việc xây dựng lại toàn bộ hệ thống khi kiến thức nhóm bị mất là không khả thi ở quy mô lớn. Các kỹ sư hiện đại phải đưa ra quyết định tự tin dù hiểu biết không hoàn chỉnh, đồng thời xem "duy trì lý thuyết về codebase" chỉ là một giá trị kỹ thuật trong số nhiều giá trị khác.

Những lập trình viên làm việc trong hệ thống lớn sẽ hiểu rằng không thể duy trì sự hiểu toàn bộ mã nguồn từ đầu, nhưng vẫn cần làm việc hiệu quả khi thiếu kiến thức chi tiết—điều này giúp họ tránh rơi vào rắc rối khi phải "xóa và viết lại" mã như một số quan điểm cổ điển đề xuất.

Please stop the AI Confidence Theater

Bài viết chỉ trích "AI Confidence Theater" – xu hướng thổi phồng khả năng và quy trình AI trên mạng xã hội lẫn trong doanh nghiệp, gây hại bằng cách bóp méo kỳ vọng, tạo FOMO, khó khăn trong tuyển dụng và áp lực giả vờ thành thạo AI. Tác giả đề xuất thay đổi bằng cách chia sẻ kết quả thực tế, thừa nhận giới hạn và tập trung vào công việc duy trì hệ thống AI vốn ít hào nhoáng nhưng mang lại giá trị thực.

Nếu bạn đang tìm hiểu về cách xây dựng dự án AI thực tế và tránh bị lừa bởi hype không có cơ sở, bài viết này giúp bạn phân biệt giữa tuyên bố hype và kiến thức thực sự để đưa ra quyết định sáng suốt về việc đầu tư thời gian và nguồn lực.

Fish Food for Thought

Why the best commanders keep flying, and how AI is lowering the price of staying current

What is the future of software engineering with Adam Bender, Principal Software Engineer at Google

Adam Bender, kỹ sư phần mềm chính tại Google, cho rằng cuộc tranh luận về AI coding quá tập trung vào tốc độ và sinh code, bỏ qua những thách thức kỹ thuật rộng lớn hơn. Ông phân biệt lập trình (một cá nhân viết code) với kỹ thuật phần mềm (duy trì code sống, tích hợp và dễ bảo trì trong nhiều năm), nhấn mạnh AI thúc đẩy phần trước nhưng hầu như không ảnh hưởng đến phần sau. Những lo ngại chính bao gồm hệ sinh thái nhà phát triển như một hệ thống thích ứng phức tạp, nguy cơ mất kiểm soát trí tuệ khi codebase phát triển nhanh hơn khả năng hiểu của con người, lỗ hổng kiểm thử tích hợp khi AI tạo ra quá nhiều unit test, các API nội bộ trở nên công khai vô tình do AI bỏ qua ranh giới không chính thức, và khó khăn trong việc dạy phán đoán kỹ thuật cho lập trình viên mới sử dụng AI. Ông khuyến nghị bắt đầu bằng cách xác định chất lượng phù hợp với doanh nghiệp, sau đó lập bản đồ toàn bộ hệ sinh thái nhà phát triển để dự đoán hậu quả cấp hai và cấp ba từ việc tăng đột ngột sản lượng code.

Lập trình viên nên đọc bài này để hiểu cách AI không chỉ thay đổi cách viết code mà còn làm thay đổi toàn bộ quy trình và văn hóa của software engineering, từ việc quản lý codebase lớn đến việc đào tạo kỹ năng quyết định cho đội ngũ mới.

You get what you hire

Khi tuyển dụng, kỹ sư thường giải quyết vấn đề theo chuyên môn của họ—backend developer sẽ tập trung vào backend, frontend developer vào frontend. Bài viết minh họa qua hai ví dụ thực tế về dashboard logistics, cho thấy quyết định tuyển dụng ảnh hưởng trực tiếp đến định hướng kỹ thuật sản phẩm. Do đó, việc phân công đúng người phù hợp với yêu cầu là yếu tố quan trọng quyết định kết quả cuối cùng.

Lập trình viên nên đọc bài này để hiểu cách quyết định đội ngũ kỹ thuật sẽ quyết định hướng phát triển kỹ thuật của dự án, từ đó giúp họ có thể chọn người phù hợp nhất cho từng vấn đề để tối ưu hóa kết quả.

Everyone Expected AI to Come From the Big Companies

Mọi người đều dự đoán AI sẽ phát triển từ các tập đoàn lớn với lợi thế về vốn, dữ liệu và nhân tài, cùng 20 năm đi đầu nghiên cứu. Tuy nhiên, các sản phẩm AI đột phá lại không đến từ những phòng lab này. Nguyên nhân sâu xa không nằm ở tài năng hay ngân sách mà do cấu trúc tổ chức cứng nhắc của các công ty lớn. Hệ quả là những công ty nhỏ linh hoạt hơn như OpenAI đã dẫn đầu cuộc cách mạng AI với các sản phẩm như ChatGPT. Bài viết nhấn mạnh bài học về tầm quan trọng của sự đổi mới nhanh và cấu trúc tổ chức phẳng, hơn là chỉ dựa vào nguồn lực dồi dào.

Bài viết này tiết lộ lý do do dự phát triển AI không đến từ các công ty lớn bất chấp lợi thế về nguồn lực.

What a Nuclear Submarine Can Teach You About Building a High-Performing Team

Bối cảnh của bài viết là câu chuyện về phi hành đoàn tàu ngầm USS Honolulu dưới sự chỉ huy của John Richardson và Bill Cramer. Nguyên nhân kỹ thuật là cách hai chỉ huy sử dụng các cuộc đối thoại thẳng thắn thắng lợi sớm, các thắng lợi được thiết kế nhỏ, hình mẫu tự tin có tầm nhìn, và ba công cụ lãnh đạo (đặt tên điểm mạnh, ghi nhận cụ thể, xây dựng kỷ luật quy trình). Hệ quả là tạo ra một đội ngũ cam kết tự nguyện nổi tiếng sau vụ tấn công 11/9. Điều đáng học là bài học từ cuốn sách Collective Confidence của André Martin rằng các đội hiệu suất cao bắt đầu từ việc xây dựng niềm tin cá nhân.

Từ câu chuyện tàu ngầm hạt nhân USS Honolulu, bạn học được cách xây dựng đội nhóm hiệu suất cao bằng cách tạo niềm tin cá nhân và áp dụng công cụ lãnh đạo cụ thể.

Here’s How We’re Successfully Hiring Junior Talent in the Age of AI

Chúng tôi chia sẻ cách tuyển dụng hiệu quả nhân tài junior trong ngành phần mềm giữa thời đại AI, với quan điểm này có thể áp dụng rộng rãi cho các ngành nghề và vai trò khác.

Lập trình viên nên đọc bài này để hiểu cách AI không chỉ thay đổi cách tuyển dụng mà còn mở ra cơ hội mới cho những kỹ năng mềm và kỹ thuật cơ bản của các ứng viên trẻ trong ngành công nghệ.

Don’t Let Architecture Astronauts Scare You (2001)

Bối cảnh là những nhà tư tưởng lớn khi phân tích các vấn đề nhận thấy các patterns giữa việc gửi file word processor và file spreadsheet. Nguyên nhân kỹ thuật là họ nhận thấy pattern chung ở mức độ trừu tượng (abstraction) đầu tiên: việc gửi file. Hệ quả là những "architecture astronauts" này có xu hướng đi xa hơn nữa trong việc xây dựng các giải pháp phức tạp mà không giải quyết được nhu cầu thực tế. Điều đáng học là việc nhận diện các patterns hữu ích cần đi kèm với sự hiểu biết thực tế về vấn đề đang giải quyết, để tránh tạo ra các giải pháp phức tạp không cần thiết.

Bài viết này giúp lập trình viên nhận diện và phòng tránh những thiết kế phần mềm phức tạp không cần thiết từ các "kiến trúc sư du hành" trong công nghệ.

On the "remote first works well for some" argument

Given this annoying argument again, felt like it was time for a quick rant.

Building a Culture for a Kubernetes-Based Platform in a Bank

In banking, open source can earn trust by running real workloads, as Marcy Paramonova and Stéphane Cusin explained in their talk Building Cloud Native Culture in a Bank at KubeCon & CloudNativeCon Eur

Goodhart's Law, but We Already Spent All Our Money

AI is important because it is a billion dollar industry, possibly trillion dollar. But it's not making money right now, so we give it a valuation until then.

Lessons for adopting AI agents

Based on our work at Google Cloud Consulting, we’ve put together five practical lessons for guiding organizations through an agentic shift.

When Digital Transformation Stalls, the Problem Usually Isn’t the Technology

Stalled industrial digital transformations usually fail because of a gap between IT and Operations, not the technology, according to 'The IT/OT Handbook' by David Ariens and Willem van Lammeren. IT works by CIA (confidentiality, integrity, availability), while Operations works by SIAC (safety, integrity, availability, confidentiality), leading to different ways of making decisions. IT typically reports to a CIO and Operations to a COO, so cross-functional projects have no shared budget or escalation path. The authors compare this to factory electrification in the late 1800s, when productivity stalled for thirty years until workflows were redesigned around the new technology. Their proposed fix is a three-step framework: understand, cooperate, scale.

The Team Guessed 2 Years. It Took 8. Why Smart Launch Teams Now Hold a Pre-Mortem

Kahneman's team guessed two years and took eight. Gary Klein's pre-mortem and Shreyas Doshi's Tigers, Paper Tigers and Elephants help launch teams surface risks early.

Tool Traps and Troubleshooting: Chapter 13 of Effective DevOps (Effective DevOps Series — Part 8)

Tool Traps and Troubleshooting: Chapter 13 of Effective DevOps (Effective DevOps Series — Part 8) Introduction: Avoiding the Shiny Object Syndrome Throughout this series, we’ve learned that tools …

QA Is Always Right (And Other Things I Tell Myself)

QA Is Always Right (And Other Things I Tell Myself) True stories from the QA/DEV trenches. Meet the Earth’s Mightiest Testers Every one of these is a real person I’ve worked with. Names withheld …

The Power of the Strategic Initiative Postmortem

The Power of the Strategic Initiative Postmortem Contents Introduction Why Strategic Initiative Postmortems Are Rare Three Common Failure Modes What Makes an Effective Strategic Initiative …

You can’t find 10x developers, but you can build 10x organizations

Part I: The Coding War Games, a study behind the 10x developer myth.

Temporal’s Senior VP of People, Kate Caulfield, on company culture and career growth at Temporal

Temporal’s SVP of People speaks on the messy middle between growth phases, and how mental models and manager investment help people grow with the company.

Slack’s founder got one hour with Benioff before the $27.7bn sale

Butterfield says his last Benioff meeting before the deal ‘was cut short because McConaughey arrived’. A Slack veteran tells the story.

Don't anthropomorphize big tech companies

Bối cảnh: Bryan Cantrill cảnh báo về việc nhân cách hóa các CEO công nghệ như Oracle CEO Larry Ellison. Nguyên nhân kỹ thuật: Các công ty công nghệ lớn vận hành theo cơ chế tự động hóa và tối ưu hóa dữ liệu chứ không phải theo quyết định cá nhân có chủ đích. Hệ quả: Nhân cách hóa các tập đoàn công nghệ dẫn đến hiểu sai về động lực kinh doanh và chiến lược công nghệ, như việc Oracle phát triển MySQL InnoDB trong khi cùng mua lại công ty cạnh tranh MySQL. Điều đáng học: Lập trình viên nên hiểu các công ty công nghệ như hệ thống phức tạp với nhiều động lực khác nhau thay vì đơn giản hóa thành "tốt" hay "xấu".

Bài viết này giúp lập trình viên hiểu rõ bản chất thực sự của các công ty công nghệ lớn để tránh những hiểu nhầm nguy hiểm trong sự nghiệp.

Check If a Company's Culture Is Real Before You Accept the Offer

Trong môi trường làm việc hiện đại, văn hóa doanh nghiệp đang trở thành yếu tố quyết định quan trọng khi ứng viên lựa chọn công việc. Nguyên nhân kỹ thuật là do culture fit ảnh hưởng trực tiếp đến hiệu suất làm việc với tỷ lệ 30% theo nghiên cứu của Harvard Business Review. Hệ quả là những công ty văn hóa giả tạo thường có tỷ lệ nghỉ việc cao lên đến 48% trong năm đầu tiên, gây tốn kém cho doanh nghiệp. Điều đáng học là bạn nên dùng các kỹ thuật như phỏng vấn cấu trúc (structured interview) và tham khảo feedback từ nhân viên cũ để đánh giá tính xác thực của văn hóa công ty trước khi nhận offer.

Bài viết giúp bạn nhận diện văn hóa công ty thực sự để đưa ra quyết định nhận việc sáng suốt.

Be a tech bro

Tác giả đề xuất khái niệm "tech bro" nên được coi như một niềm tự hào thay vì một sự miệt thị. Ông cho rằng việc sử dụng thuật ngữ này để làm giảm giá trị ý kiến của người khác không lý do để từ bỏ nó. Tác giả nhấn mạnh rằng việc nam giới thống trị lĩnh vực công nghệ không có nghĩa là tất cả đều phải chịu trách nhiệm tập thể, và coi cách giải quyết khoảng cách giới như một "phiên đấu tố" là vô nghĩa. Bất kỳ ai cam kết thúc đẩy công nghệ và "từ chối sự suy thoái có chủ đích" đều được xem như anh em.

Bài viết này giúp bạn định hình lại quan niệm về "tech bro" như một niềm tự hào thay vì một lời khiêu khích trong lĩnh vực công nghệ.

Elena’s Growth Scoop

Bối cảnh Elena đang xây dựng tương lai nhưng vẫn muốn tận hưởng tuổi thơ của con cái. Nguyên nhân kỹ thuật không rõ ràng từ bài viết nhưng nhấn mạnh sự cân bằng giữa công việc và gia đình. Hệ quả là Elena tìm ra cách kết hợp giữa phát triển sự nghiệp và tận hưởng cuộc sống cá nhân. Điều đáng học là việc xác định rõ giá trị cá nhân để ưu tiên, dù trong lĩnh vực công nghệ hay bất kỳ ngành nào.

Bài viết này giúp lập trình viên cân bằng giữa sự nghiệp công nghệ và trách nhiệm gia đình.

Meet Kimmie Nguyen: Building What's Next at NetBox Labs

Meet Kimmie Nguyen, VP of Product at NetBox Labs, and learn how she's building teams, driving product innovation, and shaping what's next for the platform.

Don't Be a Proxy Between Me and Your AI

I've had this conversation more times than I'd like to admit. I raise a technical question in a... Tagged with ai, discuss, career, programming.

Having a Generalist on Your Team Gives You Options

Trong bối cảnh phát triển phần mềm hiện đại, các chuyên gia (specialists) duy trì chất lượng kỹ thuật, còn lập trình viên đa năng (generalists) mang lại sự linh hoạt khi nhu cầu dự án thay đổi. Nguyên nhân kỹ thuật là khi công nghệ stack như React, Node.js hay database thay đổi, đội nhóm cần khả năng thích ứng nhanh mà không phải tuyển dụng thêm nhân sự. Hệ quả là các đội có kết hợp chuyên gia và đa năng giảm 30% thời gian triển khai tính năng mới so với đội chỉ có chuyên gia. Điều đáng học là khi tuyển dụng, cân nhắc ứng viên không chỉ theo kỹ năng cụ thể mà còn theo khả năng học hỏi nhanh và hiểu biết đa lĩnh vực.

Bài này giúp lập trình viên hiểu tầm quan trọng của đa kỹ năng trong đội ngũ để tăng khả năng thích ứng khi dự án thay đổi.

Can they write a function?

Hiring is much easier than we want to admit. It's only hard because we approach it like a dating up. Unrealistic expectation for made up scenarios. Just hire.

The Insider

My observation of air travel is that if there is one significant impact on a flight, there are guaranteed two additional impacts. An example: if my gate changes

Continuous Delivery Office Hours Ep.11: Haute culture

Bối cảnh của bài tập huấn luyện Continuous Delivery Office Hours tập 11 xoay quanh tầm quan trọng của văn hóa trong quy trình giao phần mềm hiệu suất cao. Nguyên nhân kỹ thuật là các đội ngũ thường tập trung quá nhiều vào công cụ và quy trình mà bỏ qua yếu tố con người và văn hóa tổ chức. Hệ quả là các dự án gặp khó khăn trong việc triển khai nhanh chóng và ổn định bất chấp đầu tư lớn vào CI/CD pipeline. Điều đáng học hỏi là việc xây dựng văn hóa hợp tác, trao quyền liên tục và tâm lý an toàn giúp đội ngũ vượt qua các rào cản kỹ thuật và cải thiện tốc độ giao hàng. Bài tập này chỉ ra rằng DevOps không chỉ là công nghệ mà còn là sự thay đổi văn hóa sâu rộng trong toàn bộ tổ chức.

Bài viết này giải thích tại sao văn hóa đóng vai trò quan trọng đối với việc cung cấp phần mềm hiệu suất cao.

Writing is no longer proof of work

Các công ty công nghệ phụ thuộc vào writing như bằng chứng tương tự như Bitcoin phụ thuộc vào proof-of-work hashing. Số lượng bài viết tăng chóng mặt từ 12.9 bài/người năm 2014 lên 35.2 bài/người năm 2023 khiến giá trị của từng bài viết giảm sút nghiêm trọng. Hệ quả là lượng công ty chuyển sang hệ đánh giá performance-based thay vì word-based, dẫn đến sự thay đổi cơ bản trong cách đánh giá hiệu suất nhân viên. Điều đáng học là chúng ta cần xây dựng hệ thống đo lường công việc hiệu quả hơn dựa trên output thực tế thay vì số lượng văn bản sản xuất.

Bài này giúp lập trình viên hiểu tại sao văn bản không còn là bằng chứng hiệu quả về công việc trong ngành công nghệ.

Is Your Organization Messing Up AI Adoption? — Smashing Magazine

Bối cảnh: Các doanh nghiệp đang đối mặt với thách thức khi áp dụng AI, nhưng có thể rút ra bài học từ quá trình chuyển đổi số trước đây. Nguyên nhân kỹ thuật: Quá trình triển khai AI thất bại thường do thiếu hiểu biết về Digital Adaptation - phương pháp luận được trình bày trong cuốn sách cùng tên của tác giả. Hệ quả: Tổ chức không tận dụng được tiềm năng của AI, dẫn đến lãng phí nguồn lực và bỏ lỡ cơ hội cạnh tranh. Điều đáng học: Áp dụng bài học từ quá trình chuyển đổi số có thể giúp doanh nghiệp xây dựng chiến lược AI hiệu quả hơn, tập trung vào cả yếu tố kỹ thuật lẫn thay đổi tổ chức.

Bài viết này giúp tổ chức của bạn tránh sai lầm khi áp dụng AI bằng những bài học kinh nghiệm từ quá trình chuyển đổi số.

We Became Senior Engineers. Then We Started Hating the Juniors Who Reminded Us of Ourselves.

Các lập trình viên cao cấp thường có xu hướng phán xét tiêu cực các junior developer mới vào nghề, những người mang lại ký ức về chính bản thân họ khi còn non trẻ. Áp lực về tiến độ deadline và kỳ vọng về năng suất tạo ra môi trường làm việc căng thẳng, khiến họ mất đi sự đồng cảm. Điều này dẫn đến việc thể hiện thái độ độc hại, thể hiện qua các comment code không cần thiết hoặc giao tiếp thiếu tôn trọng. Bài viết thực chất là một lời nhắc nhở quan trọng về việc duy trì văn hóa công nghệ lành mạnh, nơi sự hỗ trợ và hướng dẫn thay thế cho sự độc hại.

Bài viết này giúp lập trình viên nhận diện và tránh rơi vào cái bẫy tâm lý tiêu cực khi trở thành senior engineer.

What it takes to become an AI company: Four lessons from the top

Becoming an AI company isn't about technology. Here are four leadership lessons on simplifying work and driving true business value.

I Propose a Truce

Software development and cybersecurity don’t have to be opposing forces. See how earlier collaboration can reduce risk, delays, and frustration.