Rời Linkedin

• Khi việc làm cho đúng và tốc độ nhanh của công ty xung đột với nhau, bạn sẽ chọn gì?
• Câu chuyện của kỹ sư Chris Krycho, người đã chọn vế sau trong lựa chọn giữa việc giữ vững niềm tin nhưng thỏa hiệp, hay rời đi để tìm công việc phù hợp với nguyên tắc của mình.
• Cuối cùng Chris đã rời LinkedIn để theo đuổi công việc phù hợp với các nguyên tắc của bản thân.
• Tổng hợp lại những điều anh ấy đã chia sẻ trong podcast.
• Câu chuyện của anh nhấn mạnh sự căng thẳng giữa “nhu cầu đổi mới” và “tầm quan trọng của sự lành mạnh của dự án”.

Ngày đầu tiên của Chris Krycho tại LinkedIn

• Chris gia nhập LinkedIn vào cuối tháng 1 năm 2019. Anh trải qua nhiều quy trình onboarding khác nhau vốn thường thấy ở các công ty lớn hoặc các công ty nhỏ vận hành lành mạnh.
• Chris dự định làm việc từ xa tại Colorado, nhưng hai tuần đầu anh dành cho onboarding và làm quen với đội ngũ.

Hàng triệu dòng mã

• So với kinh nghiệm ở công ty trước, anh rất bất ngờ trước quy mô của ứng dụng client frontend và các dịch vụ backend của LinkedIn.
• Frontend của LinkedIn có tới 2 triệu dòng mã, nhiều hơn rất nhiều so với toàn bộ codebase ở công ty trước của anh.

Đội hạ tầng

• Vai trò của Chris nằm trong đội hạ tầng, nhưng trọng tâm không phải là xây dựng server mà là hỗ trợ kỹ thuật hoặc cải thiện trải nghiệm nhà phát triển.
• Mục tiêu là giúp việc làm việc với ứng dụng desktop quy mô lớn của LinkedIn trở nên dễ dàng hơn.

Hiện đại hóa JavaScript

• Anh tham gia vào công việc hiện đại hóa mã thông qua việc đưa JavaScript class vào sử dụng. Trong quá trình giải quyết các vấn đề phát sinh khi dùng framework Ember, anh đã học được rất nhiều.
• Anh nhận ra rằng việc migration trong một codebase quy mô lớn cần được tự động hóa tối đa, vì khối lượng công việc này quá lớn để xử lý thủ công.

Áp dụng TypeScript

• Để giảm lỗi phát sinh ở frontend, nhóm đã quyết định chuyển sang TypeScript.
• TypeScript có thể được áp dụng dần dần, và điều này mang lại khả năng mở rộng mà LinkedIn cần.

Kế hoạch migration chậm so với 'Finger Gun's Plan'

• Chris và nhóm của anh đề xuất một kế hoạch 3–5 năm để migration mã Ember sang React, nhưng một đội khác lại đưa ra 'Finger Gun's Plan', hứa hẹn việc làm lại tổng thể và tốc độ triển khai cao.
• Sự khác biệt trong cách tiếp cận này phản ánh xung đột giữa những vấn đề mà Chris và nhóm của anh đang đối mặt với văn hóa ưu tiên tốc độ của công ty.

Trải nghiệm và những điều Chris học được

• Nhận ra vấn đề cảnh báo không đầy đủ.
• Toàn bộ server trong data center đã sập do phản ứng dây chuyền từ việc tăng mức sử dụng bộ nhớ và khởi động lại server.
• Nhóm đã cố gắng giải quyết vấn đề bằng cách reset hệ thống và điều chỉnh quyền hạn.
• Thất bại là điều không thể tránh khỏi, và kỹ nghệ phần mềm là việc thiết kế các hệ thống hỗ trợ quá trình các kỹ sư tạo ra sản phẩm đầu ra.
• Nhấn mạnh sự cần thiết của các hệ thống có khả năng phục hồi ở nhiều tầng.

Phản ứng sau sự cố

• Trong quá trình xử lý vấn đề đã phát sinh bất mãn do thiếu niềm tin từ phía quản lý.
• Bất đồng quan điểm với các kỹ sư cấp cao và vấn đề trong giao tiếp.
• Anh nhấn mạnh rằng hệ thống không chỉ phải hoạt động khi ở trạng thái tốt nhất, mà còn phải có thể hỗ trợ trong mọi tình huống.

Áp lực gia tăng

• Dù đã nỗ lực xử lý technical debt và cải thiện khả năng phục hồi, sự bất mãn từ ban điều hành vẫn gia tăng.
• Xung đột với ban điều hành, những người đòi hỏi các lời giải đơn giản cho những vấn đề phức tạp.

Tái cơ cấu tổ chức

• Tái cơ cấu tổ chức và thay đổi vai trò do 'đội Finger Guns'.
• Nhận ra những trải nghiệm mới và cơ hội học hỏi ở các vai trò khác.

