Đã làm ra Excel cho Uber, nhưng rồi nó sớm bị bỏ đi
(basta.substack.com)- Năm 2016, tổ chức Business Intelligence của Uber đã tạo một công cụ chạy mô hình R và giao diện giống Excel để nhanh chóng xử lý dữ liệu cần thiết cho cuộc cạnh tranh tại Uber China, nhưng tính năng này sớm bị gỡ bỏ khi Uber China được bán cho Didi
- R-Crusher là một hệ thống nội bộ nhằm biến quy trình thiếu ổn định, nơi các nhà khoa học dữ liệu tải dữ liệu Vertica về máy tính xách tay rồi chạy mô hình R qua đêm, thành một công cụ thực thi dựa trên API
- Các đội ngũ thành phố ở Trung Quốc đã quen với các tệp Excel dùng để tính thưởng cho tài xế, và thay vì chuyển thủ công hàng trăm đến hàng nghìn công thức sang JavaScript, nhóm đã triển khai một engine bảng tính chạy XLS và công thức ngay trong trình duyệt
- Nguyên nhân khiến kết quả hơi lệch so với Excel là do các nhà khoa học dữ liệu dùng tham chiếu vòng để thực hiện hồi quy tuyến tính, nên hệ thống được điều chỉnh theo cách của Excel: lặp phép tính cho đến khi hội tụ
- Ngay cả mã được viết tốt cũng có thể bị loại bỏ nếu bài toán kinh doanh mà nó giải quyết không còn nữa; giá trị của kỹ thuật nằm gần với việc giải quyết vấn đề hơn là tuổi thọ của mã
Công cụ dữ liệu nội bộ từng chống đỡ Uber China
- Sau khi gia nhập Uber năm 2016, tác giả trở thành kỹ sư frontend đầu tiên của nhóm Crystal Ball
- Nhóm có khoảng 4 người và phần lớn thiên về backend
- Vai trò là biến các công cụ nội bộ thành UI mà mọi người trong công ty có thể thực sự sử dụng
- Khi đó, các nhà khoa học dữ liệu tải dữ liệu từ Vertica rồi chạy mô hình R qua đêm trên nhiều laptop
- Buổi sáng, chỉ những laptop mà mô hình không bị chết mới cho ra dữ liệu có thể dùng trong ngày
- Những laptop thất bại không tạo được dữ liệu cần thiết, và điều đó dẫn tới việc công ty mất tiền
- R-Crusher mà nhóm đang xây dựng gần giống một hệ thống CI: tải mã về qua API, chạy nó và tạo ra tệp kết quả
- Wesley, frontend của R-Crusher, đã có phiên bản đầu tiên chỉ vài tuần sau khi tác giả gia nhập
- Trong 6–7 tháng tiếp theo, nhóm tiếp tục bổ sung tính năng cho người dùng, công cụ debug và mở rộng đội frontend
Thị trường Trung Quốc và việc tính thưởng cho tài xế
- Năm 2016, hai trọng tâm lớn bên trong Uber là viết lại/thiết kế lại ứng dụng và Uber China
- Công việc của nhóm Crystal Ball rốt cuộc là để hỗ trợ Uber China
- R-Crusher là công cụ nhằm đảm bảo dữ liệu cần thiết để cạnh tranh với Didi
- Trung Quốc là một cơ hội quan trọng với Uber, và một phần dữ liệu cần thiết dự kiến sẽ đến từ R-Crusher
- Vào mùa hè, một yêu cầu mới xuất hiện
- Có một mô hình tạo dữ liệu dự báo nhu cầu đi xe qua đêm cho Trung Quốc
- Bản thân dữ liệu này không hữu ích nếu đứng riêng, nhưng khi đưa vào một tab cụ thể trong bảng tính Excel thì nó trở thành công cụ tương tác để tính thưởng cho tài xế
- Người phụ trách tài chính yêu cầu đưa bảng tính đó vào trong Wesley
- Các đội thành phố nói rằng họ chỉ biết dùng Excel và yêu cầu “hãy làm nó giống Excel”
- Dù nhóm giải thích rằng không đủ thời gian kỹ thuật, câu trả lời nhận được là mỗi ngày không có công cụ này sẽ mất hàng triệu đô la
Bắt chước Excel trong trình duyệt
- Không có thời gian để chuyển bảng tính ở backend sang mã Python hay R, nên tình huống trở thành phải viết rất nhiều JavaScript ở frontend
- Một nguyên mẫu Box Sums từng được làm ở Box trở thành nền tảng
- Nó có UI bảng tính đơn giản dựa trên React và một engine công thức cơ bản
- Khi thả tệp XLS/XLSX vào trang, nội dung được parse bằng một thư viện Node
- Bản triển khai cho Uber không nhắm tới việc là chính Excel mà là hành vi gần giống Excel
- Đọc tệp XLS làm đầu vào
- Chạy công thức Excel trên dữ liệu
- Backend cung cấp dữ liệu nhu cầu đi xe dưới dạng mảng 2 chiều, còn frontend đưa nó vào engine công thức như một tab ẩn
- Ngoài những ô mà người dùng cần thao tác, tất cả đều được đặt ở chế độ chỉ đọc
- Điểm mấu chốt là tránh phải dịch thủ công hàng trăm đến hàng nghìn công thức dày đặc sang JavaScript
- Trong quá trình triển khai, nhóm trích xuất công thức từ tệp XLS và thêm các hàm cùng cú pháp cần thiết vào engine công thức
-
Mở rộng cú pháp Excel
- Tham chiếu ô tuyệt đối
- Tham chiếu ô từ sheet khác
- Các cú pháp bảng tính không có trong bản demo Box cũ
-
Những con số gần đúng nhưng vẫn sai và tham chiếu vòng
- Ở lần so sánh đầu tiên, kết quả giữa Excel và engine tự làm chênh nhau rất nhỏ
- Khi Excel cho ra
3.03thì hệ thống tự làm cho ra3.01 - Khi Excel cho ra
1.002thì hệ thống tự làm cho ra1.000
- Khi Excel cho ra
- Những giá trị gần đúng lại khó xử lý hơn những giá trị sai hẳn
- Điều đó có nhiều khả năng là khác biệt tính toán tinh vi hơn là lỗi logic đơn giản
- Unit test đều pass, và khác biệt giữa kiểu double của JavaScript với biểu diễn số thực dấu chấm động của Excel cũng không phải nguyên nhân
- Sau khi hỏi nhà khoa học dữ liệu, nguyên nhân mới lộ ra
- Bảng tính đang dùng tham chiếu vòng để thực hiện hồi quy tuyến tính
- Excel không phải lúc nào cũng coi tham chiếu vòng là lỗi
- Nếu giá trị tính toán hội tụ đến mức chênh lệch nhỏ hơn một epsilon nhất định, Excel sẽ dừng lặp và coi như thành công
- Cách triển khai được thay đổi sang phát hiện đồ thị phụ thuộc vòng và so sánh chênh lệch giữa giá trị tính trước đó với giá trị tính mới
- Nếu chênh lệch đủ nhỏ thì dùng giá trị mới
- Nếu không thì tăng số vòng lặp và tiếp tục tính
- Ngưỡng số lần lặp được đặt là 1000
- Thay đổi này mất khoảng một ngày rưỡi, và đầu ra đã khớp với Excel
- Nhóm viết test và tích hợp vào Wesley
- Dự án được bàn giao vào tuần thứ hai của tháng 7
Yêu cầu bảo mật sau khi phát hành và việc khai tử đột ngột
- Công cụ thực sự đã được phát hành và các thành viên đội thành phố của Uber China đã đăng nhập để sử dụng
- Theo tác giả biết, các con số tạo ra đã được dùng cho thưởng tài xế
- Thời điểm đó là tuần thứ ba của tháng 7
- Đến tuần cuối cùng của tháng 7, người phụ trách tài chính coi việc bấm vào ô rồi thấy công thức là một vấn đề
- Có lo ngại rằng nhân viên Didi sẽ ứng tuyển làm thực tập sinh tại Uber China để lấy cắp dữ liệu
- Mô hình đe doạ này chưa từng được chia sẻ trước với nhóm kỹ thuật
- Muốn bảo vệ hoàn toàn công thức thì phải chuyển việc tính toán lên server, nhưng điều đó nằm ngoài phạm vi yêu cầu
- Bản sửa ngay lúc đó là làm cho công thức không hiện ra khi bấm vào ô trên UI
- Vào tuần đầu tiên của tháng 8 năm 2016, Uber China được bán cho Didi
- Nhiều nhân viên biết tin trước tiên qua thông báo tin tức
- Vài giờ sau, công ty mới gửi email nội bộ thông báo thương vụ
- Khi Uber China biến mất, UI đó cũng bị gỡ khỏi Wesley
- Đó là UI tuỳ biến cho một tác vụ dữ liệu sẽ không bao giờ cần chạy lại
- Không còn ai yêu cầu “làm lại Excel trong trình duyệt” nữa
Giải quyết vấn đề quan trọng hơn tuổi thọ của mã
- Khi ấy tác giả không cảm thấy mất mát hay thất vọng quá lớn
- Ý nghĩ đầu tiên là muốn public mã lên GitHub, rồi sau đó chuyển sang việc tiếp theo
- Chỉ có chút tiếc nuối nhỏ vì đoạn mã đã tốn công viết lại được dùng quá ngắn rồi biến mất
- Mã mà kỹ sư viết ra rồi sẽ có lúc trở thành legacy code
- Một ngày nào đó, ai đó có thể vui vẻ khi được xoá chính đoạn mã đó
- Ngay cả mã được viết tốt cũng không phải tồn tại lâu mới là mục tiêu
- Trưởng thành với tư cách kỹ sư gắn liền với việc dùng kỹ thuật để tạo ra giá trị kinh doanh tốt hơn
- Giá trị kinh doanh có thể được tạo ra theo nhiều cách: sản phẩm kỹ thuật, hợp tác, mentoring, hỗ trợ nhóm, v.v.
- Sau khi Uber China biến mất, dự án này không còn giá trị kinh doanh nào để tiếp tục tạo ra
- Có cố đẩy tiếp cũng không giúp ích cho cá nhân hay công ty
- Cách nói DevOps “Cattle, not pets” cũng phù hợp với code
- Code là phương tiện để hoàn thành công việc, và khi công việc đó không còn hữu ích thì code cũng nên sẵn sàng nghỉ hưu
- Nếu vì cảm xúc mà đối xử với code như thú cưng, ta sẽ hành động ngược với việc hiểu doanh nghiệp
Những câu hỏi mà một dự án bị khai tử để lại
- Một dự án bị gỡ bỏ không nhất thiết đồng nghĩa với thất bại ngay lập tức
- Công việc bị khai tử để lại những câu hỏi sau
- Có phải ta đã làm ra thứ không đáp ứng được các ràng buộc của dự án?
- Có phải ta đã làm đúng thứ được yêu cầu, nhưng bản thân yêu cầu ban đầu đã sai?
- Có phải bài toán cốt lõi đã bị hiểu sai?
- Có phải giải pháp được yêu cầu thực sự giải quyết nhu cầu của người dùng cuối?
- Có câu hỏi nào lẽ ra cần hỏi các bên liên quan nhưng đã không hỏi?
- Kỳ vọng có bị thiếu chính xác hoặc mơ hồ không?
- Mức độ độ bền/chắc chắn mà ta bàn giao có thực sự cần thiết không?
- Một lời giải đơn giản hơn hoặc bớt “thông minh” hơn có đủ không?
- Có phải ta đã đặt sai tiêu chí thành công?
- Ngoài việc “xây đúng thứ được yêu cầu”, còn có tiêu chí thành công nào khác không?
- Nếu chỉ xem kết thúc dự án là thất bại, ta sẽ bỏ lỡ cơ hội học được chỗ nào trong các vấn đề phi kỹ thuật đã lệch hướng
- Ngay cả những bộ phận được làm rất tinh vi cũng có thể bị loại bỏ nếu chúng không vận hành trơn tru trong một hệ thống lớn hơn
1 bình luận
Ý kiến trên Hacker News
Câu trích dẫn hay nhất là đoạn này: “Những người làm ở Didi nộp đơn làm thực tập sinh Uber China rồi tuồn dữ liệu của chúng ta ra ngoài. Không thể để họ xem các công thức được. Nếu không họ sẽ sao chép y nguyên những gì chúng ta làm!”
Điều này thật sự đúng. Người Mỹ không hiểu rõ mức độ gián điệp kinh tế và công nghiệp diễn ra hằng ngày ở Trung Quốc. Khoảng giữa thập niên 2000, khi tôi đang ứng phó một vụ xâm nhập riêng tại một công ty công nghệ không thể nêu tên, tôi nghe nói: “Chúng tôi mở một trung tâm công nghệ ở Tân Cương, nhưng gần đây số thẻ ra vào bị mất nhiều bất thường”; khi tôi hỏi “Có nghĩ rằng đó có thể không phải là bị mất, mà là bị bán lấy tiền không?”, thì chỉ còn im lặng.
Tôi không biết các lãnh đạo biết mà không quan tâm, hay chỉ đơn giản là bất tài, nhưng Trung Quốc đã sản phẩm hóa hoạt động gián điệp công nghiệp ở quy mô lớn. Gần đây GE Aviation cũng trở thành nạn nhân: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
Sau đó họ lập công ty ở Trung Quốc, nhận vốn từ nhà đầu tư Trung Quốc, và làm ra gần như cùng một sản phẩm cho thị trường Trung Quốc. Ví dụ có các trường hợp như Thoratec/Abbot Heartmate III và CH Biomedical, Auris/Verb/J&J Robotic & Digital Solutions và Renovo Surgical.
Trớ trêu là một số công ty kiểu này, sau khi thành công ở Trung Quốc, lại muốn bán hàng và cạnh tranh tại Mỹ và Châu Âu. Giờ đây chuyện này không còn là bí mật hay giao dịch ngầm nữa; trong ngành của chúng tôi, nó diễn ra công khai và phần lớn được chấp nhận như “chuyện là vậy”.
Một điểm nữa là các công ty nước ngoài kinh doanh ở Trung Quốc rất khó bảo vệ tài sản của mình. Vì thế các công ty khôn ngoan thường không cố tự làm, mà cấp phép cho công ty Trung Quốc để phục vụ thị trường Trung Quốc. Như vậy ít nhất còn có khả năng không bị đánh cắp toàn bộ.
Trước đây, agency nơi tôi làm từng thuê một nhà thiết kế công nghiệp để làm một vỏ ngoài đẹp cho phần cứng iBeacon. Kết quả rất tuyệt.
Chúng tôi giao cho một công ty Trung Quốc ép phun nhựa, mẫu thử cũng khá tốt nên quyết định dùng, nhưng vài tuần sau tôi thấy vỏ của chúng tôi được bán trên Alibaba/AliExpress.
Tôi không có ý nói phương Tây hay các nước khác là hoàn hảo, nhưng đó không phải điều đang được nói ở đây. Tất cả những người tôi biết từng làm việc với sản xuất/kinh doanh Trung Quốc đều đã trải qua những chuyện kiểu “bị sao chép”, “công sức của chúng tôi bị bán cho người khác”, “họ cung cấp loại x có phẩm cấp thấp hơn thỏa thuận”.
Phản biện cuối cùng luôn là “nhưng phương Tây cũng làm X” hoặc “đó là phân biệt chủng tộc”.
Các công ty Trung Quốc, đặc biệt là những nơi bán hàng trên Ali-X, rất thích cấu trúc này. Vì họ có thể lấy tài sản trí tuệ miễn phí rồi dùng giá cả để đẩy nhà sản xuất thiết bị gốc ra ngoài. Thiết kế của các maker đăng trên Tindie và những nơi tương tự cũng thường bị sao chép rồi xuất hiện trên Ali.
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
Khi đọc bài này, tôi đã kỳ vọng một câu chuyện về việc bóc tách và xóa bỏ những đoạn mã tùy biến phức tạp, nhưng trái với dự đoán, tác giả đã trưởng thành hơn với tư cách kỹ sư
Câu châm ngôn DevOps “Cattle, not pets” rất hợp trong trường hợp này. Mã nguồn và sản phẩm được tạo ra từ mã đó không phải thú cưng, mà là gia súc. Chúng làm việc, và khi công việc đó không còn hữu ích nữa thì chúng đã sẵn sàng để nghỉ hưu. Nếu đối xử với mã như thú cưng vì lý do cảm tính, thì chẳng khác nào đang làm điều đi ngược trực diện với lợi ích của doanh nghiệp
Viết nhiều đoạn mã rất vui, và giải nhiều vấn đề cũng rất vui. Nhưng doanh nghiệp, đặc biệt là startup, phải tập trung cực độ. Sự nghiệp của tôi thực ra gần như là ngồi trong phòng họp và nói với các kỹ sư trẻ, đầy nhiệt huyết rằng đừng xây dựng nó. Hơi buồn, nhưng cũng là việc bắt buộc phải làm
Một kỹ sư giỏi có thể giải quyết bất kỳ vấn đề nào bằng mã thông minh. Một kỹ sư xuất sắc hiểu rằng có những vấn đề thực ra không phải là vấn đề, và có khi một liên kết tải xuống XLS được cập nhật hằng ngày đã là đủ
Tôi đang xây dựng hệ thống giám sát cho một dịch vụ được host nội bộ, và sếp tôi muốn mua một tiện ích nhỏ để theo dõi một phần vụn vặt trong môi trường của chúng tôi. Tôi hơi khó chịu vì nghĩ mình có thể tự làm mà lại phải bỏ tiền ra mua
Sếp hỏi: “Mất bao lâu để viết và kiểm thử cái này?” Tôi đáp: “Có lẽ một tuần, nếu gặp phần khó thì có thể lâu hơn một chút.” Rồi ông ấy hỏi: “Công cụ đó giá 500 đô. 40 giờ công của cậu đáng bao nhiêu?”
Lúc đó tôi đã ngộ ra, và từ đó về sau tôi không còn tự làm những thứ mà công ty có thể mua rẻ hơn nữa
Checklist ở cuối trang Substack cũng không đủ cho mức nắm bắt yêu cầu như thế này. Những câu hỏi đó chỉ mô tả tình huống, và chỉ vì đã hỏi chúng không có nghĩa là sẽ đi đến được giải pháp đơn giản này. Tư duy kiểu checklist là một cái nạng và làm vấn đề trở nên phức tạp quá mức
Ở đây, mọi tín hiệu quan trọng đều mang tính tổ chức và xã hội, chứ không phải vấn đề có thể giải quyết bằng cách cải thiện quy trình. Người không tham gia vào chi tiết triển khai thì không thể trả lời các câu hỏi về chi tiết triển khai
Câu “cứ làm giống Excel là được” là một câu trả lời chất lượng thấp từ một người có mục tiêu hoàn toàn khác. Lẽ ra phải trao đổi với người gần với người dùng thực hơn và từ đó hình thành phản biện. Điều còn thiếu là khả năng nhận ra các giả định yếu, và lòng can đảm cố ý không viết mã cho đến khi các chi tiết được chốt đủ để mọi bên liên quan đồng thuận. Không được chỉ nói “vâng” với “người phụ trách”
Năm 2006, tôi cũng từng có một cuộc nói chuyện dài để thuyết phục ai đó đừng đi theo con đường đó, và đến năm 2026 chắc chắn vẫn sẽ có người lại muốn làm điều tương tự
Khả năng dừng lại và nghĩ “người khác đã giải quyết đúng vấn đề này như thế nào?” là một phần rất lớn trong quá trình trưởng thành của lập trình viên, nên tôi ước gì trường học tập trung vào điều này hơn
Chỉ dựa vào phần mô tả rằng họ đã hoàn thành thành công và đúng hạn trong một thời hạn ngắn thì không thể kết luận lựa chọn triển khai là tệ. Ngược lại, câu chuyện là nó thành công đến mức đã triển khai quá nhiều tính năng của Excel, rồi sau đó họ loại bỏ những thứ đó để sửa lại. Với một liên kết tải XLS thì làm sao có thể loại bỏ được những thứ đó?
Điểm cốt lõi là đừng quá gắn bó với mã, và trong một số tình huống điều đó có thể là “đừng tự xây, hãy dùng liên kết tải xuống XLS”, nhưng không phải lúc nào cũng chỉ có vậy
Phần “không có gì xảy ra, nhưng tôi giữ lại đoạn mã đó để một ngày nào đó dùng đến. Ý tưởng của tôi là tinh chỉnh đoạn mã này cho phù hợp với nhu cầu của Uber”, và “phản ứng đầu tiên của tôi là công khai mã trên GitHub” thật sự rất đáng ngạc nhiên
Chẳng phải đoạn mã đó thuộc sở hữu của Box hoặc Uber sao? Tác giả không nhắc đến việc đã xin phép trước khi công khai dưới giấy phép MIT
Nếu Uber muốn một đoạn JavaScript vài nghìn dòng, không xuất phát từ họ, đã hơn nửa năm trôi qua, và được dùng chưa tới một tháng, thì họ cứ gửi thư cho tôi
Đoạn “ông ấy không thể nào tin rằng tôi đã viết cả một engine bảng tính chạy trong trình duyệt” thì tôi cũng khó tin, và không phải theo nghĩa tốt
Dùng Apache POI là có thể chạy Excel headless. Có thể lấy sheet trong Java và tương tác bằng lập trình; ở chỗ làm cũ tôi đã dùng đúng vì lý do như vậy. Hàm, tham chiếu ô, v.v. đều hoạt động tốt
Chỉ là may mắn khi tìm ra vấn đề ‘circ’. Những tiểu tiết kỳ quặc ẩn giấu của Excel sẽ gặp trong tương lai thì định làm sao? Thật sự sẽ tạo và bảo trì một bản sao Excel hoàn chỉnh bằng JS à? Đó có đúng là mục tiêu của đội frontend không?
Chỉ cần tìm kiếm một chút có lẽ đã tránh được hơn 90% công việc ở đây. Thêm nữa, đội backend cũng có thể đảm nhận
Uber vận hành data center riêng. Để xin được một máy Windows hoặc VM chạy Excel thật có lẽ cần phép màu. Tôi có thể dựng một dịch vụ frontend mới trong khoảng 30 phút, và cũng đã có một phần code đang chạy sẵn, nên không phải bắt đầu hoàn toàn từ con số 0. Cũng phải tính đến việc hệ thống này cần cho nhiều người với các tập dữ liệu khác nhau dùng đồng thời
Nếu họ tiếp tục đòi thêm nhiều tính năng và mức tương đương Excel hơn nữa thì tôi đã cân nhắc, nhưng họ đã không làm vậy
Tôi không kỳ vọng nhiều người sẽ chọn cách như tôi. Nhưng nó đã chạy, và chạy tốt đến đáng ngạc nhiên. Nếu từ bài viết mọi người chỉ rút ra “đó là một dự án lớn và phức tạp”, thì bài viết đã không truyền tải đúng thông điệp tôi muốn nói
Nếu là tôi, có lẽ tôi sẽ soi kỹ đặc tả UI hơn và thúc đẩy hướng chạy Excel ở phía sau. Nhưng khi có nhiều chỗ nhập số liệu thì đó đúng là một UI quen thuộc
Tôi luôn thấy bài viết làm bảng tính bằng 100 dòng F# này rất thú vị: https://tomasp.net/blog/2018/write-your-own-excel/ Mở rộng nó tới tập tính năng cần ở đây là mức có thể xoay xở được
Cuối cùng họ đã tự làm một bản sao “Excel” làm UI cho mô hình, lý do là “các đội thành phố chỉ biết dùng Excel”
Nếu là tôi thì sẽ làm ngược lại. Tôi sẽ nối Excel với dữ liệu mà mô hình xuất ra để các đội thành phố tiếp tục dùng Excel thật. Có vẻ hầu hết các đội tài chính đều làm kiểu này
Tài liệu về tham chiếu vòng trong Excel cho ai tò mò: https://support.microsoft.com/en-us/office/remove-or-allow-a...
Nếu không quen với tính toán lặp, nhiều khả năng bạn sẽ không muốn để nguyên tham chiếu vòng. Có thể bật tính toán lặp, nhưng phải quyết định sẽ tính lại công thức bao nhiêu lần. Nếu bật tính toán lặp mà không thay đổi số lần lặp tối đa hoặc mức thay đổi tối đa, Excel sẽ dừng tính sau 100 lần lặp, hoặc khi mọi thay đổi giá trị trong tham chiếu vòng giữa các lần lặp nhỏ hơn 0,001, tùy điều kiện nào đến trước. Tuy vậy, bạn có thể kiểm soát số lần lặp tối đa và mức thay đổi được chấp nhận
Tôi tự hỏi liệu tác giả có nhìn nhận tình huống này khác đi không nếu Uber hay Box tuyên bố đoạn mã đó là của họ. Dù đoạn mã không phát huy được tiềm năng thực sự, ít nhất việc cả thế giới có thể nhìn thấy và công nhận nó dường như cũng mang lại một mức độ giải tỏa nào đó
Khi còn làm thực tập sinh, tôi từng tạo ra cả một ngôn ngữ lập trình. Nó được đánh giá lười, có garbage collection, và cũng có những điểm kỳ quặc đặc thù cho ứng dụng như địa chỉ MAC không đặt trong dấu ngoặc kép vẫn là cú pháp hợp lệ
Không có bytecode hay JIT gì cả; trình thông dịch đi qua cây cú pháp và push/pop các giá trị trên stack, nhưng như vậy là đủ nhanh cho công việc của chúng tôi. Trình thông dịch được viết bằng ANSI C thuần và Valgrind cũng rất hài lòng
Nó có thể đã bị lãng quên hoàn toàn, hoặc cũng có thể đã trở thành phần cốt lõi trong hạ tầng kỹ thuật của công ty đó. Đoạn mã ấy chưa từng rời khỏi phòng lab air-gapped nơi tôi viết ra nó, nên không có cách nào biết được. Ba năm trước, khi tôi vừa tốt nghiệp đại học, đó chắc chắn là thứ “phần mềm thực sự hữu ích” ngầu nhất mà tôi từng viết, và đến giờ vẫn nằm trong nhóm đầu. Thỉnh thoảng tôi vẫn tự hỏi nó đã ra sao
Có vẻ tác giả nhầm tưởng rằng việc hỏi một quản lý cấp trung, thậm chí một quản lý cấp cao, “Anh/chị có muốn cái này không?” và người đó trả lời “Không” là có giá trị ràng buộc pháp lý với công ty
Câu “Rất dễ xem những đoạn mã đặc biệt thông minh hoặc thanh lịch như kiệt tác. Thực ra chúng cũng có thể là những món đồ trang trí đẹp. Nhưng kỹ sư chúng ta không làm nghề tạo ra đồ trang trí đẹp, mà làm nghề tạo ra kết quả” khiến tôi thấy rất thấm
Tuy vậy, như bất kỳ ai từng xem code của tôi đều biết, tôi cũng muốn code và chức năng của nó thật đẹp. Thường thì tôi viết code mà chính tôi sẽ bảo trì, nên một năm sau nhìn lại vẫn phải hiểu được
Hiện tôi đang ở giai đoạn cuối của một dự án mà tôi sẽ không công bố ở đây, cũng không định nhận nhiều công trạng, nhưng nó thật sự là một thứ tuyệt vời. Lý do nó được như vậy là vì không ai trả tiền cho nó, và cũng không ai kiếm tiền từ nó
Tiền vừa có thể phá hỏng mọi thứ, đồng thời cũng có thể khiến mọi thứ trở nên khả thi
Một bài viết thật sự xuất sắc từ góc nhìn của đội BI Uber ngày trước. Tôi ở đội Vertica trong giai đoạn đó, và lượng công sức đổ vào incentives nhiều đến mức choáng váng. Việc mất hàng triệu đô la mỗi ngày vì downtime, tính năng sản phẩm, hay băng thông kỹ thuật là chủ đề thường gặp
Đặc biệt vào thời Uber China, việc một director yêu cầu chính xác spreadsheet làm UI hẳn cũng là chuyện rất tự nhiên. Cá nhân tôi cũng từng nạp giá FX vào Vertica từ một spreadsheet được gửi qua email cho đội mỗi tháng. Vì không có đủ băng thông để đảo chiều luồng điều khiển bằng thu thập tự động, quy trình đó đã tồn tại hơn một năm
Câu “Cho đến nay tôi vẫn chưa thấy hệ thống ứng dụng nội bộ nào được thiết kế tốt như của Uber. Từ lúc bắt đầu đến khi chạy Hello World trên một subdomain *.uberinternal.com với CI/CD đầy đủ mất chưa đến 30 phút” khiến tôi thấy hơi ấm lòng
Thời đó tôi từng tham gia vào tất cả những việc này ở Uber