Tôi không uống nhiều. Nhưng tối nay thì có. Và khi hơi ngà ngà, tôi có xu hướng trung thực theo kiểu mà sáng mai tỉnh dậy tôi có thể sẽ hối hận. Nhưng ông kia đã làm vậy trên Reddit và mọi người yêu thích nó — bài đó viral đến mức account bị xóa rồi mà vẫn còn người lưu lại đọc. Nên thôi, tôi cũng thử.
Đây là những thứ tôi thực sự học được — không phải những thứ tôi đọc trong sách, không phải những thứ tôi nói trong phỏng vấn. Những thứ tôi biết sau khi đã làm đủ thứ sai và nhìn đủ người khác làm sai tương tự.
Về tiền lương và sự nghiệp
Đổi công ty là con đường nhanh nhất để tăng lương. Mình biết điều này từ năm thứ hai đi làm, nhưng mất thêm hai năm để thật sự tin vào nó và hành động. Công ty cũ của mình tăng lương 8% mỗi năm nếu review tốt. Lần đầu đổi công ty, mình tăng 40% trong một ngày. Market rate tồn tại. Internal raise thì không bao giờ bắt kịp market rate, đặc biệt trong tech.
Tech stack không quan trọng như bạn nghĩ — nhưng cũng không phải không quan trọng. Có khoảng 15–20 patterns cốt lõi trong engineering. Database normalization, caching, event-driven architecture, idempotency, eventual consistency. Những thứ này tồn tại trong mọi ngôn ngữ, mọi framework. Khi bạn hiểu chúng, chuyển stack chỉ là vấn đề học syntax mới. Nhưng đồng thời — nếu bạn muốn làm ML mà bạn chỉ biết PHP, thì đó là vấn đề.
Code tốt là code mà junior đọc được. Code xuất sắc là code mà sinh viên năm nhất đọc được. Code tốt nhất là không có code. Tôi ghim câu này vào tường. Mỗi lần tôi thấy mình đang viết solution phức tạp cho một vấn đề, tôi hỏi: có cách nào không cần code này không? Câu trả lời thường là "có, nhưng mình chưa hiểu đủ vấn đề để tìm ra nó."
Kỹ năng underrated nhất của engineer là viết documentation. Tôi là người viết code decent, nhưng documentation của tôi tệ hơn nhiều so với code. Mỗi lần tôi nhìn lại code mình viết 6 tháng trước và không có doc, tôi nguyền rủa bản thân mình. Tôi đã từng nghĩ "code tốt là self-documenting." Đó là câu nói của người lười viết doc và cần lý do để biện hộ cho mình.
Nếu bạn đang nghĩ mình là người thông minh nhất trong phòng, đó là lúc nên ra đi. Không phải vì kiêu ngạo là xấu — mà vì nếu bạn thật sự là người giỏi nhất trong team, bạn đang bị mắc kẹt. Bạn không có ai để học từ. Và đó là môi trường nguy hiểm nhất cho sự phát triển dài hạn. Mình đã ở trong một team như vậy 8 tháng. 8 tháng đó mình gần như không học được gì mới.
Làm việc với engineer giỏi làm tôi code tốt hơn. Làm việc với non-technical co-worker giỏi làm tôi engineer tốt hơn.
Quản lý có ít quyền lực hơn bạn nghĩ. Mỗi lần tôi tự hỏi "tại sao manager không sa thải người đó?" — câu trả lời thường là vì họ không thể. HR process, PIP, documentation, headcount freeze. Manager không phải dictator. Hiểu điều này giúp tôi bớt frustrated với những thứ manager "không làm" — vì thực ra họ cũng đang bị ràng buộc bởi system.
Nếu bị gọi dậy lúc 2 giờ sáng vì on-call nhiều hơn một lần mỗi quý, có gì đó đang thật sự sai. Hoặc fix nó, hoặc quit. Tôi đã làm ở một chỗ mà on-call alert đến 3–4 lần mỗi tuần vào lúc kỳ lạ. Tôi mất 4 tháng để chấp nhận rằng đó không phải vấn đề tôi có thể fix một mình, và quit. Nên ra đi từ tháng thứ nhất.
Về title và bằng cấp
Title không quan trọng — nhưng title thay đổi theo hai hướng khác nhau tùy giai đoạn. Đầu career, title tăng là tốt: Junior → Mid → Senior → Lead. Nó cho phép bạn mở rộng scope và trách nhiệm. Cuối career, title xuống lại có thể là tốt — vì bạn có thể negotiate mức lương tương đương ở role thấp hơn, rồi được tăng khi promote. Đây là điều mình chưa bao giờ nghĩ đến cho đến khi đọc bài kia.
Bằng cấp không quan trọng theo cách mọi người hay nói, nhưng fundamentals thì có. Tôi đã làm việc với người không có bằng CS nhưng hiểu data structures sâu hơn tôi. Tôi cũng làm với người có bằng top school nhưng không biết tại sao query của họ slow. Bằng cấp không predict gì. Nhưng nếu bạn không biết Big O notation, không hiểu tại sao index quan trọng, không biết khi nào dùng recursion và khi nào không — thì có vấn đề, dù bằng hay không.
Làm việc gần product, gần revenue — dù công việc không technical — khiến bạn cảm thấy có giá trị hơn. Câu này đúng với mọi công ty mình từng làm. Infrastructure engineer giỏi nhưng không ai thấy output của họ. Product engineer mediocre nhưng ship feature và user dùng ngay. Perception của value không phải lúc nào cũng khớp với reality của value — và nếu bạn cần recognition để stay motivated, làm gần product giúp nhiều hơn bạn nghĩ.
SQL là ngôn ngữ underrated nhất trong tech. Tôi từng coi SQL là "không phải programming thật." Sai. SQL là ngôn ngữ khai báo mạnh nhất tôi từng dùng. Người biết SQL tốt trong môi trường data có thể làm được 80% những gì một data pipeline phức tạp làm — với ít code hơn, dễ maintain hơn, và người khác đọc được. Mình tốn hai năm học Python và Spark trước khi nhận ra rằng mình nên học SQL sâu hơn trước.
Về technology và teamwork
Intern và junior hay hơn nhiều người nghĩ. Không phải vì họ giỏi hơn — mà vì họ hỏi những câu mà senior không dám hỏi vì sợ nghe ngớ ngẩn. "Tại sao chúng ta làm theo cách này?" Câu đó đôi khi không có câu trả lời tốt, và việc không có ai hỏi nó là lý do nhiều quyết định tệ tồn tại lâu hơn cần thiết.
Tests quan trọng. TDD là cult. Tôi viết test. Tôi không viết test trước khi viết code trừ khi tôi đã hiểu hoàn toàn vấn đề — và nếu tôi hiểu hoàn toàn vấn đề trước khi bắt đầu, thì thường là vấn đề không đủ phức tạp để cần TDD. Với những vấn đề thật sự khó, tôi cần explore trước. Test đến sau, khi tôi biết mình đang làm gì.
Conferences và courses đáng tiền. Với một điều kiện: bạn phải có câu hỏi cụ thể trước khi đi. Conference không có câu hỏi chỉ là networking event đắt tiền. Course không có vấn đề cụ thể muốn giải quyết chỉ là video bạn sẽ xem 30% rồi bỏ. Lần cuối tôi mua course là vì tôi đang build một thứ cụ thể và cần hiểu một concept cụ thể. Xong trong một tuần. Áp dụng ngay hôm sau.
Ông ấy nói "tôi đang trở thành người tôi ghét: làm việc trong tech nhưng tránh tech trong cuộc sống thực." Và tôi không nghĩ đó là thứ cần phải hối hận. Bác sĩ không nhìn người bệnh trong bữa ăn tối. Luật sư không mang brief về nhà cuối tuần — hoặc không nên làm vậy. Tech là công việc. Cái thứ đẹp của tech là nó cho phép bạn tách biệt rất rõ ràng nếu bạn muốn. Bạn không cần code side projects để là engineer tốt. Bạn cần nghỉ ngơi để là con người tốt.
Về cuộc sống
Code không nên là legacy của bạn nếu bạn không muốn nó là vậy. Tôi đã từng tự hào về đoạn code đẹp mình viết. Rồi nó bị refactor. Rồi bị thay thế. Rồi project bị deprecated. Code sống theo vòng đời của công ty. Những thứ tôi nhớ nhất không phải code nào tôi đã viết — mà là ai tôi đã giúp, và ai đã giúp tôi. Những thứ đó không bị refactor.
Engineering là ngành khoảng 80 tuổi. Chúng ta vẫn đang tìm hiểu xem mình đang làm gì. Tôi thấy an ủi khi nghĩ điều này. Không phải vì nó cho phép sự cẩu thả — mà vì nó giải thích tại sao best practices thay đổi liên tục, tại sao "đúng" và "sai" trong engineering thường là "đúng với context này vào năm đó." Bạn không phải biết tất cả. Không ai biết tất cả. Kể cả những người viết sách về nó.
Ông kia kết thúc bài bằng câu chuyện về Conan O'Brien — người đã nói "be kind and work hard" trong show cuối cùng, và câu đó đã thay đổi cách ông sống. Tôi không có Conan O'Brien của riêng mình. Nhưng tôi có một senior engineer cũ tên Minh — người mỗi lần tôi mang vấn đề đến, ông không giải quyết hộ tôi. Ông hỏi "em đã thử cách nào rồi?" Rồi ông hỏi thêm "em đã hỏi ai chưa?" Rồi cuối cùng mới nói "ok, vậy thử cái này xem." Tôi mất hai năm để hiểu ông đang dạy tôi cách tự giải quyết vấn đề, không phải dạy tôi cách giải quyết vấn đề cụ thể đó. Đó là thứ quan trọng nhất tôi học được trong career — và không phải từ sách, không phải từ course, không phải từ blog post.
Từ một người ngồi cạnh và đủ kiên nhẫn để không làm hộ tôi.
Những thứ tôi nhớ nhất không phải code nào tôi đã viết — mà là ai tôi đã giúp, và ai đã giúp tôi. Những thứ đó không bị refactor.