Suy ngẫm và tự nhận thức

• Tự phản tỉnh thông qua kinh nghiệm trong quá khứ và tình huống hiện tại.
• Nhận ra tầm quan trọng của việc xây dựng quan hệ giữa con người và giao tiếp.
• Hiểu rằng các vấn đề kỹ thuật và vấn đề xã hội có liên kết với nhau.

Kết luận và bài học

• Chris giữ góc nhìn phê phán đối với một văn hóa coi tốc độ là giá trị ưu tiên cao nhất.
• Tìm kiếm cơ hội mới thông qua việc suy ngẫm về sự nghiệp và các giá trị cá nhân.
• Hành trình của Chris trong việc tìm một vai trò theo đuổi sự xuất sắc trong kỹ thuật vẫn tiếp tục.

Ý kiến của GN⁺

• Trải nghiệm của Chris Krycho cho thấy rất rõ xung đột giữa các nguyên tắc kỹ thuật và yêu cầu kinh doanh.
• Quyết định của anh nhấn mạnh tầm quan trọng của việc tìm ra sự cân bằng giữa giá trị cá nhân và lựa chọn nghề nghiệp.
• Việc quản lý thay đổi trong môi trường kỹ thuật quy mô lớn như LinkedIn rất phức tạp, và điều này cũng mang lại bài học quan trọng cho các công ty khác.
• Việc áp dụng các công nghệ như TypeScript có thể giúp cải thiện chất lượng mã và giảm lỗi, nhưng với codebase lớn thì cần một cách tiếp cận dần dần.
• Khi thúc đẩy những thay đổi kỹ thuật như vậy, cần cân nhắc sự cân bằng giữa trải nghiệm nhà phát triển và tốc độ phát hành sản phẩm.

[GN⁺]

Ý kiến trên Hacker News

• Có người kể rằng trong một cuộc trò chuyện với quản lý, họ đã nghe câu: "Bạn quá lý tưởng, không coi trọng lợi nhuận đủ mức, và cần thay đổi hệ giá trị của mình." Họ bày tỏ sự phản cảm với điều đó và khẳng định ý chí giữ vững các giá trị của bản thân. Đây được cho là phần thú vị nhất của podcast, và tác giả nói rằng điều này khiến họ có ấn tượng người đó dường như đã cố tình phớt lờ những phản hồi quan trọng. Bài học rút ra trong sự nghiệp là điều khó không phải là biết điều gì đúng, mà là đạt được sự đồng thuận của cả tổ chức về giải pháp đúng đắn.

  • Trường hợp trải qua xung đột giá trị trong cuộc trò chuyện với quản lý
  • Ấn tượng rằng đã cố tình phớt lờ phản hồi quan trọng
  • Bài học quan trọng là sự đồng thuận của cả tổ chức về giải pháp đúng đắn

• Năm 2019, tôi đã tham gia dự án viết lại facebook.com bằng React. Tôi không biết trực tiếp về codebase hay tổ chức của LinkedIn, nhưng tôi từng thấy các công ty có codebase và cấu trúc tổ chức tương tự. Tôi ủng hộ cách tiếp cận “finger gun”, vì nếu được triển khai tốt thì nó có thể mang lại kết quả tích cực. Khi nhiều client cố làm cùng một việc, bạn có thể lấy một cái làm nền tảng để phục vụ các nền tảng khác. Hoặc nếu bắt đầu mới, bạn có thể làm theo cách sạch sẽ, nhanh và gọn. Yếu tố thành công phổ biến là một đội nhỏ gồm các cựu binh xây dựng hệ thống mới; tôi tin rằng thành công đến từ các nhóm kỹ sư nhỏ kết hợp giữa chuyên gia miền nghiệp vụ và chuyên gia kỹ thuật. Một vấn đề lớn lặp đi lặp lại trong quản lý kỹ thuật là những người ít kinh nghiệm nhất lại là người xây dựng hệ thống lớn tiếp theo.

  • Chia sẻ kinh nghiệm viết lại sang React
  • Nhấn mạnh cách tiếp cận “finger gun” và tầm quan trọng của đội ngũ cựu binh quy mô nhỏ
  • Chỉ ra vấn đề người ít kinh nghiệm xây dựng hệ thống lớn

• Việc viết lại quy mô lớn vẫn rủi ro ngay cả với codebase còn trong tầm quản lý, và các vấn đề tồn đọng cũng không biến mất hoàn toàn. Vài năm sau, ai sẽ muốn viết lại một trang cấu hình ẩn? Giá mà có một framework để viết lại codebase, nhưng thực tế là không có. Codemod tự động đòi hỏi tính nhất quán, trong khi điều đó hiếm khi được tuân thủ. Theo thời gian, các pattern trong code đã thay đổi rất nhiều, nên nó giống như nhìn vào vòng năm của thân cây. Đây là việc cho code vào các chiếc hộp rồi sắp xếp lại, nhưng ở cấp độ chiếc hộp thì chưa có tự động hóa.

  • Rủi ro của việc viết lại codebase và các vấn đề tồn đọng
  • Không có framework cho việc viết lại code
  • Khoảng cách giữa tự động hóa ở mức code và tự động hóa ở mức chiếc hộp

