Tại sao việc bỏ dở dự án phụ (Side-project) lại hoàn toàn ổn?

Ngành công nghệ web luôn ngập tràn những câu chuyện về các dự án phụ (side-project) phát triển thành những doanh nghiệp tỷ đô. Giống như nhiều lập trình viên khác, tôi thường dành thời gian sau giờ làm việc chính để mày mò các ý tưởng mới. Tuy nhiên, làm dự án phụ không phải lúc nào cũng là "cánh cửa thần kỳ" dẫn đến thành công và sự giàu có – đôi khi chúng đơn giản là không hiệu quả.

Nếu bạn đang đọc bài này, có khả năng bạn vừa bỏ dở một dự án hoặc đang cân nhắc việc làm vậy. Đừng lo lắng, chúng ta đều đã từng trải qua cảm giác đó. Thực tế, những dự án bị bỏ quên đã trở thành một chủ đề meme quen thuộc trong cộng đồng lập trình viên.

Tôi thường nhận được email từ các lập trình viên mới vào nghề xin lời khuyên, và một vấn đề ngày càng phổ biến là nỗi lo lắng về việc họ không hoàn thành (ship) các dự án phụ nhanh chóng hoặc nhiều như mong muốn. Sự lo âu này hoàn toàn dễ hiểu. Khi triết lý phổ biến của văn hóa "hustle" trong giới công nghệ là "luôn luôn tung ra sản phẩm", và các nhà tuyển dụng kỹ thuật thường đánh giá ứng viên dựa trên sản phẩm mã nguồn mở hay dự án cá nhân của họ, thì những dự án bị bỏ dở bỗng nhiên không còn buồn cười nữa.

Màn hình ứng dụng Lietvards

Tôi muốn chia sẻ về một dự án phụ tôi đã làm cách đây một thời gian – một dự án mà tôi đã bỏ dở ngay trong ngày nó được triển khai.

Bối cảnh

Bạn đời tôi là người Latvia và cách đây vài năm, tôi đã quyết định học ngôn ngữ của cô ấy. Vì đến từ một quốc gia nhỏ, tài nguyên học tiếng Latvia khá khan hiếm nhưng tôi vẫn đạt được tiến triển nhất định. Điều đó kéo dài cho đến khi tôi phát hiện ra tiếng Latvia có "cách ngữ pháp" (grammatical cases).

Nếu bạn chưa từng gặp khái niệm "cách" này, đây là một chút kiến thức cơ bản: Tiếng Anh sử dụng trật tự từ và các giới từ như "for", "to" hoặc "in" để thêm ý nghĩa cho từng từ trong câu. Nếu trật tự sai hoặc thiếu giới từ, câu có thể không còn hợp lý. Ví dụ, "Tom gives the book to Anna" nghe tự nhiên, nhưng "Tom the book to Anna gives" thì không.

Trong tiếng Latvia, thay vì dựa vào trật tự từ, phần cuối của mỗi từ sẽ thay đổi để cho thấy vai trò của nó trong câu. Đây là một hệ thống thú vị nhưng lại là cơn ác mộng với người học vì phải nhớ hàng loạt đuôi từ khác nhau. Tiếng Latvia có tổng cộng bảy cách, hai giống ngữ pháp và danh từ có thể là số ít hoặc số nhiều. Tóm lại, có khoảng 84 đuôi từ khác nhau cần phải ghi nhớ.

Là một người nói tiếng Anh bản xứ, đây là một thách thức lớn. Nhưng may mắn thay, tôi cũng là một lập trình viên và tôi luôn mặc định rằng mình có thể giải quyết mọi thứ bằng code. Điều gì sẽ xảy ra nếu tôi xây dựng một ứng dụng trắc nghiệm (quiz app) để giúp mình học các đuôi từ này? Nghe giống như một dự án phụ hoàn hảo!

Cách tiếp cận

Tôi muốn giữ cho ứng dụng của mình đơn giản. Mặc dù còn nhiều ngữ pháp khác để học, tôi chỉ tập trung vào sự biến đổi của danh từ để thu nhỏ khái niệm ban đầu thành một sản phẩm khả dụng tối thiểu (MVP). Cơ chế trắc nghiệm sẽ hiển thị một loạt danh từ tiếng Latvia và người dùng cần biến đổi danh từ đó thành đuôi từ phù hợp.

Mã nguồn ứng dụng

Về công nghệ, tôi chọn Svelte 3.0 cho giao diện người dùng vì nó là công nghệ mới lúc bấy giờ. Tôi muốn lưu trữ mọi thứ trên Netlify, nên cho phần backend tôi viết một vài hàm serverless để đưa ra câu hỏi và kiểm tra câu trả lời. Danh sách từ vựng có thể được phục vụ từ một tệp JSON tĩnh, và vì tôi là người dùng duy nhất, tôi có thể lưu kết quả và điểm cao vào bộ nhớ cục bộ (local storage) mà không cần cơ sở dữ liệu.

Để kiểm tra câu trả lời, tôi đã nghiên cứu các quy tắc biến đổi và quyết định xây dựng một hệ thống dựa nhiều vào Regex để tách gốc từ và thêm đuôi từ phù hợp.

Sau khi có một kế hoạch khá ổn, tôi bắt đầu viết code.

Sự nhận ra

Sau một tuần làm việc vào mỗi buổi tối, tôi hoàn thiện MVP. Tôi triển khai mọi thứ lên Netlify và bắt đầu thử nghiệm ban đầu.

