Tháng đầu tiên tại một startup sẽ để lại dấu ấn sâu sắc. Không có giai đoạn làm quen chậm chạp, cũng không có tuần lễ ngồi xem các video định hướng trong khi chờ bộ phận IT cấp phát laptop. Ngay từ ngày đầu tiên, bạn được kỳ vọng sẽ xây dựng, làm hỏng và sửa chữa những thứ mà người dùng thực tế sẽ thực sự sử dụng. Tôi đã học được điều này rất nhanh sau khi gia nhập Treevah, một công ty đang xây dựng các công cụ giúp người tìm việc sắp xếp hồ sơ ứng tuyển của họ. Ba mươi ngày trong một môi trường giai đoạn đầu đã dạy tôi về phát triển phần mềm nhiều hơn bất kỳ lớp học hay cuộc thi nào từng làm được.
Nhịp độ dồn dập không ngừng nghỉ
Tại Treevah, công việc không chờ đợi bạn ổn định chỗ ngồi. Đội ngũ đang nỗ lực đưa sản phẩm từ bản alpha sang beta và cuối cùng là đưa vào production, điều đó có nghĩa là mọi nhiệm vụ đều mang sức nặng đáng kể. Không có chỗ cho những công việc mang tính tạm bợ hay những bài tập chỉ để lưu lại trong hộp thư đến của giáo sư. Khi bạn ra mắt một tính năng, nó sẽ đến thẳng tay những người dùng đang cố gắng theo dõi thời hạn, các buổi phỏng vấn và các bước theo dõi trong khi tìm kiếm công việc tiếp theo.
Tốc độ làm việc thật kiệt sức. Bạn phải di chuyển nhanh chóng mỗi ngày, và khối lượng công việc chất đống nhanh hơn bạn tưởng. Các hạn chót không phải là thứ gì đó trừu tượng; chúng gắn liền với các cột mốc quyết định liệu công ty có thể phục vụ thêm nhiều người tìm việc hay không, hoặc có thể khắc phục các lỗ hổng trong trải nghiệm hiện tại hay không. Sức nặng đó bào mòn bạn. Nhưng nó cũng tạo ra một sự rõ ràng mà khó có thể tìm thấy ở các tổ chức lớn hơn. Khi hoàn thành một nhiệm vụ, tôi có thể vạch ra một đường thẳng nối liền giữa những gì mình đã xây dựng và một người hiện đang có trải nghiệm dễ dàng hơn trong việc quản lý quá trình tìm việc. Cảm giác làm chủ đó thật hiếm có, và nó khiến sự mệt mỏi trở nên xứng đáng.
Kỹ năng tích lũy nhanh hơn trong môi trường production
Trước mùa hè này, phần lớn năng lượng của tôi dành cho việc thuyết trình trước công chúng và các cuộc thi hackathon. Cả hai đều dạy tôi cách ứng biến nhanh và trình bày ý tưởng dưới áp lực. Đặc biệt, hackathon rèn luyện cho bạn khả năng chắp vá các bản demo hoạt động được chỉ trong vài giờ. Nhưng có một sự khác biệt giữa một dự án cuối tuần gây ấn tượng với ban giám khảo và mã nguồn production phải tồn tại khi tiếp xúc với hàng trăm người dùng thực tế.
Dành một tháng tập trung vào phát triển web tại Treevah đã giúp tôi lấp đầy khoảng cách đó. Ở trường, các dự án luôn có các rào chắn an toàn. Phạm vi được cố định, các yêu cầu được cung cấp tận tay, và nếu lược đồ cơ sở dữ liệu (database schema) của bạn gặp lỗi, bạn có thể giải thích điều đó qua một slide thuyết trình. Bên trong một startup, schema của bạn phải đứng vững vì những người tìm việc thực sự đang lưu trữ dữ liệu ứng tuyển thực tế trong đó. Vòng lặp phản hồi diễn ra ngay lập tức và không khoan nhượng. Khi một trang tải chậm hoặc một biểu mẫu không lưu được, chẳng ai quan tâm đến điểm số của bạn; họ chỉ quan tâm đến việc liệu họ vừa bỏ lỡ một cơ hội hay không.
Áp lực đó thúc đẩy sự trưởng thành. Bạn học cách viết mã sạch hơn không phải vì một tiêu chí đánh giá yêu cầu, mà vì chính bạn sẽ là người phải gỡ lỗi (debug) nó vào lúc nửa đêm. Bạn học cách đặt những câu hỏi sắc bén hơn trong quá trình kiểm duyệt mã (code review) vì việc triển khai một bản build lỗi đồng nghĩa với việc người dùng thực tế sẽ gặp bế tắc. Những cơ hội ở đây đơn giản là tác động mạnh mẽ hơn các dự án ở trường. Sai lầm gây ra tổn thất lớn hơn, và vì thế các bài học sẽ khắc sâu hơn.
Thực tế đầy khiêm nhường về những lỗi phần mềm
Nếu có một quan niệm sai lầm mà tôi muốn đập tan, thì đó là ý tưởng cho rằng mọi lỗi phần mềm đều là một thất bại logic đầy kịch tính. Tất nhiên là có những lỗi như vậy. Nhưng nhiều lỗi tôi gặp phải tại Treevah lại nhỏ đến mức phát điên. Chúng ẩn nấp ngay trước mắt và làm lãng phí hàng giờ cuộc đời tôi.
Có hai kiểu lỗi liên tục xuất hiện. Kiểu thứ nhất là các quy tắc CSS trùng lặp. Khi nhiều lập trình viên cùng chạm vào một component qua nhiều sprint, các stylesheet sẽ trở nên cồng kềnh. Một người thêm một lớp tiện ích margin trong khi người khác lại gán cứng một giá trị trong file component. Xét riêng lẻ thì không ai sai cả. Nhưng khi kết hợp lại, chúng tạo ra sự thay đổi bố cục (layout shifts) hoặc các cuộc chiến về độ ưu tiên (specificity wars) khiến một nút bấm trông có vẻ ổn trên Chrome nhưng lại bị lỗi trên Safari. Việc truy tìm nguyên nhân đó đồng nghĩa với việc phải mở công cụ dành cho nhà phát triển của trình duyệt và dò tìm từng dòng kiểu đã tính toán (computed styles) thay vì đọc những logic thuật toán thanh thoát.
Kiểu thứ hai là việc định nghĩa các phần tử nằm ngoài các thẻ div cha của chúng. Một trình kích hoạt modal hoặc một menu thả xuống (dropdown) có thể bị chèn vào sai nút trong DOM. Màn hình trông có vẻ gần như đúng, vì vậy bạn cho rằng cấu trúc đã ổn. Thế rồi một xung đột z-index xuất hiện, hoặc một sự kiện click bị nổi bọt (bubble) đến sai trình xử lý, và đột nhiên người dùng không thể đóng một cửa sổ popup đang che mất biểu mẫu ứng tuyển của họ. Đây không phải là những câu đố về khoa học máy tính. Chúng là những sai sót về không gian và cấu trúc, vốn sẽ tích tụ dần khi bạn đang làm việc với tốc độ cao.
Một vài lỗi trong số này phải mất hàng tuần mới tìm ra được. Tôi thường nhìn chằm chằm vào mã nguồn, tự thuyết phục mình rằng logic đó hoàn toàn hợp lý, rồi cứ thế đi vào những ngõ cụt không lối thoát. Sự ức chế là có thật. Bạn cảm thấy như mình đang bỏ lỡ một điều gì đó rất hiển nhiên, và thực tế đúng là như vậy. Nhưng cảm giác thỏa mãn khi cuối cùng cũng phát hiện ra một quy tắc bị trùng lặp hay một thẻ đóng đặt sai chỗ lại vô cùng...