Rời LinkedIn
(corecursive.com)- Chris Krycho đã phụ trách hạ tầng frontend và trải nghiệm lập trình viên cho ứng dụng web desktop của LinkedIn trong khoảng 5 năm, đồng thời trải qua xung đột giữa việc thay đổi an toàn một codebase quy mô lớn và yêu cầu triển khai sản phẩm nhanh
- Ứng dụng desktop của LinkedIn có khoảng 2 triệu dòng JavaScript khi anh gia nhập, sau đó tăng lên thành một monorepo khoảng 3,2 triệu dòng, và việc migration trên thực tế rất khó nếu không có tự động hóa và không giảm gánh nặng cho các nhóm sản phẩm
- Việc hiện đại hóa Ember và đưa TypeScript vào nhằm giảm lỗi và cải thiện chất lượng phát triển; phân tích cho thấy chuyển sang TypeScript có thể giảm ít nhất 25% số lỗi trong log ứng dụng, và điều này được dùng để thuyết phục nội bộ
- Kế hoạch chuyển từ Ember sang React đã đặt chiến lược tự động hóa dần trong 3–5 năm của nhóm Chris đối đầu với cách tiếp cận muốn tái thiết kế mạnh mẽ phương thức hiện có để thử nghiệm sản phẩm nhanh hơn
- Trong quá trình ứng phó sự cố diện rộng, các giới hạn của cảnh báo, khả năng quan sát, khả năng phục hồi và code review đã bộc lộ; Chris rời đi vì định hướng tổ chức đặt tốc độ lên trên hết không còn phù hợp với các giá trị của anh
Công việc trong 5 năm và quy mô codebase
- Chris Krycho gia nhập LinkedIn vào cuối tháng 1 năm 2019 và làm việc khoảng 5 năm
- Phạm vi phụ trách của anh không phải hạ tầng server mà là hạ tầng frontend và cải thiện trải nghiệm lập trình viên cho ứng dụng web desktop của LinkedIn
- Anh dẫn dắt các dự án hiện đại hóa JavaScript quy mô lớn trên ứng dụng desktop phụ trách trải nghiệm LinkedIn.com trên trình duyệt không phải di động
- Ứng dụng ở công ty trước chỉ khoảng 150.000 dòng, nhưng frontend của LinkedIn đã có khoảng 2 triệu dòng code khi anh vào làm
- Mỗi quý có khoảng 150–200 kỹ sư commit vào cùng ứng dụng, và hàng chục đội cùng liên tục triển khai một sản phẩm duy nhất
- Khi anh gia nhập, kỹ sư làm việc từ xa có chưa đến 100 người trong tổng số hàng nghìn nhân sự, và Chris là một trường hợp hiếm làm việc từ xa ở Colorado
Cách thực hiện migration trên 2 triệu dòng code
- Một trong những công việc lớn ban đầu là đưa cú pháp class hiện đại của JavaScript vào code dựa trên Ember
- Có vấn đề khi class Ember cũ và class JavaScript native bị trộn trong cùng chuỗi kế thừa, nội bộ gọi hiện tượng này là “Zebra Striping”
- Với quy mô như vậy, migration phải được tự động hóa tối đa
- Nếu sửa thủ công 2 triệu dòng thì có thể mất nhiều tháng hoặc hơn
- Rất khó yêu cầu các nhóm sản phẩm dừng phát triển tính năng chỉ để áp dụng cú pháp mới
- LinkedIn có quy trình horizontal initiatives trải rộng qua nhiều đội, cùng nguyên tắc vận hành là giữ mức tham gia của các nhóm sản phẩm dưới 10%
- Nhóm của Chris cho rằng cách đội hạ tầng dùng tự động hóa để tạo PR, còn nhóm sản phẩm chỉ review và smoke test, sẽ dễ được chấp nhận hơn so với việc bắt các nhóm sản phẩm tự chạy codemod
- Toàn bộ công việc liên quan đến Ember mất 18 tháng; phần lớn hoàn thành trong 6 tháng đầu nhưng một số đội chậm trễ khiến phần đuôi kéo dài
Lập luận giảm lỗi để thuyết phục việc áp dụng TypeScript
- Sau khi hiện đại hóa Ember, nhóm của Chris nhắm tới lượng lớn lỗi JavaScript phát sinh ở frontend
- LinkedIn có quy mô log lỗi quá lớn nên dùng hạ tầng logging nội bộ thay vì dịch vụ bên ngoài
- LinkedIn đã vượt mốc 1 tỷ thành viên vào năm trước đó, và khi Chris rời đi monorepo đã ở quy mô khoảng 3,2 triệu dòng
- Một nửa là mã kiểm thử
- Một nửa là mã production
- Nhóm của Chris phân tích riêng các loại lỗi mà TypeScript có thể bắt được
- Một số lỗi không thể bị TypeScript phát hiện, nhưng họ cho rằng sau khi hoàn tất toàn bộ migration, có thể giảm ít nhất 25% lượng log ứng dụng trong số hàng triệu lỗi JavaScript mỗi ngày
- Tài liệu Chris viết về chuyển đổi sang TypeScript được chia sẻ lặp đi lặp lại giữa kỹ sư và quản lý
- Vấn đề cần giải quyết
- Các lợi ích có thể kỳ vọng
- So sánh về năng lực cạnh tranh trong tuyển dụng
- Cơ sở để cân nhắc với các ưu tiên khác
- Sau đó Chris còn đảm nhận vai trò chuyên gia nội bộ hỗ trợ các vấn đề type TypeScript khó
Từ Ember sang React: chuyển đổi dần hay tái cấu trúc toàn diện
- LinkedIn là một trong những người dùng EmberJS lớn nhất thế giới, nhưng công việc của Chris cuối cùng chuyển sang việc lập kế hoạch di chuyển từ Ember sang React
- Các lãnh đạo cấp cao cho rằng chi phí migration ở LinkedIn quá lớn và đang làm chậm tốc độ sản phẩm
- Kế hoạch của nhóm Chris là chiến lược tự động hóa dần trong 3–5 năm
- Tăng cường tự động hóa để các nhóm sản phẩm gần như không phải dừng lại
- Tách và chuyển đổi lần lượt build pipeline, data layer, routing layer, hệ thống reactivity và view layer
- Cuối cùng thay hệ thống rendering và reactivity của Ember bằng phía React
- Một nhóm khác nhắm trực diện hơn vào vấn đề tốc độ
- Mục tiêu là rút ngắn thời gian từ ý tưởng đến A/B test từ vài tháng xuống còn vài tuần
- Họ xem các stack khác nhau giữa web desktop, web di động, iOS và Android cùng chu kỳ phát triển dài là vấn đề
- Chris nhìn nhận cách tiếp cận của nhóm đó gần với thái độ “finger guns mode”
- Anh cảm thấy họ chưa xử lý đầy đủ các vấn đề sẽ xuất hiện khi mở rộng từ việc hỗ trợ vài chục người sang hàng trăm kỹ sư
- Theo anh, nhiều phản hồi cho các câu hỏi chỉ mang tính kiểu “sẽ không thành vấn đề đâu”
- Kế hoạch 3–5 năm của nhóm Chris không nhận được phản ứng tốt từ lãnh đạo
- Bản thân kế hoạch dài và không hấp dẫn
- Nhóm cũng trình bày nó như “lựa chọn ít tệ nhất”, nên sức thuyết phục yếu
Vấn đề về khả năng phục hồi bộc lộ qua ứng phó sự cố
- Sau khi Chris trở lại từ kỳ nghỉ Giáng sinh, một số người dùng LinkedIn gặp sự cố không thấy trang LinkedIn.com trong tối đa khoảng 20 phút
- Sự cố liên quan đến dịch vụ prerendering chạy code phía client bằng Node.js để gom dữ liệu backend và trả về nhanh hơn
- Dịch vụ bị rò rỉ bộ nhớ, và container được thiết kế để khởi động lại khi vượt quá giới hạn bộ nhớ
- Nhiều yếu tố chồng lên nhau đã làm sự cố nghiêm trọng hơn
- Cảnh báo cho việc bị kill vì bộ nhớ chưa đủ tốt
- Thiết lập số lượng container có thể khởi động lại đồng thời tồn tại dưới dạng một key trong file YAML
- Giá trị đó hợp lệ về mặt kiểu dữ liệu nhưng lại sai đối với hệ thống này
- Cấu hình trên thực tế gần bằng tổng số service đang chạy
- Khi việc deploy bị dừng trong thời gian dài như kỳ nghỉ cuối tuần kéo dài, các service cạn bộ nhớ gần như cùng lúc, cùng khởi động lại và không thể xử lý request của người dùng
- Khi một số server bị down, tải dồn lên các server còn lại, khiến mức sử dụng bộ nhớ của chúng tăng nhanh hơn và dẫn đến tình trạng server sập theo cả cấp độ datacenter
- Đồng thời còn có công việc rightsizing nhằm giảm mức dùng CPU và bộ nhớ của cả fleet, khiến phần đệm dự phòng ít đi
- Chris và các kỹ sư khác cho rằng cần cảnh báo, khả năng quan sát và khả năng phục hồi tốt hơn
- Dù một Node server rơi vào trạng thái runaway thì cũng không nên làm chết cả tiến trình host
- An toàn hơn là chỉ dừng tiến trình Node, phát cảnh báo rồi khởi động lại
- Họ cũng xem xét đường lui chuyển sang fetch phía client nếu service bị down
Xung đột: code review không thể tự nó ngăn chặn mọi thứ
- Các cuộc họp ứng phó sự cố diễn ra nhiều lần mỗi tuần, vừa để chia sẻ tiến độ vừa để báo cáo với cấp điều hành
- Một quản lý từ nhóm khác phụ trách ứng phó sự cố và bổ sung thêm nhân lực, còn Chris cảm nhận đây là dấu hiệu không tin tưởng vào câu trả lời của anh và đội hiện tại
- Trong quá trình đó, một kỹ sư senior đặt câu hỏi: “Tại sao code review lại không giải quyết được việc này?”
- Chris cho rằng chỉ riêng code review không thể đảm bảo việc tương tự không lặp lại
- Con người luôn có thể mắc lỗi
- Một kỹ sư junior khó có thể nghi ngờ liệu một giá trị cấu hình trong PR của một SRE rất senior có hợp lý hay không
- Hệ thống phải vận hành an toàn không chỉ vào ngày tốt nhất của kỹ sư senior, mà cả vào ngày tệ của kỹ sư junior
- Với Chris, software engineering còn bao gồm cả thiết kế hệ thống để hỗ trợ những kỹ sư tạo ra kết quả sản phẩm
- Sự cố kỹ thuật và giao tiếp tổ chức không tách rời nhau; như Charity Majors từng nói, ở cấp độ cao thì không tồn tại vấn đề chỉ thuần xã hội hoặc chỉ thuần kỹ thuật
Lãnh đạo, văn hóa làm việc từ xa và xung đột giá trị
- Chris cho rằng nhóm và cách tiếp cận của anh đã bị lấn át bởi đề xuất từ nhóm khác
- Kế hoạch của nhóm kia mở rộng thành hướng suy nghĩ lại cả ứng dụng desktop lẫn mobile, và mang tính xem xét lại toàn bộ cách LinkedIn xây dựng sản phẩm
- Chris muốn làm cho đề xuất đó tốt hơn, nhưng cảm thấy các mối lo ngại hay câu hỏi của mình không được tiếp nhận đầy đủ
- Anh kể rằng một quản lý từng nói với mình: “Bạn quá lý tưởng, không quan tâm đủ đến lời lỗ, và cần thay đổi giá trị của mình”
- Chris cho rằng làm việc từ xa đã ảnh hưởng tới việc xây dựng quan hệ
- LinkedIn có văn hóa gặp mặt trực tiếp mạnh, và nhiều người xây dựng quan hệ một cách tự nhiên ở căn tin hoặc hành lang
- Anh cảm thấy việc tiếp xúc vật lý lặp đi lặp lại với các kỹ sư cấp cao và lãnh đạo có thể tạo ra khác biệt trong các tình huống xung đột
- Chris cũng tự nhìn nhận rằng bản thân có điểm yếu trong việc xây dựng quan hệ
Lý do cuối cùng khiến anh rời đi
- Chris cho rằng nhiều vấn đề trong codebase cũ là kết quả của việc đánh giá quá cao tốc độ và không sửa hoặc loại bỏ các lối đi phụ trợ
- Theo anh, nếu tốc độ trở thành giá trị cao nhất thì có thể đạt được lợi thế ban đầu, nhưng sẽ khó duy trì theo thời gian
- Anh từng bị burnout ở công việc trước đó, với các triệu chứng như đau nửa đầu nặng, đau bụng, không thể tập thể dục, bật khóc đột ngột và các cơn hoảng loạn
- Anh cho rằng nếu tiếp tục làm ở LinkedIn, mình sẽ phải cố gắng mỗi ngày để không sống trong trạng thái tức giận
- Anh ví tình huống này như cố đổi hướng một tổ chức khổng lồ bằng một chiếc thuyền chèo nhỏ, và quyết định không dành thêm nhiều năm cho cách làm và công việc mà mình không tin tưởng
- Chris rời LinkedIn để tìm công việc phù hợp với giá trị của mình, dù tại đây anh đã học được về ứng dụng quy mô 3 triệu dòng, migration TypeScript ở doanh nghiệp lớn và các bài toán kỹ thuật quy mô lớn
1 bình luận
Ý kiến trên Hacker News
Tôi cho rằng đoạn thú vị nhất trong podcast là phản hồi rằng “bạn quá lý tưởng hóa, không đủ quan tâm đến lãi lỗ, và cần thay đổi hệ giá trị”. Ngay cả trước khi đọc tôi cũng đã có ấn tượng như vậy, và nghe có vẻ như trong quá trình đó họ đã nhận được phản hồi có giá trị nhưng cố tình phớt lờ
Điều khó đối với một senior staff engineer không phải là bản thân việc “đúng”, mà là tạo ra sự căn chỉnh của toàn bộ tổ chức hướng tới giải pháp đúng. Vì từng tham gia viết lại facebook.com bằng React vào năm 2019 nên câu chuyện này khiến tôi đặc biệt thấy thú vị
Tôi đã giao tiếp được ở một mức độ nào đó, nhưng trong thời gian ở LinkedIn, tôi không thật sự thành công trong việc căn chỉnh đó. Một phần là trách nhiệm của tôi, một phần cũng là trách nhiệm của LinkedIn
Tuy nhiên, trong trường hợp này, câu “quá lý tưởng hóa” thực sự có nghĩa là “đừng bận tâm đến những thứ không đóng góp trực tiếp vào lãi lỗ”, và tôi phản đối điều đó đến tận xương tủy. Lãi lỗ quan trọng, nhưng trải nghiệm người dùng, trải nghiệm developer, và đạo đức nền tảng về việc chúng ta đang tạo ra cái gì cũng quan trọng
Trong một tổ chức, bạn cố gắng hết sức bảo vệ điều mình tin là đúng, rồi người khác hoặc một tập thể sẽ quyết định có đồng ý hay không. Việc chấp nhận kết quả đó, thỏa hiệp, hay rời đi là do tôi quyết định, và trong sự nghiệp tôi đã từng làm cả hai
Ở một unicorn nổi tiếng từng có một senior staff engineer rất thông minh, hợp lý và tử tế. Người đó thúc đẩy nâng framework đang được dùng ở quy mô 50 triệu USD mỗi năm từ v2 lên v3, và so với việc chuyển từ Python 2 sang 3 thì đây là thay đổi rất nhỏ
Kết quả khảo sát cho thấy về cơ bản có thể kỳ vọng cải thiện hiệu năng 10%, nhưng ban lãnh đạo không muốn “lãng phí thời gian vào việc nâng cấp phiên bản”. Cuối cùng kỹ sư đó tự mình thúc đẩy, tạo bản preview trong chưa đầy một tháng, rồi trong vòng hai tháng chuyển một phần công việc có tác động lớn sang đó, tiết kiệm số tiền gấp nhiều lần lương của chính mình
Khi chi phí chính trị ban đầu và chi phí kỹ thuật đã được trả, ai cũng muốn chuyển sang; một năm sau, khi việc triển khai hoàn tất, tầng quản lý nói trên đã mất khoảng một nửa vì bị sa thải và nghỉ việc, nhưng kỹ sư đó và quá trình migration vẫn còn. Đôi khi staff engineer không phải là người cố chấp, mà có thể là người duy nhất tỉnh táo trong một thế giới điên rồ
Tôi đã từng ở vị trí như vậy và có thể không tham gia, nhưng không phải lúc nào cũng có thể làm thế
Tôi đã thấy những trường hợp thuyết phục được ban lãnh đạo bằng mối quan hệ đúng, bữa trưa đúng, lời nói đúng, dù không có ý tưởng hay kế hoạch tốt nhất
Câu “bạn quá lý tưởng hóa và không đủ quan tâm đến lãi lỗ” cũng có thể là cách gắn nhãn để đẩy ai đó ra ngoài. Đặc biệt là nếu người đó đã bán bản thân và ý tưởng của mình lên cấp trên theo cách như vậy
Cá nhân tôi từng thực hiện nhiều thay đổi và nâng cấp quy mô lớn liên quan đến Ruby, Rails, Postgres trong một tổ chức nhỏ hơn Facebook nhưng có hàng trăm kỹ sư và codebase lớn; phương pháp mà Chris mô tả rất hợp lý và cũng khớp với cách tôi cảm thấy là thành công
Tôi đồng ý rằng vai trò lãnh đạo cần có sự tin cậy và tôn trọng mới hiệu quả. Tất nhiên, để sự tin cậy đó hữu ích thì thực tế nó cũng phải đúng. Tiến bộ theo hướng sai thì không phải là tiến bộ
Tôi chưa từng làm việc với codebase của LinkedIn và cũng không biết nó, nhưng đã nhiều lần thấy những codebase và cấu trúc tổ chức/chính trị nghe giống đến đáng sợ. Vì vậy tôi thường ủng hộ cách làm finger-gun
Viết lại kiểu finger-gun cũng có thể được triển khai tốt. Nếu có nhiều client làm cùng một việc, có thể lấy một trong số đó làm nền tảng cho các platform khác; và kể cả bắt đầu từ đầu thì vẫn có thể làm sạch, nhanh và gọn
Mấu chốt để thành công là giao hệ thống mới cho một nhóm nhỏ các veteran vừa là chuyên gia domain vừa là chuyên gia kỹ thuật. Điều này có thể gây tranh cãi, nhưng tôi cho rằng mọi thành công, kể cả các vấn đề vận hành và bảo trì bình thường, đều đến từ đây. Phần còn lại chỉ làm chậm tốc độ
Vấn đề lớn mà hầu hết lãnh đạo kỹ thuật lặp lại là giao hệ thống lớn tiếp theo cho những người ít kinh nghiệm nhất. Tôi cũng muốn nghe một cuộc phỏng vấn đối xứng từ phía finger-gun
Điều đó là tự nhiên vì đó là những thứ đã được kiểm chứng và họ từng thấy hiệu quả, nhưng không phải lúc nào cũng là tốt nhất. Hơn nữa, dù nhóm veteran khởi động dự án, hiếm khi họ ở lại đến cuối; và nếu không phải gánh kết quả hay hậu quả sau đó, thì việc ra quyết định trở nên quá dễ
Kế hoạch phải có các lựa chọn thực tế để xử lý chướng ngại, và điều đó không chỉ gồm lựa chọn kỹ thuật mà còn gồm thời gian và năng lực của những người sẽ làm việc đó. Ví dụ, nếu kế hoạch là nhiều team cùng vận hành server, về mặt kỹ thuật có thể làm được, nhưng nếu team không có thời gian hoặc năng lực thì đó không phải là lựa chọn thực tế
Ngược lại, lập một lộ trình tinh vi để né mọi chướng ngại cũng không tốt. Vì đến lúc tới nơi, chướng ngại có thể đã dịch chuyển, và trên đường có thể còn những chướng ngại mình chưa biết. Nếu chỉ lên kế hoạch cho một con đường duy nhất, bạn sẽ kẹt ở đó
Tuy nhiên, thứ đang thấy ở đây là phần giải thích podcast tóm tắt một cuộc tranh luận kiến trúc phức tạp theo kiểu hoạt họa, nên không thể biết ở LinkedIn thực tế lập luận người rơm nào gần với sự thật hơn
Người đó nói hội đồng quản trị đã nói với toàn bộ bộ phận engineering rằng từ nay trong bất kỳ dự án nào cũng không ai được chỉ đạo chi tiết cho người khác
Nghe như Chris đã đưa ra vài lựa chọn không may. Đề xuất kế hoạch 5 năm, dẫn dắt sự cố theo hướng đổ lỗi thay vì lãnh đạo, nói nhiều về vấn đề hơn là giải quyết vấn đề, và có vẻ cũng thiếu xây dựng quan hệ
Tôi đồng cảm với Chris, nhưng đồng thời cũng có vẻ như anh ấy không biết cách tạo ra kết quả trong môi trường này. Như vậy cũng ổn. Không phải ai cũng cần học cách làm việc trong những nút thắt quan liêu, và startup đơn giản hơn ở mặt đó
Có lý do vì sao các công ty lớn dần mất đi sự sắc bén theo thời gian, và vì sao một executive phải đối mặt với mức lỗ -10% so với năm trước trong phòng họp mà không có lấy một VP thẳng thắn nào bên cạnh
Khi ở trong tình huống như vậy, về mặt tâm lý bạn sẽ mất phương hướng. Có vẻ mình đúng, nhưng mình có thật sự đúng không? Những người xung quanh có thật sự kém năng lực đến thế, và không quan tâm học hỏi từ đồng nghiệp đến thế không?
Vài năm sau rời đi rồi nhìn lại, những người đó đã bị sa thải hoặc đã rời đi, tổ chức vẫn không làm được X, và sự linh hoạt cùng năng lực của các team gia nhập sau đó thật sự tồn tại
Một mặt, đó có thể là kiêu ngạo, thiếu năng lực chính trị, và không thích nghi được với một văn hóa thực thi bệnh hoạn. Mặt khác, đó cũng có thể là phản ứng đúng
Nếu tổ chức đang đi qua một giai đoạn văn hóa bệnh hoạn, việc những người tài năng, thận trọng và nhiệt huyết bị nó làm cho phát điên có thể là điều đúng. Những người không phát điên vì nó có thể không liên quan đến năng suất và tăng trưởng, hoặc tệ hơn là gây lỗ ròng
Vì thế những môi trường như vậy trở thành một vở tâm lý kịch. Tình hình có thật sự tệ đến thế không, hay chỉ là mình phản ứng quá mức
Nhưng trong tình huống ban lãnh đạo nói “dù đây là migration chúng tôi yêu cầu, cũng không được làm chậm tốc độ lặp sản phẩm chút nào”, đó cũng là kế hoạch duy nhất mà chúng tôi cảm thấy có thể mang ra
Tôi không rõ ý nói dẫn dắt sự cố theo hướng đổ lỗi là gì. Thực ra tôi đã cố làm ngược lại, không đổ lỗi cho người đã hạ ngưỡng memory hay người gõ nhầm giá trị sai trong YAML. Tôi chỉ kiên quyết rằng đừng bỏ mặc nguyên nhân gốc rễ cho tới khi người tiếp theo lại làm nổ tung nó, mà hãy thật sự giải quyết
Phần nói rằng tôi chỉ nói chứ không giải quyết vấn đề, tôi cũng không rõ. Chỉ là trong chương trình tôi không khoe dài dòng về những việc mình đã làm; những vấn đề được giải quyết ở đó thực ra đã được xử lý khá tốt
Thiếu xây dựng quan hệ, như tôi đã nói trong tập podcast, là điểm yếu lớn nhất của tôi. Tôi có quan hệ tốt với các kỹ sư, nhưng đã thất bại lớn trong việc xây dựng niềm tin chính trị, đặc biệt với tầng quản lý phía trên
Dù vậy tôi không nghĩ đơn giản chỉ là vì tôi không biết cách tạo ra kết quả trong môi trường đó. Tôi thấy có những cách để thành công, nhưng cũng có lựa chọn không hành động theo cách mà tôi không tin tưởng. Nhiều kỹ sư tôi kính trọng sẵn sàng nhảy vũ điệu chính trị cho những điều họ tin, nhưng không làm vậy cho những điều họ không tin
Hiện đang làm việc tại LinkedIn. Vai trò và podcast của Chris có vẻ xoay quanh Ember và phát triển web frontend, còn số dòng code và bản build mà anh ấy nói có lẽ là voyager-web, ứng dụng web đại diện dạng monolithic của LinkedIn
LinkedIn còn có nhiều hệ thống khác với hàng triệu dòng code và thời gian build dài. Tầng trung gian, stack dữ liệu offline, hệ thống metrics, và những thứ như KafkaKafkaKafka
Đáng tiếc là build 17 phút đã là khá tốt. Nếu 17 phút mà không có sự cố hạ tầng tạm thời thì là rất tốt
Toàn công ty gần như không có khái niệm test, cũng không có QA. Các kỹ sư nhồi những dự án còn nửa vời vào để đưa vào hồ sơ thăng chức rồi chuyển sang việc tiếp theo
Khi dùng công cụ nội bộ hằng ngày, tôi phải tự xử lý quá nhiều vấn đề; cấu trúc khi đó khiến những kỹ sư muốn làm việc thực chất lại trở thành QA
Thay vào đó, nên đi theo hướng làm cho build nhanh hơn, hoặc làm hạ tầng build nhanh hơn và rẻ hơn
Ít nhất ở đội tôi từng ở, chất lượng code được nhấn mạnh khá nhiều và văn hóa cũng đang tiếp tục cải thiện. Tuy vậy tôi từng làm một việc liên quan đến voyager, và nhớ đó là một cơn ác mộng
Viết lại quy mô lớn vốn đã rủi ro ngay cả với codebase còn quản lý được, và phần cặn sót lại dường như không bao giờ biến mất hẳn. Vài năm sau, ai lại muốn ghi điểm bằng việc viết lại một trang cấu hình bị nhét trong góc chứ
Tôi đã thấy quá nhiều nỗ lực kiểu này, nên lẽ ra phải có một framework dành cho việc viết lại codebase, nhưng lại không có. Các công cụ sửa code tự động đòi hỏi tính nhất quán, nhưng hiếm nơi nào giữ được sự nhất quán đó. Các pattern trong code tiến hóa quá nhiều theo thời gian, nhìn như các vòng tuổi cây
Về cơ bản, chúng ta đặt code vào các hộp, sắp xếp lại các hộp, rồi nói một cách hợp lý rằng cách sắp xếp nào đó hiệu quả hơn. Vậy tại sao ta vẫn chưa tìm được cách tốt hơn? Tự động hóa hoạt động ở cấp độ code, nhưng không hoạt động ở cấp độ hộp
Đây là một trường hợp định luật Conway đang phát huy tác dụng. Vì tổ chức chưa thay đổi, khả năng cao là họ sẽ tạo lại cùng một nồi súp code
Từ góc nhìn của người từng ở cùng con thuyền, các sáng kiến kỹ thuật tích cực phải đi từ trên xuống thông qua một nhà bảo trợ ở vị trí rất cao. Không thể thay đổi tổ chức từ dưới lên; suy cho cùng, tổ chức mới là thứ tạo ra codebase
Định luật Conway không thay đổi, nhưng không nhất thiết chỉ phụ thuộc vào sơ đồ tổ chức chính thức. Nếu tạo được cấu trúc giao tiếp tạm thời giữa các tech lead đúng đắn và các quản lý có năng lực thì có thể xử lý được
Tuy nhiên, chỉ cần vài quản lý ở giữa yếu về kỹ thuật hoặc muốn xây vương quốc riêng, toàn bộ việc này rất dễ đổ vỡ; tùy theo vòng đời công ty, có khi đã vô vọng vì quy luật sắt về quan liêu của Pournelle
Ví dụ, nếu toàn bộ developer đều tệ thì đưa cho họ một framework phổ biến. Đó là cái cớ để né tránh vấn đề con người, chẳng khác nào cho trẻ con điều hành nhà trẻ
Nếu muốn sự xuất sắc, phải đặt tiêu chuẩn cao bằng các quy tắc buộc chịu trách nhiệm, trao quyền sở hữu và gắn phần thưởng–trách nhiệm. Không phức tạp, nhưng từ cấp trên phải kiên quyết và không sợ va chạm
Có điều bạn có thể sẽ mất hết hy vọng rằng một công ty như Microsoft có thể làm ra thứ gì đó rồi không phá hỏng nó
Tôi đã ở LinkedIn 12 năm. Đáng buồn là nó đã khác xa tổ chức kỹ thuật ngày xưa. Thời Kevin Scott lãnh đạo engineering thật sự tốt hơn nhiều nếu so sánh
Hàng triệu dòng JavaScript, bản thân nó đã là hiện thân của sự cồng kềnh
Tôi từng nghĩ đến việc triển khai lại một thứ như LinkedIn, hay chính xác hơn là tạo một cơ sở dữ liệu danh bạ của tôi mà không có các tính năng kiểu “Facebook”
Vấn đề là làm sao để các liên hệ của tôi chuyển sang hàng loạt. Tách khỏi chuyện cồng kềnh, vấn đề chính của Microsoft LinkedIn là họ không cho xuất thông tin liên hệ, mà với một nền tảng danh bạ thì đây là chức năng bắt buộc
https://queue.acm.org/detail.cfm?id=2567673
Tóm tắt: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn đã chuyển sang Node vào đầu năm 2010
Tuy vậy, nhìn phản ứng trong luồng này thì tôi cũng tự hỏi liệu con số đó có sai không
Tôi chưa làm với LinkedIn, nhưng đó là mẹo bẩn tôi dùng khi xuất danh sách người tham dự hội nghị được đăng trên một website công khai. Tùy tình huống có thể khác nhau
Tôi ấn tượng với cách Chris Krycho thẳng thắn nói về những khó khăn của mình mà không biến nó thành trò đổ lỗi. CoRecursive là một trong những podcast tôi thích vì nó bàn đến bối cảnh phức tạp phía sau code
Nghe giống một vai trò lãnh đạo mềm gần như lúc nào cũng khó khăn. Đó là vị trí “chịu trách nhiệm” về một việc nào đó, nhưng có rất ít hoặc hầu như không có quyền hạn đối với phần còn lại của tổ chức
Nếu có lãnh đạo kỹ thuật thực sự thì có thể họ đã vắng mặt, hoặc đã ở đó quá lâu và dù được gọi là “chuyên gia hệ thống” thì thực tế không còn chạm đến các vấn đề thật nữa. Tôi đã trải qua rồi, và xin kiếu lần nữa