• Tôi hiện đang làm việc tại LinkedIn, và tôi nghĩ vai trò của Chris được nhắc trong podcast cùng với phát triển web frontend có liên quan đến ember. Có lẽ họ đang nói đến voyager-web, ứng dụng web chủ lực dạng monolith của LinkedIn. Ngoài voyager-web, 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. Ví dụ như lớp trung gian, offline data stack, hệ thống metric, Kafka, v.v. Thời gian build 17 phút thực ra là khá tốt; nếu không có lỗi hạ tầng nhất thời mà vẫn là 17 phút thì đó là rất tốt rồi.

  • Chia sẻ trải nghiệm hiện đang làm việc tại LinkedIn
  • Giải thích về nhiều hệ thống và thời gian build
  • Đánh giá về thời gian build 17 phút

• Hàng triệu dòng JavaScript đồng nghĩa với mức độ phình to quá mức. Điều đó khiến tôi nghĩ đến việc tái triển khai một dịch vụ như LinkedIn hoặc tạo cơ sở dữ liệu liên hệ của riêng mình. Vấn đề là làm sao để di chuyển danh bạ với số lượng lớn. Một trong những vấn đề chính của Microsoft LinkedIn là không thể xuất thông tin liên hệ, trong khi đó là tính năng bắt buộc phải có đối với một nền tảng danh bạ.

  • Chỉ ra sự phình to quá mức của mã JavaScript
  • Khó khăn trong việc di chuyển thông tin liên hệ
  • Tầm quan trọng của tính năng xuất thông tin liên hệ

• Tôi đã ở LinkedIn 12 năm, nhưng giờ đây nó đã rất khác so với tổ chức kỹ thuật ngày xưa. Theo tôi, thời Kevin Scott lãnh đạo mảng kỹ thuật tốt hơn nhiều.

  • Kinh nghiệm làm việc lâu năm tại LinkedIn
  • Sự khác biệt giữa tổ chức kỹ thuật trước đây và hiện tại

• Đây là một tình huống mà định luật Conway đang phát huy tác dụng. Chừng nào tổ chức chưa thay đổi, họ sẽ lại tạo ra cùng một mớ hỗn độn trong code. Những sáng kiến kỹ thuật tích cực phải đến từ cấp trên và cần sự hậu thuẫn từ cấp rất cao. Không thể thay đổi tổ chức theo hướng từ dưới lên; chính tổ chức tạo ra codebase.

  • Khả năng tái diễn hỗn loạn trong code nếu tổ chức không thay đổi
  • Cần các sáng kiến kỹ thuật tích cực từ cấp trên

• Tôi thực sự ấn tượng với cách Chris Krycho nói thẳng thắn 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 yêu thích vì nó đào sâu vào bối cảnh phức tạp đằng sau code.

  • Thái độ thẳng thắn và tránh đổ lỗi của Chris Krycho
  • Đánh giá tích cực về podcast CoRecursive

• Việc chuyển từ Ember sang React có vẻ là một trường hợp rất phù hợp với công nghệ mà một khách hàng tôi từng làm việc trước đây đã tạo ra. Anh ấy đã tạo ra một ngôn ngữ tên là "Unhack" để cho phép tìm kiếm và thay thế ở cấp độ AST. Nó dùng một ngôn ngữ để chỉ định pattern trong mã nguồn gốc và một pattern khác để thay thế nó. Tôi đã ngừng làm việc với khách hàng đó từ vài năm trước, nên không biết giờ nó còn tồn tại hay không.

  • Trường hợp chuyển đổi công nghệ từ Ember sang React
  • Ngôn ngữ "Unhack" cho phép tìm kiếm và thay thế ở cấp độ AST

• Codebase của LinkedIn lộn xộn thì chẳng có gì đáng ngạc nhiên nếu bạn từng dùng website của họ. Bạn bấm vào một bài đăng mình quan tâm, tìm hiểu thêm về người viết, rồi nhấn quay lại thì feed bị làm mới và bạn mất luôn bài đăng đó. Khi cố cuộn các tin nhắn đã nhận, toàn bộ trang web chậm hẳn và mất 10-15 giây mới nhận thao tác nhập. Tại sao lại có 30 thông báo giả? Đó là những thông báo giả được tạo ra để ép người dùng tương tác. Thuật toán gợi ý cũng tệ một cách hoàn toàn.

  • Khó khăn khi sử dụng website LinkedIn
  • Thông báo giả và phản hồi chậm của trang web
  • Chỉ ra các vấn đề của thuật toán gợi ý