Trải nghiệm làm việc tại GitLab
(yorickpeterse.com)- 6 năm làm việc từ tháng 10/2015 đến tháng 12/2021, khi gia nhập GitLab với tư cách nhân viên thứ 28, là một trải nghiệm pha trộn giữa làm việc từ xa hoàn toàn, sự hỗn loạn của một startup tăng trưởng nhanh, các vấn đề về hiệu năng, triển khai, văn hóa tổ chức và cả kiệt sức
- Ở giai đoạn đầu của GitLab, phàn nàn lớn nhất từ người dùng là hiệu năng chậm và sự cố xảy ra thường xuyên, nhưng hạ tầng giám sát hiệu năng còn thiếu, và còn phải cùng lúc xây các công cụ mà khách hàng self-hosting cũng có thể dùng
- Trong giai đoạn 2017–2018, tác giả đã tạo database load balancer trong đội Database; cùng thời gian đó, việc xóa nhầm DB production và backup thất bại chồng chéo đã gây ra khoảng 6 giờ mất dữ liệu và gần 24 giờ phục hồi
- Giai đoạn 2019–2021, đội Delivery đã hợp nhất cấu trúc kho lưu trữ tách biệt giữa Community Edition và Enterprise Edition, giảm quy trình từ lúc commit đến khi triển khai lên GitLab.com từ mức tệ nhất là 3 tuần xuống còn vài giờ đến khoảng một ngày
- Những bài học rút ra từ GitLab là khả năng mở rộng phải trở thành một phần của văn hóa, việc đánh giá “minimal viable” khi không có dữ liệu là rủi ro, vận hành song song SaaS và self-hosting tạo ra xung đột yêu cầu, và triển khai nhanh cùng đãi ngộ dựa trên vai trò là rất quan trọng
Trước khi gia nhập GitLab và vai trò ban đầu
- Trước khi gia nhập GitLab, tác giả làm tại một startup nhỏ ở Amsterdam; công ty lúc đó khó khăn đến mức phải cho thuê lại một phần văn phòng vì thiếu vốn
- Trong thời gian cá nhân, tác giả làm việc với Rubinius và muốn ổn định nó đủ để dùng trong môi trường production, nên bắt đầu tìm một công việc cho phép làm những việc liên quan
- Tác giả gặp Sytse tại các buổi Ruby meetup và workshop Rails Girls, từ đó bắt đầu quan tâm đến GitLab; sau khi gửi email vào mùa hè năm 2015, tác giả gia nhập vào tháng 10/2015 với tư cách nhân viên #28
- Công việc được giao là cải thiện hiệu năng của GitLab, đồng thời có thể dùng 20% thời gian làm việc cho Rubinius
- Trong 6 năm, tác giả đi qua nhiều đội khác nhau với mức độ tự chủ lớn, báo cáo cho 10 quản lý khác nhau, và chứng kiến GitLab phát triển từ hơn 30 người lên khoảng 2.000 người
2015–2017: Làm việc từ xa và xây công cụ hiệu năng
- Tác giả bắt đầu làm ở GitLab ngay ngày hôm sau ngày làm việc cuối cùng tại công ty cũ, chuyển từ làm 5 ngày/tuần ở văn phòng sang 5 ngày/tuần làm việc từ xa
- GitLab thời kỳ đầu là một công ty remote hoàn toàn nhưng có bầu không khí rất xã hội, với các buổi gặp mặt và sự kiện công ty thường xuyên ở Amsterdam, Austin và những nơi khác
- Trong giai đoạn này, GitLab trải qua làn sóng tăng trưởng đầu tiên khi tuyển khoảng 100 nhân viên mới; quy mô công ty tăng từ hơn 30 người lên hơn 130, rồi giảm xuống hơn 80 trước khi tăng trưởng trở lại
- Đồng thời, công ty cũng trải qua các vấn đề điển hình của một startup tăng trưởng nhanh như vấn đề hiệu năng nghiêm trọng, sự cố gần như xảy ra hàng tuần, và quản lý còn non nớt
- “GitLab is slow” là phàn nàn lớn nhất từ người dùng
- Trên Hacker News cũng thường xuyên xuất hiện phàn nàn về việc GitLab chậm
- Việc cải thiện hiệu năng càng khó hơn do thiếu công cụ
- Khi đó, giám sát hiệu năng chỉ dựa vào tài khoản trial của New Relic, và chỉ có thể theo dõi 1–2 máy chủ trong tổng số 15–20 máy
- Dữ liệu thu vào không phản ánh chính xác toàn bộ tình hình
- GitLab yêu cầu các công cụ đang dùng cũng phải cung cấp được cho khách hàng self-hosting, và nếu có thể thì nên là mã nguồn mở
- Muốn cải thiện hiệu năng thì trước hết phải xây công cụ, và kết quả sau đó trở thành tính năng chính thức GitLab Performance Monitoring
- Tác giả cũng xây Sherlock, một profiler nặng cho môi trường phát triển, trong giai đoạn này
- GitLab nhận ra rằng vấn đề hiệu năng không thể được giải quyết bởi một người, nên đã lập đội Performance, bổ nhiệm quản lý chuyên trách và cấp ngân sách tuyển dụng nhỏ
- Tác giả từng cố làm cho Rubinius chạy được với GitLab nhưng không thành công; cuối cùng phải dừng do chồng chéo giữa hướng đi bảo trì và tranh cãi trong cộng đồng Ruby
2017–2018: Đội Database, load balancer và sự cố DB production
- Sau khoảng một năm rưỡi hỗn loạn đầu tiên, hiệu năng đã cải thiện đáng kể và GitLab cũng bắt đầu nghiêm túc hơn với vấn đề này
- Đội Performance chuyển phạm vi từ tối ưu hiệu năng nói chung sang tập trung vào hiệu năng cơ sở dữ liệu, và trở thành đội Database
- Ngân sách tuyển dụng cũng tăng lên, đồng thời có thêm kỹ sư hạ tầng hỗ trợ các cấu hình DB mới
- Tính năng cốt lõi được xây trong giai đoạn này là GitLab database load balancer
- Nội dung liên quan được công bố qua Scaling the GitLab database
- Lập trình viên vẫn viết truy vấn DB như bình thường, còn load balancer sẽ định tuyến sang primary hoặc replica
- Sau thao tác ghi, hệ thống áp dụng sticking để tiếp tục dùng primary cho đến khi thay đổi được phản ánh sang mọi replica
- Đây là thay đổi có tác động hiệu năng rất tích cực, và điều đáng tự hào nhất là nó được đưa vào một cách minh bạch
- Ngày 31/1/2017, đã xảy ra sự cố xóa nhầm cơ sở dữ liệu vận hành của GitLab.com
- Sự cố được công khai trong GitLab.com database incident
- Hệ thống backup đã không hoạt động đúng trong thời gian dài, và cả hệ thống lẽ ra phải cảnh báo lỗi backup cũng không hoạt động
- Việc khôi phục chỉ khả thi nhờ dữ liệu production từ khoảng 6 giờ trước đó đã được chép sang môi trường staging
- Quá trình khôi phục mất khoảng 24 giờ, và dẫn tới mất khoảng 6 giờ dữ liệu
- Cùng thời gian đó, GitLab vẫn muốn tiếp tục theo đuổi database sharding, nhưng theo dữ liệu lúc bấy giờ và đánh giá của kỹ sư thì đó không phải hướng giải quyết phù hợp
- GitLab có tỷ lệ yêu cầu đọc so với ghi khoảng 10:1
- Quy mô dữ liệu lưu trữ cũng chưa đủ lớn để biện minh cho độ phức tạp của sharding
- Một tư vấn viên thậm chí còn nói rằng với những khách hàng có tải và dung lượng lớn hơn nhiều, sharding vẫn là quá mức cần thiết
2019–2021: Đội Delivery và cải thiện thời gian triển khai
- Khoảng năm 2018–2019, vì đã mệt mỏi với công việc về hiệu năng và độ tin cậy, tác giả chuyển sang đội Delivery mới được thành lập
- Mục tiêu của đội Delivery là cải thiện quy trình phát hành và công cụ của GitLab, trong khi tình trạng khi đó khá hỗn loạn
- Từ lúc một commit vào nhánh main đến khi được triển khai lên GitLab.com trung bình mất vài ngày, và trường hợp tệ nhất có thể lên tới 3 tuần
- Nút thắt lớn nhất là GitLab Community Edition và GitLab Enterprise Edition tồn tại dưới dạng hai kho Git riêng biệt
- Thường xuyên cần merge thủ công và xử lý conflict
- Để giải quyết vấn đề này, một dự án kéo dài nhiều tháng đã được thực hiện nhằm hợp nhất hai codebase thành một
- Công việc liên quan được công bố trong Merging CE and EE codebases
- Đội Delivery đã cải thiện đáng kể quy trình phát hành, đưa tốc độ triển khai thay đổi xuống mức có thể trong vài giờ
- Việc giảm từ mức tệ nhất 3 tuần xuống mức tệ nhất khoảng một ngày là một cải thiện lớn
- Tuy vậy, tốc độ đó vẫn chưa đủ nhanh theo tiêu chuẩn lý tưởng
Thay đổi văn hóa tổ chức và quá trình dẫn tới nghỉ việc
- Năm 2018 là năm cuối cùng của GitLab summit mang tính hướng nội cho nhân viên; từ sau 2019, nó chuyển dần sang hình thức gần với một hội nghị truyền thống dành cho khách hàng
- Với các buổi tụ họp quy mô hơn 2.000 người, đây là thay đổi dễ hiểu về mặt tài chính do chi phí rất lớn, nhưng xét về trải nghiệm xã hội thì kém vui hơn trước
- Vấn đề quản lý laptop cũng là một nguồn xung đột lặp đi lặp lại
- GitLab yêu cầu hoặc xem xét yêu cầu cài phần mềm quản trị từ xa đối với nhân viên truy cập tài nguyên GitLab bằng máy Mac của công ty hoặc phần cứng cá nhân
- Các công cụ được đề xuất có tính xâm phạm và có thể dùng để ghi lại hoạt động người dùng, trong khi tác giả cảm thấy thiếu bảo đảm chống lạm dụng
- Nhiều phản hồi từ nhân viên có lúc bị phớt lờ cho đến khi những nhân sự chủ chốt tạo áp lực
- Cuối cùng GitLab chọn giải pháp quản lý laptop dựa trên SentinelOne
- Sự thay đổi văn hóa cùng những thay đổi cá nhân khiến động lực và năng suất giảm, còn căng thẳng thì tăng
- Sau khi người quản lý được đánh giá cao chuyển sang vai trò khác và một quản lý mới tiếp quản đội, xung đột bắt đầu phát sinh, và tác giả bị đưa vào performance enablement plan
- PEP là bước trước PIP, nhằm đưa mối quan hệ và công việc trở lại trạng thái bình thường
- Ban đầu đây được mô tả là quy trình để cả hai phía cùng cải thiện, nhưng trên thực tế tác giả cảm thấy nó chỉ tập trung vào những thay đổi mà bản thân phải thực hiện
- Kế hoạch ban đầu kéo dài một tháng nhưng được gia hạn thêm một tháng, và sau hai tháng kết quả được đánh giá là đạt yêu cầu
- Sau đó, tác giả dần cảm thấy mình và GitLab đang đi theo hai hướng khác nhau nên bắt đầu nghĩ đến việc rời đi
- Việc GitLab IPO và thời điểm thực hiện stock option khiến tác giả có thể nghỉ việc vào tháng 12/2021
- Khi đó tại Hà Lan, việc thực hiện stock option bị đánh thuế thu nhập 52% trên phần chênh lệch giữa giá thực hiện và giá trị định giá, bất kể cổ phiếu đã thanh khoản hay chưa
- Gánh nặng thuế quá lớn nên trước khi GitLab IPO, rất khó để thực hiện quyền chọn
- Về sau luật thay đổi, cho phép chọn thời điểm nộp thuế là lúc thực hiện quyền hoặc lúc cổ phiếu được thanh khoản
- Tháng 12/2021, tác giả rời GitLab để tập trung toàn thời gian vào Inko
Những bài học rút ra từ trải nghiệm ở GitLab
-
Khả năng mở rộng phải trở thành văn hóa công ty
- Theo tác giả, GitLab đã không ưu tiên đầy đủ cho khả năng mở rộng, và ngay cả khi rời đi thì vấn đề này vẫn còn tiếp diễn
- Phần lớn doanh thu của GitLab không đến từ GitLab.com mà đến từ các khách hàng self-hosting GitLab Enterprise Edition
- GitLab.com tiêu tốn chi phí lớn hơn rất nhiều so với số tiền nó tạo ra, vì vậy trọng tâm bị dồn về thị trường self-hosting
- Nhiều vấn đề hiệu năng của GitLab.com không áp dụng trực tiếp cho phần lớn khách hàng self-hosting
- Nhiều lập trình viên muốn cải thiện hiệu năng nhưng không có đủ thời gian và tài nguyên để làm điều đó
-
Đội ngũ nên vận hành dựa trên dữ liệu và lập trình viên
- GitLab mang tính product manager-led khá mạnh, và những tính năng cần triển khai chủ yếu do product manager cùng director quyết định
- Một số quyết định là hợp lý, nhưng cũng có những quyết định tạo cảm giác như chỉ vì ai đó thấy ý tưởng đó hay trên Hacker News nên phải làm
- Theo tác giả, kết quả có thể tốt hơn nếu sớm áp dụng cấu trúc phân cấp đơn giản hơn, trao nhiều quyền hơn cho team lead và để họ tương tác với người dùng nhiều hơn
- Vai trò của product manager nên là vừa đóng góp vào việc xây dựng sản phẩm về mặt kỹ thuật, vừa làm cầu nối giữa đội ngũ và người dùng
-
Không có dữ liệu thì rất khó đánh giá thế nào là “minimal viable”
- Một trong những nguyên tắc cốt lõi của GitLab là luôn bắt đầu với minimal viable change
- Vấn đề là mỗi người lại có định nghĩa khác nhau về “minimal”
- Có đội xem hiệu năng hay trải nghiệm sử dụng tốt là một phần của yêu cầu viable, nhưng có đội khác lại không coi đó là quan trọng
- Kết quả là có những tính năng được xây ra nhưng không hữu ích với người dùng
- Nền tảng serverless không ai yêu cầu và cuối cùng bị khai tử
- Hỗ trợ quản lý Kubernetes cluster đã không hoạt động suốt 3 tuần mà không ai nhận ra
- Giải pháp chatops được xây trên CI thay vì dùng giải pháp có sẵn
- Tính năng requirements management chỉ tạo và xem được, không thể sửa hay xóa
- GitLab có thực hiện user survey hàng quý và một số đội có quyền truy cập dữ liệu tương tác người dùng, nhưng theo ký ức của tác giả và trao đổi với đồng nghiệp cũ, dữ liệu này chỉ được dùng gián đoạn chứ không phải cốt lõi của workflow đội ngũ
-
SaaS và self-hosting rất khó vận hành cùng lúc
- GitLab cung cấp cả cài đặt self-hosting lẫn SaaS
- Hai mô hình này khác nhau về cấu trúc doanh thu, yêu cầu và cách áp dụng cập nhật
- SaaS cần triển khai nhanh và xử lý khối lượng dữ liệu cùng workload lớn trên hạ tầng tập trung
- Phần lớn instance self-hosting nhỏ hơn rất nhiều so với SaaS, nên các vấn đề và giải pháp của SaaS không thể bê nguyên sang
- Kết quả là nhiều phần của nền tảng phải tính tới hai code path riêng cho SaaS và cho self-hosting
- Nếu chỉ tập trung vào một trong hai, công ty có thể dồn toàn bộ sự chú ý vào trải nghiệm phù hợp với mô hình vận hành đó
-
Nhiều người hơn không đảm bảo kết quả tốt hơn
- GitLab đã tuyển rất nhiều người qua nhiều năm và hiện có hơn 2.000 nhân viên
- Tác giả không biết chính xác số lượng lập trình viên, nhưng chỉ cần lướt qua trang đội ngũ cũng có thể ước tính là ít nhất vài trăm người
- Việc thêm người vào một dự án không có nghĩa năng suất và kết quả sẽ tự động tốt hơn; điều này cũng liên hệ với “The Mythical Man-Month”
- Dù không có dữ liệu cụ thể, tác giả cho rằng phần lớn công ty chỉ cần dưới 20 lập trình viên; một số cần 20–50; và chỉ rất ít công ty cần 50–100
- Khi số lập trình viên vượt quá 100, nên tự hỏi liệu phạm vi sản phẩm có đang phình ra quá mức hay không
- Nhận định này áp dụng cho lập trình viên phần mềm; các lĩnh vực như sản xuất custom hardware, sales hay support có chi phí đồng bộ khác nên là ngoại lệ
-
Đánh giá về Ruby on Rails có hai mặt
- GitLab được xây bằng Ruby và Ruby on Rails, và bộ đôi này đã đóng góp lớn vào thành công của GitLab
- Nhưng đồng thời, khi dự án trở nên lớn và có nhiều người đóng góp với mức kinh nghiệm khác nhau, Rails khiến việc viết ra mã có hiệu năng kém trở nên khá dễ dàng
- Vấn đề tiêu biểu là N+1 query problem
- ActiveRecord của Rails có chức năng để xử lý vấn đề này, nhưng theo kiểu opt-in
- Nếu lập trình viên quên dùng, truy vấn sẽ xảy ra theo từng row và gây ra vấn đề hiệu năng
- Nhiều vấn đề hiệu năng được giải quyết trong những năm đầu của GitLab thực chất là N+1 query
- Bản thân Ruby là một ngôn ngữ tuyệt vời, nhưng đặc tính dùng nhiều meta programming lại gây khó khăn trong các dự án lớn
- Theo tác giả, Go, Rust và Node.js có thể hiệu quả hơn Ruby, nhưng không có framework nào mạnh bằng Ruby on Rails
- Python và Django cũng có thể là lựa chọn, nhưng nhiều khả năng vẫn sẽ gặp một phần các vấn đề tương tự của Ruby và Rails
-
Thời gian triển khai rất quan trọng với thành công của tổ chức
- Theo tác giả, sau khi mã được push lên nhánh hoặc tag đích để triển khai, nó phải có thể được triển khai trong tối đa một giờ
- GitLab mất khoảng 4 năm để tiến gần đến mức đó, và vẫn còn việc phải làm
- Triển khai nhanh giúp ích cho việc ứng phó sự cố
- Nếu một lần triển khai mất hàng giờ, có thể phải cần hot-patch
- Triển khai nhanh cũng ảnh hưởng đến động lực làm việc
- Có cảm giác thỏa mãn khi có thể thực sự nhìn thấy và sử dụng thay đổi mình đã tạo ra
- Việc phải chờ thêm 2 tuần để thay đổi mình làm suốt nhiều tuần mới được triển khai sẽ làm giảm động lực
- Tổ chức cần rất quyết liệt trong việc rút ngắn thời gian triển khai và thời gian test suite chiếm dụng trong quá trình đó
- Điều cốt lõi không phải là mọi bài test hay mọi lần triển khai đều phải dưới một ngưỡng cố định, mà là phải ưu tiên việc triển khai nhanh nhất có thể trong phạm vi các yêu cầu kinh doanh cho phép
-
Lương theo vị trí là phân biệt đối xử
- Mức lương ở GitLab chịu ảnh hưởng của nhiều biến số, trong đó có vị trí địa lý
- Nếu là công ty có văn phòng vật lý và phải tuyển ở một số khu vực nhất định, việc điều chỉnh theo vị trí có thể hiểu được; nhưng với một công ty remote hoàn toàn, tác giả cho rằng không có lý do chính đáng để trả lương khác nhau cho hai người có cùng kinh nghiệm và trách nhiệm chỉ vì nơi họ sống
- Khi nghỉ việc, mức lương của tác giả tại Hà Lan là khoảng €120.000/năm trước thuế, tương đương khoảng €8.500/tháng
- Nếu sống ở Bay Area, tác giả cho rằng mình có thể nhận ít nhất gấp đôi, thậm chí còn hơn thế
- Giải pháp là trả công dựa trên yêu cầu của vai trò công việc, chứ không phải vị trí của ứng viên
- 0xide Computer Company được nhắc đến như một công ty trả cùng một mức tiền thay vì dựa trên vị trí
- Nội dung liên quan được bàn trong Compensation as a Reflection of Values
Kết luận
- Thời gian ở GitLab là trải nghiệm pha trộn giữa rất nhiều điều tích cực và tiêu cực
- Tác giả cảm thấy rất tự hào về những gì đã đạt được ở nhiều đội khác nhau cũng như về những người từng cùng làm việc
- Điều đáng tiếc là khoảng một năm cuối đã để lại vị đắng cho toàn bộ trải nghiệm
- Tác giả không hối hận vì đã làm việc ở GitLab, và nếu có thể làm lại thì vẫn sẽ làm, chỉ là sẽ làm khác đi đôi chút nhờ kinh nghiệm nhìn lại
- Dù có những khiếm khuyết, tác giả vẫn cho rằng GitLab tốt hơn rất nhiều công ty khác và vẫn là một nơi đáng để giới thiệu làm việc
1 bình luận
Các ý kiến trên Hacker News
Nếu công ty hạ lương vì màu da hay giới tính thì đó là vấn đề lớn, nhưng so sánh rằng vì sao hạ lương theo nơi cư trú lại được chấp nhận thì cần suy nghĩ thêm
Màu da·giới tính và nơi cư trú khác nhau ở chỗ có thể thay đổi được hay không, và có thực sự liên quan đến công việc hay không
Nơi cư trú có liên quan đến công việc vì công ty phải gánh việc thành lập pháp nhân địa phương, hiểu hệ thống tư pháp·thuế, múi giờ, chi phí công tác, v.v.
Có thể tranh luận việc trả lương theo khu vực là đúng hay sai, nhưng nếu so sánh điều đó với phân biệt chủng tộc·giới tính thì chẳng khác nào biến GitLab thành một tổ chức phân biệt chủng tộc·giới tính, khiến cuộc thảo luận nhanh chóng kết thúc
Người viết nói rằng nếu sống ở Bay Area thì đáng lẽ nhận được hơn gấp đôi, nên chỉ vì nơi cư trú khác mà như vậy là bất công, nhưng có vẻ không có điểm nào để nhận mình là nạn nhân ở đây
Lập luận này gần với việc chưa hiểu rõ kinh tế
Mức lương tôi nhận ở Mỹ hiện nay khoảng gấp đôi khi ở Anh, nhưng mức sống thì tương tự; có mặt tệ hơn và có mặt tốt hơn
Nếu tác giả bài gốc chuyển đến Bay Area, rất có thể dù thù lao cao hơn thì mức sống lại giảm xuống
Cần cân nhắc không chỉ thu nhập mà cả an sinh xã hội, thuế và văn hóa; tôi thậm chí cũng sẵn sàng chấp nhận giảm lương lớn để quay lại châu Âu sống thoải mái hơn
Động cơ trả lương theo khu vực của GitLab được nêu tại https://handbook.gitlab.com/handbook/total-rewards/compensat..., và trông khá hợp lý
Nếu trả lương Bay Area cho cả Philippines hay Ukraine, mọi người có thể bị trói bởi còng tay vàng, không thể rời đi ngay cả khi cần, và có thể bị burnout
Ngược lại, nếu trả mức lương trung vị toàn cầu thì ở California hay London sẽ không tuyển được người
Lập luận rằng không cần product manager và không nên có hơn 100 lập trình viên cho một sản phẩm cũng gây tranh cãi
Tác giả bài gốc có vẻ là một kỹ sư xuất sắc với mức tự chủ cao, kiểu người có lẽ sẽ hạnh phúc và thành công hơn nhiều ở một startup tương đối nhỏ
Nếu không phải chờ thay đổi quy định thuế, có lẽ anh ấy đã rời đi sớm hơn và viết được một câu chuyện trải nghiệm tích cực
Cũng đáng nghĩ xem nếu ngoài cổ phiếu còn nhận $300k thù lao ở Amsterdam thì việc rời công ty sẽ khó đến mức nào
Nếu bắt buộc trả lương như nhau trên toàn thế giới, các công ty có khả năng sẽ chỉ muốn tuyển tại địa phương vì lợi thế offsite, cùng múi giờ và giao tiếp
Điều này đặc biệt đúng trong bối cảnh kinh tế mà ngay cả ở các khu vực chi phí sinh hoạt cao cũng có nhiều ứng viên muốn được tuyển
Tương lai có thể thay đổi, nhưng nhìn vào cấu trúc động lực thực tế sẽ hữu ích hơn
Các công ty tuyển dụng ở quốc gia khác cũng chấp nhận rủi ro, và điều đó cũng có tác dụng để lại tri thức tại địa phương cùng những hạt giống cho các công ty tương lai
Việc đến văn phòng đem lại cho nhân viên sức mạnh đàm phán lương nhờ chi phí sinh hoạt của khu vực đó, nhưng trong một công ty và văn hóa hoàn toàn từ xa, công ty có thể tuyển ở bất cứ đâu và trả mức lương gần với mẫu số chung thấp nhất
Làm việc từ xa khiến mọi người giống như nhà thầu độc lập cạnh tranh với nhân tài trên toàn thế giới, còn làm việc tại văn phòng chủ yếu khiến họ cạnh tranh với những người trong cùng khu vực
Có vẻ đây là câu chuyện của một người là nhân viên thứ 28, từng báo cáo trực tiếp cho CEO, rồi dần dần có các quản lý chen vào phía trên; một trong số họ đưa người này vào PEP, người này nhận ra tín hiệu và rời đi
Đây là một diễn biến khá tiêu chuẩn, và có thể là một trong những lý do khiến ở các công ty lớn, mọi người khó làm được những việc lớn
Ngay cả khi khởi xướng và làm thành công một dự án trong công ty, công ty vẫn sẽ đưa những người cấp trên vào, và cuối cùng bạn trở thành nhân viên thứ n trong chính dự án mình bắt đầu, rồi có thể bị chê là thiếu thành tích
Chỉ muốn làm những việc vui và thú vị, cuối cùng lại có quan điểm mạnh về những thứ không quan trọng; một individual contributor thân với CEO mà không công nhận lựa chọn của quản lý thì sẽ trở thành ác mộng quản lý
Có thể di chuyển chỗ này chỗ kia và tạo ra vấn đề mà không chịu trách nhiệm ra quyết định
bảo mật endpoint và việc dùng thiết bị cá nhân là một trong những manh mối
Văn hóa dễ dãi như vậy không thể mở rộng vì chi phí tuân thủ quy định và năng suất phát triển
Khó tách một lập trình viên kỳ cựu khỏi bản phân phối Linux ưa thích của họ, nhưng đúng hơn là dùng máy tính công ty cho công việc và để công ty quản lý cập nhật
Câu chuyện sao lưu cơ sở dữ liệu cũng tương tự: nếu là đội cơ sở dữ liệu thì sao lưu là công việc ưu tiên số 1
Không thể lướt qua câu “không có bản sao lưu” bằng thể bị động; có vẻ họ quan tâm đến tranh luận kiến trúc sharding hơn là duy trì site hằng ngày
Kết luận rằng GitLab không đầu tư đủ vào hiệu năng của sản phẩm hosting cũng vậy: nếu sản phẩm đó lỗ nặng thì việc không đổ thêm tài nguyên vào có thể là điều hiển nhiên
Cần thuyết phục bằng cơ sở kinh doanh thực tế rằng vì sao việc đó quan trọng hơn và kiếm ra tiền, chứ không phải bằng kỹ thuật thú vị
Một quản lý đã cùng tôi khởi động một dự án thành công, nhưng ban lãnh đạo tham lam kéo chính trị và các thế lưỡng nan xã hội vào, chèn thêm tầng quản lý, rồi tìm cách thay thế tôi và người quản lý đó
Tôi đã học được lý do vì sao không nên thật lòng quan tâm đến công việc, và vì thế tôi có cảm giác dự án sẽ hỏng và bị giải thể
Ở đây có bầu không khí giả định rằng nhân viên đó thực sự là người hiệu suất cao, không cần quản lý, và không đáng bị đưa vào PEP, nhưng đó không phải là giả định an toàn
Tôi từng thấy các nhân viên giai đoạn đầu ở startup không thể, hoặc không muốn, phát triển theo tốc độ công ty và vai trò mở rộng
Họ thường được giữ lại vì sự tôn trọng đối với đóng góp trong quá khứ, kiến thức lịch sử khó thay thế, và quan hệ với nhà sáng lập cùng những nhân viên đầu tiên đã trở thành lãnh đạo
Nhưng việc là nhân viên giai đoạn đầu và từng tham gia dự án quan trọng ban đầu không có nghĩa là họ vẫn là người giỏi nhất hoặc phù hợp nhất để tiếp tục phụ trách việc đó
Dù rất giỏi trong việc vận hành thứ gì đó bằng các biện pháp tạm, cron job và can thiệp thủ công, ở công ty lớn cách vận hành như vậy có thể hoàn toàn không phù hợp
Nếu không thích nghi được, hoặc bất mãn vì phải làm việc theo cách của công ty lớn, thì hại nhiều hơn lợi
Công ty giai đoạn đầu nào cũng có những nhân viên ban đầu không lớn lên cùng công ty, nhưng đó không phải là kết cục duy nhất hay phổ biến
GitLab cũng có nhiều nhân viên làm lâu năm, nhưng trong một bài blog đầy bất mãn ta không nghe từ họ, nên cần tính đến thiên lệch chọn mẫu
Tôi đã dùng GitLab lâu năm, và sản phẩm vẫn tiếp tục phát triển, nên tôi không đồng ý với nhận định rằng đó là một sản phẩm trì trệ
Ba năm sau, khi thấy các bản phát hành liên tục thất bại, chuyện đó mới trở thành vấn đề, nhưng cảm giác đó không phải nhờ ảnh hưởng của tôi mà giống như kết quả của việc ai đó tìm trên Google “cách ngăn release thất bại”
Tôi không biết cách giải quyết, và hiện giờ vẫn đang trải qua cùng chuyện đó với một chủ đề khác
Ban đầu chỉ đơn giản là làm những việc cần làm, nhưng về sau mọi bước đều phải đi qua một vị trí quản lý mới được chèn vào, với lý do để đảm bảo không làm sai việc
Điều đó xảy ra bất kể các ý tưởng và đóng góp ban đầu đã giúp công ty có thể phát triển
Tôi tự hỏi liệu bối cảnh các issue liên quan đến GitLab CI tồn đọng suốt nhiều năm có liên quan đến chuyện này không
Nhìn từ bên ngoài, GitLab dường như đã hoàn toàn mất khả năng tạo ra những thứ tuyệt vời, và tạo ấn tượng rằng họ không muốn sửa cả những lỗi đã tồn tại nhiều năm và cứ lặp đi lặp lại
Đoạn nói rằng họ cho phép nhân viên dùng máy tính cá nhân gần như gây ngạc nhiên
Dù tổ chức nhỏ đến đâu, cũng nên cung cấp thiết bị thuộc sở hữu công ty và yêu cầu mọi công việc của công ty được thực hiện trên thiết bị đó
Công ty có lợi ích lớn về mặt kiểm soát sở hữu trí tuệ, còn nhân viên cũng được hỗ trợ rất nhiều trong việc tách bạch thời gian làm việc và thời gian cá nhân, mà chi phí cũng không quá lớn
Dù đi đâu bạn cũng có thể dùng nguyên bộ công cụ mình muốn, và khả năng xóa nhanh rồi tạo lại cũng rất hữu ích khi debug các vấn đề kiểu “trên máy tôi thì chạy/không chạy”
Ở một cực là cách dựa vào trí nhớ, còn ở cực kia là cách dùng https://nixos.org/ để tạo bản build hoàn toàn tái lập được ở bất cứ đâu
Ở giữa cũng có nhiều lựa chọn, và tôi từng thấy có người quản lý một bộ file Ansible cài những thứ cần thiết với
host: localhostTôi dùng phiên bản Ubuntu mới nhất và duy trì vài script shell [1] để cài khoảng 80% những thứ tôi muốn trên một bản cài mới
Nếu muốn tiếp cận theo kiểu khoa học, bạn có thể cài thứ gì đó như https://atuin.sh/ để thống kê các chương trình mình thực sự thường chạy, dựa trên lịch sử shell dài hạn
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
Không phải giải pháp hoàn hảo, nhưng ít nhất nếu là thiết bị công ty thì việc rò rỉ sẽ là hành vi ác ý, hoặc là kết quả của sự kém năng lực khi chuyển dữ liệu nhạy cảm qua một đường không được phê duyệt
Nếu công ty bị kiện, nội dung trên thiết bị cá nhân cũng có thể trở thành đối tượng của đủ loại lệnh triệu tập
Việc yêu cầu thiết bị riêng không nhất thiết mang lại lợi ích cho người dùng về cân bằng công việc-cuộc sống, mà chỉ gây bất tiện
Hành vi tách bạch thời gian làm việc và thời gian cá nhân chủ yếu phụ thuộc vào thói quen, năng lực của bản thân, và cuối cùng là quyết định của chính mình
Trước đây tôi từng cảm thấy trả lương theo khu vực là phân biệt đối xử, nhưng giờ phần lớn đã thoát khỏi suy nghĩ đó
Rốt cuộc đó là đòi hỏi mức lương SF, và người Ấn Độ sẽ đòi mức lương của Hà Lan hoặc SF
Làm vậy có khả năng tạo ra một cuộc đua xuống đáy
Sự thật đơn giản là mỗi người đã kiếm đủ để sống tốt ở khu vực của mình
Nếu muốn nhiều hơn thì có thể chuyển đi, còn nếu không chuyển thì hẳn là có lý do
Ai cũng muốn lương SF và chi phí sinh hoạt của Indiana hoặc India, nhưng vì những lý do hiển nhiên, điều đó khó mà thành hiện thực
Nếu được tuyển, dù ở San Francisco, Poland hay Indonesia, bạn cũng nhận lương mức Mỹ
Những vị trí như vậy cạnh tranh cực kỳ khốc liệt
Vì họ mở cửa cho cả thế giới và nói “hãy cho chúng tôi thấy bạn có gì”, nên họ có thể xem xét một nhóm ứng viên và nhân tài lớn hơn nhiều, trong đó có rất nhiều nhân tài ngoại lệ, cực kỳ thông minh và có động lực mạnh từ các nước nghèo
Cung và cầu vận hành như vậy
Nếu nói sẽ trả nhiều hơn, thường bạn sẽ tuyển được ứng viên ở trình độ cao hơn
Tôi biết khá nhiều người làm việc từ xa ở nhiều bang của Mỹ và nhận lương mức SF
Tất nhiên là có thể
SF cũng không nên quá tự mãn
Detroit từng là Motor City lẫn Music City, một trung tâm văn hóa và công nghệ tầm thế giới, nhưng năng lực cốt lõi của nó đã bị lung lay bởi lao động ở các khu vực khác rẻ hơn và hiệu quả hơn
Điều được yêu cầu là cùng công việc, cùng mức lương
Nếu các thành viên trong nhóm làm cùng một việc mà người khác nhận đủ còn chỉ mình bạn nhận một phần, thì đó là sự lệch lạc nghiêm trọng
Đóng góp cho nhóm không phụ thuộc vào việc hiện bạn đang ở đâu
Việc bạn mất bao nhiêu thời gian đi làm cũng không thay đổi kỳ vọng về đầu ra
Nếu vị trí văn phòng quá đắt đỏ, công ty nên giải quyết bằng cách tìm địa điểm rẻ hơn, chứ nhân viên không có lý do gì phải trợ cấp cho vị trí văn phòng tệ của công ty
100k mà nhân viên nhận và chi phí của công ty là hai thứ khác nhau
Mỗi nước có các khoản thuế, an sinh xã hội, phúc lợi mà công ty phải gánh thêm khác nhau, và trong nhiều trường hợp cần có pháp nhân địa phương hoặc một hình thức doanh nghiệp ảo, cùng nguồn lực hỗ trợ tuân thủ luật địa phương
Tôi cũng thuộc phía nhân viên nhận lương theo chuẩn địa phương khi làm vai trò toàn cầu tại một công ty đa quốc gia, nhưng có nhiều điều cần cân nhắc hơn vẻ bề ngoài
Về cơ bản, họ điều chỉnh theo chi phí sinh hoạt chứ không phải chi phí tuyển dụng, nhưng vẫn nhắm tới mức lương tương đương
Quản lý tồi là vấn nạn của ngành
Ngược lại, nhiều startup ra đời vì nhà sáng lập từng gặp quản lý tồi ở công ty trước
Tôi nhớ đến câu chuyện về traitorous eight và Fairchild Semiconductors
Cá nhân tôi có lẽ cũng đã không có động lực khởi nghiệp nếu ở công ty trước không gặp một quản lý phi kỹ thuật, thiên về chính trị và hay trả đũa
Nhìn lại, tôi còn nghĩ giá mà mình gặp một quản lý tệ như vậy sớm hơn trong giai đoạn đầu sự nghiệp
Cũng sẽ tốt nếu có thể dễ dàng chuyển sang các công ty thực sự cần kỹ năng của mình hơn mà không phải chịu gánh nặng quy trình nhân sự
Có ý kiến cho rằng toàn bộ mô hình lập trình của Ruby dựa trên tiền đề rằng phần lớn thời gian là chờ I/O hoặc mạng, nên tốc độ ngôn ngữ không quan trọng
Nhưng hiện nay phía Node.js và JVM có mô hình làm việc khác hoặc xử lý nhiều request hơn trong khi chờ I/O/mạng
Năm 2024, dùng Ruby/Rails có thể là lãng phí, nhưng với các ứng dụng doanh nghiệp có số lượng người dùng hạn chế, khi tốc độ phát triển là tối quan trọng, hoặc các prototype nhanh để kiểm chứng thị trường, đó vẫn có thể là lựa chọn tốt
Rails là một framework tuyệt vời và năng suất rất cao, nhưng các dự án Rails đã 2–3 năm tuổi luôn khó bảo trì
Dự án Rails không khó hơn dự án Django hay Express
Bất kỳ codebase nào cũng cần kỷ luật và chăm sóc đều đặn để cỏ dại không mọc lên
Nếu Ruby và Rails có điểm yếu thì đó vẫn là hiệu năng thô của ngôn ngữ cùng yêu cầu và mức sử dụng bộ nhớ cao hơn, nên kém hấp dẫn hơn cho các tác vụ cần độ trễ thấp hoặc footprint bộ nhớ nhỏ
Theo kinh nghiệm, nó chủ yếu gây đau khi traffic đột ngột dao động mạnh, hoặc khi có rất nhiều người dùng hoạt động dùng websocket; phần websocket thì anycable giải quyết được phần lớn
Nhưng rất ít sản phẩm sẽ chạm đến các giới hạn đó, và ngay cả khi chạm đến thì vẫn có thể giải quyết
Stripe, GitHub, Shopify là các ví dụ tiêu biểu cho việc Rails đã scale ổn theo nhiều cách
Động lực lớn dẫn dắt Rails là quan điểm của DHH về hạnh phúc của developer, điều này gắn chặt với tốc độ phát triển
Việc cộng đồng Rails có thảo luận về I/O là vì nó quan trọng với vận hành web server, chứ không phải là trọng tâm duy nhất hay chủ đạo khi quyết định ngôn ngữ hoặc framework
Nếu mục tiêu là tối đa hóa mức sử dụng CPU của web server, Rails cũng có thể làm bằng cách chạy nhiều process, một cách tương tự với việc chạy nhiều thread trên JVM và đã được dùng từ lâu
Có thể kém tiện hơn, nhưng đây là mô hình đã được dùng từ thập niên 90, và web request thường chạy độc lập nên giao tiếp giữa các process cũng thường không phải vấn đề lớn
Khái quát hóa là “lãng phí” thì quá mạnh tay
Viết ứng dụng bằng Rust cũng có thể là lãng phí tùy hoàn cảnh, phụ thuộc vào áp lực nằm ở đâu
Ở giai đoạn đầu, không ra mắt được mới là nỗi lo lớn hơn nhiều, và ngay cả giai đoạn giữa/cuối, tốc độ của developer vẫn là một trong những yếu tố khó scale nhất
Với tư cách CTO của một công ty dùng backend Rails và frontend React, tốc độ phát triển rất quan trọng, và tốc độ phát triển với Rails tiếp tục là lợi thế lớn
Vấn đề scale cũng có, nhưng 99% không phải vấn đề của Rails mà là vấn đề cơ sở dữ liệu
Tôi xem việc công ty muốn trả lương cho kỹ sư dựa trên vị trí là một dạng phân biệt đối xử khác
Nên trả theo năng lực của nhân viên, không phải theo vị trí
Quy định của chính phủ nói không được phân biệt đối xử theo giới tính, tôn giáo, xu hướng tính dục, v.v.; vậy phân biệt lương theo vị trí có công bằng không?
Tôi đã thấy những người bạn chuyển từ Europe sang Asia trong cùng vai trò, cùng con người, cùng công việc, nhưng bị trả ít hơn chỉ vì vị trí thay đổi
Nếu họ chuyển đến một thị trường kém cạnh tranh hơn và khó tìm việc khác hơn, khả năng họ vẫn đi làm với mức lương thấp hơn sẽ cao hơn
Dù làm từ xa có vẻ như không bị ràng buộc vào thị trường địa phương, chính phủ thường dựng rào cản lớn với tuyển dụng quốc tế, nên một số nước có thể trở thành thị trường kém cạnh tranh hơn
Nếu ở cùng một công ty, làm cùng một việc, nhưng chuyển sang nước khác và lương bị giảm, gần như chắc chắn đó là lý do họ chấp nhận mức cắt giảm đó
Tôi cho rằng công ty nên trả lương dựa trên khả năng để nhân viên có được sự thoải mái và sức khỏe, hơn là dựa trên một thước đo giá trị phổ quát nào đó
Tôi nghĩ một giá trị phổ quát như vậy là bất khả thi
Lập luận chỉ dựa trên năng lực vô tình phá vỡ cộng đồng, và thông qua bất bình đẳng làm trầm trọng thêm hiện tượng gentrification cũng như phá hoại sự gắn kết xã hội
Vị trí là quan trọng
Mục đích là để cho người ta cùng chất lượng sống, cùng loại nhà ở, cơ hội nuôi gia đình và cơ hội cho con học ở các trường tương tự
Chi phí của những thứ này khác nhau giữa các quốc gia, nên thu nhập cần thiết cũng khác nhau
Công ty cần một năng lực cụ thể, và thị trường định giá năng lực đó bao nhiêu thì họ chỉ trả chừng đó, không hơn
Thị trường định giá cùng một năng lực khác nhau tùy vị trí, nên lương cũng khác nhau
Tôn giáo là một ngoại lệ hơi mơ hồ, nhưng dù công bằng hay không, chuyện này không phải là phân biệt đối xử
Nếu GitLab.com luôn tốn chi phí cao hơn nhiều so với số tiền kiếm được, và công ty chủ yếu kiếm tiền từ khách hàng self-hosted GitLab Enterprise Edition, tôi tự hỏi liệu việc không đầu tư đủ vào khả năng mở rộng có thật sự là sai lầm không
Trước hết, công ty nên đầu tư vào những thứ kiếm ra tiền hơn là những thứ làm mất tiền
Có thể có nhận định ở tầm cao hơn rằng gitlab.com hiệu năng tốt hơn sẽ mang lại nhiều khách hàng và danh tiếng hơn, nhưng nếu hoạt động kinh doanh thực sự là bán phần mềm self-hosted thì tập trung nguồn lực phát triển vào đó là hợp lý
Thực tế là sau khi mua license GitLab, biết rằng chi phí theo ghế là như nhau dù để GitLab hosting hay tự chúng tôi hosting, tôi đã tự hỏi tại sao chúng tôi phải gánh chi phí hạ tầng
Nếu định làm GitLab.com nửa vời, thì hoặc làm cho đàng hoàng, hoặc có thể về dài hạn nên bỏ sản phẩm và chỉ tập trung vào khách hàng self-hosting như GitLab Enterprise Edition
Nhưng chắc không ai trong ban lãnh đạo muốn đưa ra quyết định như vậy
Vì thế sản phẩm bị vận hành kiểu nửa vời
Với những người thật sự quan tâm đến bản thân sản phẩm, tình huống này có thể gây bực bội
Mỗi khi developer mới vào, họ sẽ nói “chúng ta cần chú ý hơn đến khả năng mở rộng”, còn các senior thì đáp “ừ ừ, biết rồi…”
Về mặt kinh tế, nếu một lập trình viên ở Amsterdam mang lại giá trị tương đương một lập trình viên ở Bay Area, thì rất có khả năng nên trả cùng mức lương
Giá thị trường địa phương của lập trình viên Amsterdam thấp hơn, nhưng bạn đang xây dựng một công ty toàn cầu và cạnh tranh với các công ty toàn cầu khác
Hiện tại bạn có thể tuyển được lập trình viên Amsterdam với giá chiết khấu, nhưng cuối cùng đối thủ sẽ đưa ra mức gần với giá trị hơn, hoặc họ sẽ rời đi để làm việc của riêng mình
Có lẽ những công ty mạnh nhất sẽ trả lương không phụ thuộc vị trí cho nhân tài
Sau cùng, điều quan trọng là giá trị được tạo ra
Nếu bạn có một codebase Ruby lớn như GitLab và muốn bán cho các doanh nghiệp lớn coi trọng hiệu năng và độ ổn định, tôi nghĩ bạn sẽ trả cho người như vậy hơn €120k mỗi năm
Phần lớn kỹ sư coi trọng hiệu năng, an toàn kiểu và độ ổn định không quan tâm đến Ruby, nên giá thị trường cho tổ hợp kỹ năng đó chắc chắn cao hơn
Tôi không biết liệu có ở mức $500k/năm như Bay Area hay không, nhưng các công ty mạnh muốn có nhân tài hàng đầu sẽ mất người nếu không gắn đãi ngộ với giá trị tạo ra thay vì vị trí
Thời gian cần để triển khai code là một trong những chỉ số quan trọng nhất, thậm chí có thể là quan trọng nhất, để duy trì tốc độ của lập trình viên khi startup mở rộng
Chuyển đổi ngữ cảnh là một trong những tác vụ tốn kém nhất trong công việc hằng ngày của lập trình viên, nhưng cũng là thứ dễ bị xem nhẹ nhất
Các quản lý thường thích sắp lịch của cả nhóm theo lịch của mình, nhưng điều này thường xuyên làm gián đoạn “lịch của maker” của từng cá nhân đóng góp
Nhiều tổ chức nhận ra điều này và tập trung vào chi phí chuyển đổi ngữ cảnh về mặt lịch trình, nhưng với lập trình viên, thời gian từ build đến deploy cũng quan trọng không kém, hoặc thậm chí còn quan trọng hơn