Pet project là dự án cá nhân của một lập trình viên, được tạo ra để học công nghệ mới, thử nghiệm kiến trúc và làm phong phú portfolio. Khác với phát triển thương mại, pet project không có thời hạn chặt chẽ, yêu cầu kinh doanh hay ràng buộc legacy, cho phép thử những giải pháp táo bạo. Theo Stack Overflow Blog (2025), 67% lập trình viên có pet project ghi nhận sự tăng tốc phát triển sự nghiệp. Pet project — cách tốt nhất để học một stack mới mà không có áp lực kinh doanh.
Những điểm chính
Pet project là một sản phẩm phần mềm mà lập trình viên tạo ra trong thời gian rảnh cho các mục đích cá nhân: học hỏi, thử nghiệm hoặc tự động hóa các tác vụ cá nhân. Khác với công việc, nơi công nghệ và kiến trúc thường bị chi phối bởi yêu cầu kinh doanh và mã legacy, pet project mang lại sự tự do hoàn toàn: bạn muốn thử Rust cho phát triển di động? Cứ làm. Bạn muốn viết trình biên dịch của riêng mình? Tiến lên.
Tại sao nên tạo một pet project? Lý do đầu tiên là học thông qua thực hành. Lý thuyết (sách, khóa học, tài liệu) cung cấp nền tảng, nhưng sự hiểu biết thực sự chỉ đến khi bạn tự đưa ra các quyết định về kiến trúc, tự sửa lỗi và tự triển khai lên môi trường sản xuất. Học thông qua làm là cách hiệu quả nhất để làm chủ một stack mới. Lý do thứ hai là portfolio: nhà tuyển dụng không chỉ thấy một dòng trong sơ yếu lý lịch nói "biết Flutter" mà còn thấy một dự án thực tế với kiến trúc, kiểm thử và CI/CD.
Lý do thứ ba là phát triển sự nghiệp. Một lập trình viên có pet project có thể show mã trong buổi phỏng vấn, nói về các quyết định kiến trúc và thể hiện sự hiểu biết về toàn bộ chu kỳ phát triển — từ ý tưởng đến triển khai. Theo Khảo sát Stack Overflow (2025), lập trình viên có pet project công khai nhận được trung bình nhiều hơn 15–20% lời mời cho các vị trí cao cấp. Pet project — không phải nghĩa vụ, mà là một khoản đầu tư cho sự nghiệp.
Sai lầm chính của người mời bắt đầu là bắt đầu với một ý tưởng quá lớn: "Tôi sẽ viết Instagram của riêng mình." Một pet project với phạm vi quá lớn chắc chắn sẽ bị bỏ dở sau 2–3 tuần, vì lập trình viên vấp phải sự phức tạp và mất động lực. Chiến lược đúng đắn: chọn một ý tưởng có thể biến thành nguyên mẫu hoạt động được trong 2–4 tuần, sau đó mở rộng dần. Tư duy MVP — phiên bản tối thiểu chỉ làm đúng một việc.
Những danh mục tốt nhất cho pet projects: clone một ứng dụng hiện có trên stack mới (trình theo dõi thói quen, quản lý mật khẩu, ứng dụng thời tiết, trình đọc RSS); xây dựng công cụ tự động hóa tác vụ cá nhân (trình phân tích sơ yếu lý lịch, trình tạo báo cáo, bot Telegram); tạo thư viện hoặc plugin cho cộng đồng mã nguồn mở (một wrapper API tiện lợi, một plugin Gradle tùy chỉnh, một plugin Figma). Dự án clone — khởi đầu tốt nhất: bạn biết nó nên hoạt động như thế nào và có thể tập trung vào việc học công nghệ thay vì thiết kế UX.
Tiêu chí chọn ý tưởng: bạn cá nhân thấy hứng thú (nếu không hứng thú, bạn sẽ bỏ trong một tuần); có thể đạt được MVP trong 2–4 tuần; cho phép sử dụng công nghệ bạn muốn học; giải quyết một vấn đề thực tế (của bạn hoặc người quen). Những ý tưởng không phù hợp: một danh sách việc cần làm khác (hàng triệu lựa chọn thay thế), sàn giao dịch tiền mã hóa (tuân thủ pháp lý), mạng xã hội (phạm vi quá lớn). Nguyên tắc Goldilocks: không quá đơn giản (nhàm chán), không quá phức tạp (bỏn bỏ), mà vừa đúng — thú vị và khả thi.
Việc chọn stack phụ thuộc vào mục tiêu của pet project. Nếu mục tiêu là học một công nghệ mới, stack rất rõ ràng: chính công nghệ đó. Nếu mục tiêu là tạo một công cụ hữu ích, hãy chọn một stack mà bạn đã thành thạo, để không mất thời gian học cú pháp. Sự dung hòa: 70% stack quen thuộc + 30% mới. Ví dụ, một lập trình viên Android có thể dùng Kotlin quen thuộc + kiến trúc mới (MVI thay vì MVVM) và thư viện hoạt hình mới (Compose Animation).
Các kết hợp phổ biến cho pet projects di động: Kotlin + Jetpack Compose (Android); Swift + SwiftUI (iOS); Flutter + Dart (da nền tảng); React Native + TypeScript (da nền tảng). Cho backend: Kotlin + Ktor (máy chủ nhẹ), Go + Chi (hiệu năng cao), Python + FastAPI (tạo nguyên mẫu nhanh). Pet project full-stack có thể bao gồm client di động + backend + cơ sở dữ liệu + CI/CD — mang lại sự hiểu biết về toàn bộ chu kỳ phát triển.
Một lời khuyên quan trọng: đừng cố gắng chọn stack hoàn hảo ngay từ đầu. Hãy chọn thứ bạn quan tâm ngay bây giờ. Nếu sau một tháng bạn nhận ra stack không phù hợp — hãy viết lại dự án trên một stack khác. Kinh nghiệm viết lại cũng rất quý giá. Trong một pet project, không có nợ kỹ thuật nào ngoại trừ thứ bạn tự tạo ra. Tự do lựa chọn — lợi thế chính của pet project so với phát triển thương mại.
80% pet projects bị bỏ dở trong 3 tháng đầu. Nguyên nhân không phải do thiếu thời gian mà là tổ chức kém. Kẻ thù chính: không có thời hạn (có thể trì hoãn mãi mãi), phạm vi quá lớn (mất động lực vì công việc bất tận), chủ nghĩa hoàn hảo (muốn làm hoàn hảo ngay lần đầu). Phản mẫu: "Tôi sẽ nghiên cứu hết tài liệu trước, sau đó mới bắt đầu viết mã" — sai. Hãy bắt đầu viết mã từ ngày đầu tiên, sử dụng tài liệu như một tài liệu tham khảo.
Lời khuyên thực tế để duy trì đà: đặt thời gian cố định cho dự án (ví dụ, mỗi thứ Ba và thứ Năm từ 20:00 đến 22:00), thực hiện các commit nhỏ với thông điệp rõ ràng (cho cảm giác tiến bộ), sử dụng GitHub Issues hoặc danh sách việc cần làm đơn giản để lập kế hoạch các bước tiếp theo, triển khai sớm (Firebase Hosting, Vercel, GitHub Pages) để thấy kết quả trực tiếp. Ship early, ship often — một nguyên tắc cũng hiệu quả cho pet projects.
Nếu bạn bỏ lỡ một tuần — đừng tự trách và đừng cố gắng bắt kịp vào cuối tuần. Chỉ cần quay lại lịch trình thường xuyên của bạn. Pet project không nên trở thành nguồn gốc căng thẳng. Nếu dự án không còn mang lại niềm vui — bạn có thể gạc nó sang một bên hoặc đóng nó lại. Sunsetting (kết thúc dự án một cách có ý thức) là thực hành bình thường. Điều quan trọng là rút ra bài học và có thể công bố mã như tài liệu tham khảo.
Chỉ viết mã và quên nó đi thì chưa đủ. Để pet project thúc đẩy sự nghiệp của bạn, nó cần phải có tính trình bày. Một README chất lượng là điều đầu tiên mà nhà tuyển dụng hoặc trưởng nhóm kỹ thuật sẽ thấy trên GitHub. README nên bao gồm: mô tả dự án (cái gì và tại sao), ảnh chụp màn hình hoặc bản demo GIF, hướng dẫn cài đặt, tổng quan kiến trúc (mẫu, thư viện, phương pháp) và liên kết đến bản demo trực tiếp (nếu có). Ấn tượng đầu tiên từ README — danh thiếp của lập trình viên.
Các yếu tố bổ sung làm tăng giá trị portfolio: đường ống CI/CD (huy hiệu GitHub Actions trong README cho thấy dự án được duy trì); kiểm thử đơn vị và kiểm thử giao diện (thể hiện sự hiểu biết về các thực hành kiểm thử tốt nhất); tài liệu kiến trúc (ADR, sơ đồ); issues và PRs với thảo luận (thể hiện khả năng làm việc nhóm ngay cả trong dự án cá nhân). Tín hiệu chất lượng cho nhà tuyển dụng: kiểm thử + CI + README + cấu trúc > số lượng sao hoặc commit.
Cách đề cập pet project trong sơ yếu lý lịch: một phần riêng "Dự án Cá nhân" với 2–4 dự án. Cho mỗi dự án: tên, liên kết GitHub, stack công nghệ, 2–3 câu về vấn đề và giải pháp. Nếu dự án có người dùng tích cực (bạn bè, gia đình) hoặc được xuất bản trên cửa hàng — hãy đề cập số lượng cài đặt/tải xuống. Các chỉ số: "Pet project trên Flutter, 50+ lượt cài đặt trên Google Play, CI/CD qua GitHub Actions, 85% độ phủ kiểm thử" nói nhiều hơn "biết Flutter".
<!-- Example Personal Projects section in resume -->
## Personal Projects
### BudgetTracker — [GitHub](https://github.com/username/budget)
Stack: Kotlin, Jetpack Compose, Room, Ktor Client
Personal budgeting app with offline-first architecture.
- MVVM + Clean Architecture, 80% test coverage
- Published on Google Play, 200+ installs
- CI/CD via GitHub Actions + Fastlane
### WeatherBot — [GitHub](https://github.com/username/weatherbot)
Stack: Python, FastAPI, Telegram Bot API, Redis
Weather notification bot with location-based forecasts.
- Async processing via Celery + Redis
- Deployed on Railway with 99.9% uptime
Quan trọng: đừng biến phần dự án cá nhân thành bãi rác của 20 kho lưu trữ bị bỏ rơi. Hãy chọn 2–3 dự án tốt nhất, nơi mã sạch sẽ, README đầy đủ và kiểm thử đạt yêu cầu. Portfolio được tuyển chọn có giá trị hơn số lượng.
Không phải mọi pet project đều cần là mã nguồn mở. Nếu dự án giải quyết một vấn đề cá nhân và khó có thể hữu ích cho người khác — một kho lưu trữ riêng tư hoàn toàn ổn. Nhưng nếu dự án triển khai chức năng mà các lập trình viên khác đang tìm kiếm (thư viện, plugin, công cụ), thì đáng để công bố công khai. Mã nguồn mở giúp tăng khả năng hiển thị, nhận phản hồi từ cộng đồng và xây dựng uy tín trong cộng đồng lập trình viên.
Các yếu tố chính của một pet project mã nguồn mở: giấy phép (MIT, Apache 2.0 — phổ biến nhất); CONTRIBUTING.md (cách đóng góp); mẫu issue (báo cáo lỗi, yêu cầu tính năng); quy tắc ứng xử; quản lý phiên bản ngữ nghĩa với thẻ phát hành. Thiếu những yếu tố này, dự án trông giống một thử nghiệm cá nhân chưa hoàn thành, không phải một dự án mã nguồn mở. Rào cản gia nhập: một dự án mã nguồn mở tốt dành nhiều thời gian hơn cho việc bảo trì (đánh giá PR, trả lời issue) hơn là viết mã.
Câu chuyện thành công của các pet project mã nguồn mở: Retrofit (Square), Picasso, Coil — tất cả đều bắt đầu như pet projects của các lập trình viên giải quyết vấn đề của riêng họ. Picasso (tải hình ảnh cho Android) được Jake Wharton viết trong một ngày cuối tuần như một giải pháp cho một vấn đề, và hiện được hàng triệu ứng dụng sử dụng. Từ pet đến sản phẩm — hành trình từ một dự án cá nhân đến tiêu chuẩn ngành là có thể, nhưng không nên là mục tiêu cuối cùng.
Câu hỏi thường gặp
Có, nếu dự án không còn mang lại niềm vui và trở thành nguồn căng thẳng. Pet project là sở thích, không phải công việc. Sunsetting (kết thúc có ý thức) với việc công bố mã và bài học là thực hành bình thường và hữu ích.
Một ứng dụng giải quyết vấn đề thực tế, với kiến trúc rõ ràng, kiểm thử và CI/CD. Ví dụ, trình theo dõi chi tiêu, ứng dụng thời tiết có chế độ ngoại tuyến hoặc trình đọc RSS. Portfolio junior nên thể hiện sự hiểu biết về toàn bộ chu kỳ: từ kiến trúc đến triển khai.
Có, nếu mục tiêu là có kinh nghiệm xuất bản (metadata, ảnh chụp màn hình, quy trình xem xét). Không, nếu dự án có tính thử nghiệm và chưa sẵn sàng cho người dùng. Xuất bản trên cửa hàng là một điểm cộng cho portfolio, nhưng không bắt buộc.
Thay thế 2–3 giờ lướt mạng xã hội/YouTube bằng thời gian cho dự án. Tính đều đặn rất quan trọng (2–3 lần mỗi tuần, 1–2 giờ), không phải số giờ một lần. Nhất quán hơn cường độ — bí quyết của các pet project hoàn thành.
Trong giờ làm việc — không (vi phạm hợp đồng lao động). Trên máy tính xách tay công việc — tùy thuộc vào chính sách công ty. Tốt nhất nên sử dụng máy tính cá nhân và thời gian cá nhân. Đạo đức side project: không sử dụng tài nguyên công việc (đám mây, giấy phép, khóa API) cho pet project.
Tổng kết
Chúng tôi sẽ phát triển ứng dụng di động chìa khóa trao tay
IT Sectr tạo các ứng dụng iOS và Android cho các công ty khởi nghiệp và doanh nghiệp từ năm 2017. Chúng tôi sẽ tư vấn và đề xuất giải pháp tốt nhất cho bạn.
Đọc thêm