Giao diện đơn giản nhưng hoạt động tốt trên thiết bị di động. Các câu hỏi trắc nghiệm diễn ra suôn sẻ và phiên làm việc kết thúc sau ba câu trả lời sai, đúng như thiết kế. Bảng điều khiển hiển thị chính xác thống kê về các từ đúng và sai, và điểm cao được lưu giữ giữa các phiên. Vui mừng vì mọi thứ hoạt động theo kế hoạch, tôi mở một lon bia và bắt đầu luyện tập các đuôi từ.

Rất nhanh chóng, tôi nhận ra ứng dụng của mình có một vấn đề lớn mà tôi không lường trước được: Bài kiểm tra quá dễ. Tệ hơn, nếu tôi không mắc 3 lỗi sai, bài kiểm tra sẽ kéo dài mãi mãi. Nó thực sự không thú vị để sử dụng.

Tôi suy nghĩ rất nhiều về cách làm cho bài kiểm tra thú vị hơn, nhưng rồi tôi chợt nhận ra: Vấn đề này thực sự không thể giải quyết bằng code. Hóa ra là trong quá trình thiết kế và viết code cho tất cả logic cần thiết để kiểm tra các đuôi từ, tôi đã thụ động học được các quy tắc cần thiết để hình thành chúng.

Trong suốt tuần qua, tôi đã làm việc những buổi tối dài để nghiên cứu và xây dựng một ứng dụng – với đối tượng mục tiêu chỉ là một người – và thực tế tôi không còn cần sử dụng nó nữa. Ối dồi ôi.

Có lẽ kho báu thực sự chính là những dòng code chúng ta viết trên đường đi.

Trong tất cả các dự án phụ bị bỏ dở của mình, đây là dự án khiến tôi thay đổi tư duy. Ngay cả khi tôi không bao giờ sử dụng "sản phẩm" cuối cùng, việc làm dự án đó vẫn gián tiếp đạt được những gì tôi đặt ra. Điều đó dẫn tôi đến một nhận thức quan trọng: chúng ta thường nói về các dự án phụ bị bỏ dở là "thất bại", nhưng thành công của chúng thực sự phụ thuộc vào góc nhìn.

Mặc dù một số nhà tuyển dụng công nghệ có thể khiến bạn tin rằng thành công của dự án phụ phải được định nghĩa bằng một sản phẩm hoàn hảo được tung ra thị trường, nhưng chúng ta làm việc trong một môi trường thực tế và bất kỳ kinh nghiệm xây dựng nào, dù tốt, xấu hay bị bỏ dở, vẫn là kinh nghiệm hợp lệ.

Nếu bạn có thể gỡ bỏ áp lực phải hoàn thành sản phẩm và thay vào đó tiếp cận chúng như những nguyên mẫu dùng một lần, các dự án phụ sẽ trở thành tờ giấy nháp tuyệt vời để thử nghiệm. Như tôi thấy khi xây dựng ứng dụng tiếng Latvia, chính hành động viết code cũng có thể là một công cụ thành công để giải quyết vấn đề.

Điều này không có nghĩa là chúng ta nên bỏ qua lý do tại sao các dự án này bị bỏ dở – sự tự vấn vẫn rất quan trọng – nhưng tôi thấy rằng tập trung vào tiến độ đạt được sẽ mang lại cảm giác mang tính xây dựng hơn trong dài hạn. Sau khi bỏ dự án tiếng Latvia, tôi quay lại với một số dự án phụ khác đang bị treo trên máy tính xách tay. Nơi trước đây tôi than phiền về một chuỗi thất bại và thời gian lãng phí, giờ đây tôi có thể tập trung lại vào những gì đã diễn ra tốt đẹp.

Trong một dự án, tôi có thể thấy nơi mình đã học cách tạo API bằng Go. Ở nơi khác, tôi ấn tượng với cách mình đã tìm ra cách làm việc với dữ liệu bản đồ GIS trong Postgres. Trong một thư mục bỏ hoang khác, tôi thấy không nhiều hơn là một hoạt ảnh bị hỏng – thứ mà sau này tôi đã xem xét và phát triển thành trang web này.

Tóm lại

Tôi vẫn thường xuyên làm các dự án phụ, nhưng quan điểm và động lực của tôi giờ đã khác. Lời khuyên của tôi dành cho một lập trình viên mới đang gặp khó khăn với các dự án phụ của họ là hãy luôn đảm bảo rằng bạn làm chúng vì chính mình và vì những lý do đúng đắn.

Thay vì tiếp cận dự án đầu tiên của bạn thuần túy như một phương tiện để làm giàu hoặc gây ấn tượng với nhà tuyển dụng, hãy coi nó trước hết là phương tiện để học hỏi và khám phá những gì có thể. Khi bạn đã tích lũy đủ kinh nghiệm (tức là bỏ dở một vài dự án), phần còn lại thường sẽ theo sau đó. Các dự án phụ nên mang tính sáng tạo và thú vị. Nếu bạn thấy rằng việc hoàn thành dự án bắt đầu gây ra căng thẳng hoặc tệ hơn là khiến bạn bị kiệt sức, thì đừng ngần ngại cắt đứt nó. Có khả năng là, nếu bạn nhìn đủ kỹ, nó đã mang lại cho bạn rất nhiều giá trị.