Di chuyển nhanh và từ bỏ
(engineersneedart.com)- Trong quá trình khôi phục một trò chơi Mac chưa hoàn thiện vào khoảng năm 1991, cách phát triển nhanh chóng hiện thực hóa ý tưởng rồi dứt khoát gác lại nếu thiếu độ vui hoặc khả năng hoàn thiện đã lặp đi lặp lại
- Danh sách khi đó có 27 tựa game, nhưng chỉ 5 tựa được phát hành thực tế; phần còn lại gần như là các prototype nhanh được làm trong khoảng 18 tháng
- Nhờ shell dùng chung cho game dựa trên sprite, chi phí cho các thử nghiệm mới giảm xuống; âm thanh, điểm cao và tính năng lưu được hoãn lại cho đến khi xác nhận được tiềm năng
- Các thử nghiệm như kite-fighting, K-10, Thief of Baghdad được quyết định có tiếp tục hay không dựa trên độ vui của điều khiển, mục tiêu của game, và khối lượng art lẫn triển khai mà một lập trình viên solo có thể gánh nổi
- Những dự án bị bỏ cũng không lãng phí; các đoạn mã như Fisher–Yates shuffle, chuyển độ sâu màu màn hình, phát hiện va chạm, bảng tra cứu lượng giác về sau được dùng lại trong các dự án khác
Khôi phục các dự án game Mac cũ
- Khi khôi phục các tệp game viết từ khoảng 35 năm trước từ một ổ cứng cũ, những thử nghiệm gần như chưa hoàn thiện lại trở thành đối tượng thú vị hơn các bản đã phát hành
- Các game shareware từng công bố trước đây đã được đóng gói thành disk image và đưa lên Soft Dorothy Software — Early Shareware Projects
- Các disk image này có thể dùng bằng cách kéo thả vào các trình giả lập Mac 68K hoặc PPC như Basilisk II, Sheepshaver, MiniVMac
- Mã nguồn và công cụ build liên quan đến Glider 4.0 do Casady & Greene phát hành năm 1991 nằm trong disk image Casady & Greene Projects
- Nếu hoàn thiện, AirBikes đã có thể trở thành một game đua xe tương lai, nhưng thực tế nó vẫn ở trạng thái dang dở
Chỉ 5 trong 27 tựa được phát hành
- Một tài liệu lập khoảng năm 1991 đã tổng hợp creator code, tên và trạng thái của từng game
- creator code gần giống một bundle identifier rất thô sơ của thời Macintosh trước OS X, và phải là duy nhất cho mỗi ứng dụng
- Danh sách có 27 tựa, trong đó chỉ 5 tựa được phát hành
- Phần còn lại chủ yếu là prototype nhanh
- Các dự án này được tạo ra trong khoảng 18 tháng
- Vào thời điểm lập danh sách, có vẻ đang làm đồng thời 3 tựa
- Một tiện ích tên UnMask cũng đã được công bố, nhưng vì đó là công cụ chỉ mất khoảng 10 phút để viết nên được xem là có thể loại khỏi đối tượng phân tích
Cách làm prototype nhanh
- Tác giả viết code mỗi ngày đến khuya và tạo ra nhiều thử nghiệm, đồng thời giảm chi phí làm prototype mới bằng shell dùng chung cho game dựa trên sprite
- Với bản phác thảo game mới, phần lớn thời gian thường dành cho việc tạo sprite và art bằng MacPaint; một số code là cần thiết cho cách nhập liệu riêng, cơ chế game và triển khai vật lý
- Các tính năng như âm thanh, điểm cao, lưu game không được làm ngay từ đầu, mà được hoãn lại để chỉ triển khai sau cho những game đáng được giữ lại
- Trọng tâm là nhanh chóng xác minh xem ý tưởng có thực sự vui không
- Một ý tưởng nghe vui trên giấy có thể khác với việc chơi thực tế có vui hay không
- Chỉ cần triển khai điều khiển và vật lý trong vài ngày cũng có thể biết có đáng tiếp tục hay không
Tiêu chí kiểm chứng nhanh độ vui
- Với game kite-fighting, có thể triển khai và thử nghiệm điều khiển bay cùng vật lý trong vài ngày
- Nếu bản thân việc điều khiển diều quá khó, khả năng sẽ có ít người thích chơi
- Nếu chỉ thả diều mà không có yếu tố chiến đấu cũng đã vui, thì game có tiềm năng
- Game arcade Joust có bản thân thao tác bay bằng nút flap đã vui ngay cả trước khi kẻ địch xuất hiện
- Cả lúc phải vỗ cánh chậm rãi lẫn lúc bấm nút liên tục để bay lên nhanh đều tạo ra cảm giác chơi
- Một game về máy bay giấy trong căn nhà bừa bộn, dùng miệng thông gió dưới sàn để lấy lực nâng, cũng đã có phần thú vị ngay cả trước khi người chơi nhận ra mục tiêu là đi qua các phòng và tránh những thứ như bánh mì nướng
- K-10 là một game đua xe khác, lấy tên từ Kansas highway 10, nhưng không vượt qua được giai đoạn prototype
Quyết định gác lại hay tiếp tục
- Một số game đã được triển khai phần ban đầu, nhưng không rõ sau đó cần làm gì tiếp
- Trong danh sách, vài game bị ghi lạnh lùng là
<no point>
- Trong danh sách, vài game bị ghi lạnh lùng là
- Game platform Thief of Baghdad có phần chạy nhảy trên thảm bay ma thuật khá vui, nhưng mục tiêu tiếp theo của game lại không rõ ràng
- Trong điều kiện phát triển một mình, ngay cả dự án có vẻ tiềm năng cũng khó tiếp tục nếu cần hơn một năm để hoàn thiện
- Một game adventure dựa trên sprite theo phong cách Dungeons and Dragons rất hấp dẫn, nhưng khối lượng công việc lớn: động tác theo từng loại vũ khí của người chơi, quái vật, hiệu ứng phép thuật, hệ thống chiến đấu
- Sau khi tạo động tác đâm và đỡ bằng kiếm, gánh nặng art lại tăng lên vì phải thêm các biến thể như chùy, cung, áo choàng
Lôi ra lại và tái sử dụng code
- Game bị hoãn không phải là dự án đã chết hẳn; nếu tìm được mã nguồn, tài nguyên và tệp dự án thì vẫn có thể lôi ra làm lại
- Thief of Baghdad được khởi động lại dưới dạng phiên bản màu khoảng 18 tháng sau, lấy tên Scheherazade, và bắt đầu có phần nào mục tiêu
- Nhưng ngay cả ở lần thử thứ hai, nó vẫn không tạo đủ sức hút khó diễn tả, nên lại bị dừng
- Code từ các dự án bị tạm gác có thể được tái sử dụng trong các công việc sau này
- Fisher–Yates shuffle algorithm
- Code thay đổi độ sâu màu của màn hình trên Mac đời đầu
- Code va chạm polygon-point
- Bảng tra cứu sine cho lượng giác nhanh
- Các routine dot-product và cross-product
- Những công việc prototype như vậy không bị xem là lãng phí
Phương pháp lặp lại tiếp tục ở Apple
- Khi thập niên 1990 tiếp diễn, kỷ nguyên indie Mac game developer dường như đang đi đến hồi kết; khi nhận được đề nghị đến California làm việc tại Apple, tác giả đã chấp nhận
- Sau khi vào Apple, tác giả hiểu rằng mình không thể làm các dự án ngoài Apple trong thời gian rảnh
- Nói chính xác, nếu muốn viết code ngoài công việc thì cần sự cho phép bằng văn bản của quản lý
- Vì Apple không kinh doanh game, có thể vẫn xin được phép, nhưng khả năng xin rồi bị từ chối là một gánh nặng tâm lý
- Cách làm prototype nhanh vẫn tiếp tục trong các dự án công việc không phải game
- Các đồng nghiệp khác lặp lại thiết kế trên whiteboard và lên kế hoạch cẩn thận trước khi viết code
- Bản thân tác giả thích nhảy vào làm trước, compile và lặp lại
- Cách nhanh chóng gom code để tìm sớm điểm nghẽn, rồi nếu cần thì gần như bắt đầu lại dự án từ đầu, được lặp đi lặp lại
- Ngay cả sau khi bắt đầu rồi làm lại một dự án khoảng ba lần, tác giả thường vẫn đạt trạng thái đủ tốt vào thời điểm tương tự lúc những đồng nghiệp thiết kế cẩn thận bắt đầu chạy được code
- Bản revision cuối cùng của code thường là đơn giản hóa; bằng cách ngay từ đầu đối xử với code như thứ có thể thay đổi lớn, tác giả có được cảm giác về cách nên tổ chức nó
- Cũng có trải nghiệm khi một đồng nghiệp đề xuất Bloom Filter, tác giả có thể trả lời rằng mình đã bỏ nó rồi vì dữ liệu thực tế quá nhỏ nên lợi ích hiệu năng không đáng kể, chỉ làm codebase phức tạp thêm
Always Be Iterating
- Đến lúc nghỉ hưu, tác giả cảm thấy mình từng là một nhân viên đóng góp và là đồng nghiệp tại Apple
- Khác với thời một mình code thâu đêm, các kỹ sư cùng làm việc là phần tuyệt vời nhất trong quãng thời gian ở Apple
- Trong số những người từng làm chung, có cả các lập trình viên giỏi hơn tác giả hơn một bậc thang
- Tác giả cảm thấy mình là một trong những lập trình viên nhanh nhất, gần như là người có thể làm ra hai phiên bản nếu cần prototype để demo trong cuộc họp tuần đó
- Câu tác giả lặp đi lặp lại với các con gái là A.B.I.
- “Always”
- “Be”
- “Iterating”
- Tức là “Always Be Iterating”
- Các dự án, mã nguồn và công cụ của những game chưa được phát hành đã được整理 thành disk image và công bố trên GitHub
- Volume 3 cũng đã được dự kiến, nhưng vì còn công việc整理 từng dự án về trạng thái có thể “release”, nên chưa hứa thời điểm công bố
1 bình luận
Ý kiến trên Hacker News
Kể từ khi bắt đầu lập trình vào khoảng năm 1989, tôi có ít nhất hơn chục, nhiều thì khoảng cả trăm dự án bị bỏ xó, phần lớn là game. Hầu hết được làm cho Mac Plus hoặc Mac LC, và nhiều cái có cơ chế hay phong cách nghệ thuật tương tự những thứ được nêu trong bài
Vài dự án hiếm hoi mà tôi đã phát hành hoặc tham gia cảm giác như cái bóng của con người tôi. CV và sự nghiệp cũng vậy. Chúng giống như dấu vân tay của một bản thể trọn vẹn từng sống cuộc đời trong mơ nhưng không thành hiện thực, vì không có cơ hội tích lũy thành công từ sớm. Vì thế tôi nghĩ thu nhập cơ bản có thể khuếch đại tiềm năng con người lên 10 hay 100 lần, giúp chúng ta chuyển từ nền kinh tế dịch vụ sang tính chủ thể và tự hiện thực hóa bản thân, đồng thời để mỗi người tạo ra thu nhập thụ động. Và tôi đã chơi Pararena rất nhiều
Môi trường quanh bạn có thể khác, hoặc ở nước bạn có thể không áp dụng cách tiếp cận đó. Tôi tò mò sự khác biệt giữa việc làm nhiều game và tập trung hoàn thành một game là gì. Nếu có thu nhập cơ bản, liệu có thể tiếp tục làm những việc này, không chỉ trong chốc lát mà lâu dài, đến mức cho ra được các dự án hoàn chỉnh không? Ở một số giai đoạn đời người như khi làm cha mẹ hay thời thơ ấu, thu nhập cơ bản có lý, nhưng trong giai đoạn đi tìm bản thân, tôi nghĩ trách nhiệm sẽ hữu ích
Tôi thật sự khó hiểu được lối suy nghĩ này. Thu nhập cơ bản kỳ diệu sẽ trở thành mức lương tối thiểu cho đám đông không làm việc; làm sao điều đó có thể bền vững hay tốt đẹp được
Về lý thuyết, cũng có lựa chọn hoàn thiện chúng cho đúng nghĩa, nhưng nếu cố làm vậy thì tổ chức đã phá sản, nên đó chỉ là lựa chọn trên lý thuyết. Nhìn vào tình trạng phần mềm mà tôi dùng trong công việc và cũng buộc phải dùng cho việc cá nhân, có vẻ mọi người quanh tôi đều đang sống cuộc đời như thế. May là người dùng không có lựa chọn, nên họ phải mua thứ tệ hại hoặc chẳng mua gì cả. Chúng tôi vẫn an toàn khi bán những thứ tệ hại
Nhiều công ty tôi từng làm vận hành theo kiểu này. Các kỹ sư tạo ra tính năng mới hào nhoáng, nó được phát hành, mọi người đều vui. Vài tháng sau thì lỗi chất đống
Những người tạo ra nó ban đầu đã chuyển sang đội khác. Danh nghĩa là “phá vỡ silo”, nhưng thực chất gần với “biến mọi người thành người có thể thay thế” hơn. Các kỹ sư tiếp quản dự án phải bảo trì và sửa lỗi cho đến khi một đội khác lại nhận bàn giao. Thật kinh khủng
Hơn nữa, “khả dụng tối thiểu” chỉ cách “không khả dụng” một bước. Mọi dự án đều trở thành Icarus, thử xem có thể bay gần mặt trời đến đâu trước khi đôi cánh tan chảy
[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
Những người tiếp quản không đủ năng lực để ra quyết định, tầm nhìn lớn của tôi bị gạt sang một bên, việc chứng kiến sự bất tài trong quản lý tính năng đó thật khó chịu đựng, và đến giờ mỗi khi xuất hiện lỗi ngu ngốc tôi vẫn bực. Nhất là khi tôi đã cảnh báo dù có đủ thời gian để điều chỉnh. Dù vậy tôi đã học được bài học quan trọng, và lần tới tôi có thể nói chắc rằng dù bị xem là người cứng đầu, tôi cũng sẽ không lùi bước mà sẽ đấu tranh
Nó rất hợp với nhà phát triển indie, và ở một mức độ nào đó cũng áp dụng được cho các công ty lớn. Triết lý này hữu ích để xác định tính năng hay sản phẩm đáng dành thời gian có ý nghĩa. Ngược lại, tình huống bạn mô tả cũng có thể được xem là hệ quả trực tiếp của việc không làm theo cách mà bài gốc đề xuất
Dạo này tôi đang quay lại làm phát triển retro. Tôi đang làm phần mềm cho Macintosh 68K, nền tảng mà lần đầu tôi học lập trình
Tôi đã lục tìm rất nhiều sách cũ, bài viết trên comp.sys.mac.programmer, và mã nguồn như Soft Dorothy và GliderPro. Nhìn lại mã cũ bằng con mắt mới là một trải nghiệm kỳ lạ. Tôi cũng thấy được vì sao máy Mac ngày xưa hay chết đến vậy, vượt ra ngoài lời giải thích đơn giản rằng “không có bảo vệ bộ nhớ”. Như tác giả đã nói, tôi cũng thích nghệ thuật 1-bit, nên đang quản lý một danh sách các tài khoản Twitter đăng nghệ thuật 1-bit. Nếu còn thiếu ai thì mong mọi người cho biết: https://twitter.com/i/lists/1578111923324944397
Điểm hay của việc lập trình cho các hệ thống bị giới hạn là nó giới hạn các lựa chọn của bạn. Đây là một khoảng nghỉ dễ chịu khỏi trải nghiệm hiện đại, nơi chỉ cần kéo đúng thư viện vào là có thể làm bất cứ thứ gì. Thỉnh thoảng tôi tưởng tượng một thế giới nơi năng lực tính toán bị đóng băng, và phần mềm cho một hệ thống đã được hiểu rõ chỉ ngày càng tốt hơn. Những hệ thống cũ như Mac 68K từng khiến người ta chóng mặt vì tốc độ tiến bộ phần cứng quá nhanh. Khi một bộ xử lý mới như 68020 hay 80386 xuất hiện, bạn cùng lắm chỉ có vài năm để làm ra thứ gì đó khai thác đúng tiềm năng của nó. Nếu quá muộn, bạn phải cạnh tranh với phần mềm mới dành cho thế hệ phần cứng mới
Tôi cũng muốn tạo các hàm wrapper để xử lý Handle và những thứ tương tự. Dù vậy, đúng như đã nói, thật đáng ngạc nhiên là Toolbox đơn giản đến mức nào so với các hệ điều hành hiện đại. Việc thử phát triển retro lại thực sự rất thú vị
Cả blog đều rất tuyệt. Có nhiều nội dung thú vị đáng xem
Bỏ đi một thứ gì đó cũng không sao; bạn vẫn có thể học từ những dự án đã bỏ và thậm chí tái sử dụng một phần của chúng. Khoảnh khắc đột phá với tôi là khi tôi quyết định làm nó nhỏ đến mức có thể hoàn thành. Điều đó giúp tôi rèn kỹ năng hoàn thành, và đây là một kỹ năng riêng, khó học. Vì nó chỉ xảy ra ở cuối một quá trình quá dài và vất vả, nên hầu như bạn không bao giờ đi được tới đó. Những người bạn làm video game của tôi đều bắt đầu bằng cách tự viết engine, rồi kiệt sức vào lúc làm trình chỉnh sửa màn chơi. Họ học được rất nhiều về việc tạo công cụ, nhưng trớ trêu thay lại khá giống những gì họ đã biết làm, còn game thì không làm ra được. Nó giống như học nghề xây đá trong lúc xây một nhà thờ lớn, nên sẽ không bao giờ thấy điểm kết thúc. Bạn phải bắt đầu nhỏ đến mức không thể thất bại, rồi dần tiến lên các dự án lớn hơn
Hiện tôi đang làm một dự án Unity, và đã khá chật vật khi suy nghĩ cách tốt nhất để xây dựng hệ thống đặt công trình kiểu RTS. Thay vì lao vào ngay như thường lệ, tôi quyết định sửa concept game để người chơi không cần đặt công trình nữa. Khi thử nghiệm, hóa ra đó lại là trải nghiệm người dùng tốt hơn cho thứ tôi định làm. Ban đầu tôi tự hợp lý hóa rằng “hãy thêm hệ thống công trình ở vòng lặp tiếp theo”, nhưng giờ có lẽ tôi sẽ không làm vậy
Cắt bớt gần như lúc nào cũng tốt hơn. Thực sự hoàn thành một điểm khởi đầu nhỏ giống như nitromethane cho vòng lặp tiếp theo. Bạn phải đạt 100% thì lượt tiếp theo mới tốt hơn hẳn. Nếu dừng ở 80%, chỉ còn lại cảm giác phải đẩy tảng đá trở lại lên đỉnh đồi
Sau khi làm về khả năng tiếp cận, tôi lôi nhiều thứ trong số đó ra và làm lại để chúng trở nên dễ tiếp cận. Một số dùng phiên bản Bootstrap rất cũ, nên tôi cũng nâng cấp lên Bootstrap mới nhất. Chỉ riêng việc sửa các thiết kế cũ để có khả năng tiếp cận tốt hơn đã giúp tôi học được rất nhiều. Tôi cảm thấy mình có góc nhìn tốt hơn nhiều về những gì cần xem khi đánh giá website và ứng dụng. Đó cũng là dịp khiến tôi nhận ra những thứ mình từng làm thiếu khả năng tiếp cận đến mức nào
Các game của John từng là nguồn cảm hứng cho tôi khi còn nhỏ và mới học lập trình trên Mac. Tôi chơi Glider rất nhiều, còn Pararena thì nhiều hơn nữa. Đến giờ mẫu âm thanh mở đầu vang vang đó vẫn còn in trong đầu tôi
Có lẽ tôi còn dành nhiều thời gian hơn để mò mẫm resource fork của các game đó bằng ResEdit. Tôi không hoàn thành được nhiều, nhưng cũng đã làm xong vài game shareware nhỏ và đăng lên AOL. Vài tháng sau, tôi thật sự bất ngờ khi một tấm séc từ California xa xôi xuất hiện trong hộp thư
Thời kỳ Mac đầu tiên thật sự là một khoảng thời gian đặc biệt, và có cảm giác rằng một nhà phát triển đơn độc, chỉ cần có óc sáng tạo và thời gian, cũng có thể làm ra thứ gì đó rồi đưa ra thế giới. Cảm ơn vì đã viết bài này và đưa tôi trở lại miền ký ức; mong ông đang tận hưởng thời gian nghỉ hưu
Liệu nó đặc biệt vì với chúng ta, những người dùng máy tính đời đầu và nhà phát triển đời đầu, mọi thứ đều mới mẻ? Hay khi ấy trong không khí có điều gì đó khác biệt? Tôi rất vui vì bạn thích những game nhỏ tôi làm. Tôi cũng tự hỏi liệu tấm séc đến từ California đó có phải là thứ đã đẩy bạn vào con đường sự nghiệp hiện tại, dù đó là gì đi nữa, hay không
Nếu mục tiêu của bài viết này là bình thường hóa việc bỏ dự án, tôi không chắc đó có phải là ý hay không. Bỏ qua mọi thứ khác thì nó có thể là một sự lãng phí thời gian khổng lồ, và chỉ nói “dù sao cũng học được gì đó” thì không đủ để biện minh. Chẳng phải ngay cả khi kết thúc cũng vẫn nên học được điều gì đó sao?
Vì chưa ai từng làm việc này nên họ vừa làm vừa tìm cách, và mắc khá nhiều lỗi trên đường đi. Một điểm được nhấn mạnh trong video là khi chuyện như vậy xảy ra, đội không đơn giản dừng lại rồi thử lại y như cũ. Họ tiếp tục để làm hỏng nó hoàn toàn, và biến nó thành cơ hội thoải mái thử nghiệm với vật liệu
Anh ấy nói khá dài về việc điều đó tuyệt vời đến mức nào. Nếu đang ở trên con đường tạo ra một sản phẩm hoàn thiện và được đánh bóng, họ sẽ không thể tự do thử những điều như vậy; nhờ thế họ tận dụng được một cơ hội vô song để học thêm về cách vật liệu mình đang xử lý hoạt động. Vì rất khó làm hỏng thêm một thứ vốn đã thành rác, nên cũng khó mà gọi đó là tiếp tục chấp nhận rủi ro
Tôi nghĩ nhận xét rằng tư duy coi trọng học hỏi và thử nghiệm hơn là chỉ coi trọng thành công là một trong những cách tốt nhất để trở nên thật sự xuất sắc trong việc mình làm là đúng
ChatGPT tóm tắt là “làm nhanh, và đừng bao giờ phát hành. Cho đến khi phát hành”
Đôi khi bạn bám lấy một dự án chẳng đi đến đâu, nghĩ rằng nếu cố đủ thì nó sẽ đi tới đâu đó, nhưng rốt cuộc vừa không vui vừa chẳng học được gì mới. Bạn tự thúc ép mình bằng suy nghĩ “phải hoàn thành, phải hoàn thành”, rồi khi hỏi “tại sao?” thì thường là vì nỗi sợ không hoàn thành được, hoặc có lẽ là sợ mình không phân biệt được đoạn khó khăn với một dự án đã thất bại. Dù là bên nào, tôi đã quá nhiều lần cảm thấy được giải thoát khi thất bại. Nó trở thành cơ hội để bắt đầu lại
Một số pixel art trong ảnh chụp màn hình thật sự rất đẹp
Cá nhân tôi đã học được và kiếm được nhiều hơn rất nhiều bằng cách phát hành những thứ nhỏ, rồi lặp lại hoặc vứt bỏ chúng
Tôi thích cách này và thấy nó thú vị, nhưng ở cấp độ tổ chức thì có vẻ khó hơn. Rất nhiều điều chúng ta khám phá về dự án và công nghệ liên quan đến tính khả thi ở quy mô mà dự án thực tế vận hành, và các thử nghiệm nhỏ không nhất thiết bộc lộ chúng
Đôi khi vấn đề cũng không phải là kỹ thuật, mà là kiểu “liệu có thể khiến phần lớn lập trình viên ở đây hiểu cách làm theo hướng này không”. Nói vậy không có nghĩa là không nên thử thêm những việc như thế. Có những điều có thể học được khi thử các dự án nhỏ. Chỉ là không có gì bảo đảm chúng cũng hoạt động ở quy mô lớn
Vấn đề của tôi đơn giản là thời gian. Đi làm về đến nhà thì điều tôi ít muốn làm nhất là ngồi trước máy tính
Hai ngày nghỉ mỗi tuần cũng phải dành cho việc nhà, nên tôi vẫn không muốn ngồi trước màn hình máy tính
Tôi ghen tị với những người có thể làm như bạn. Ngành này hiện giờ cảm giác như một giáo phái chỉ tìm những người biến công nghệ và lập trình thành toàn bộ cuộc đời. Không phải tôi ghét bản thân các yêu cầu, tôi cũng có đạo đức nghề nghiệp và muốn làm tốt, nhưng kỳ vọng có vẻ cao hơn bao giờ hết
Tôi hy vọng mình sẽ có đủ sự ổn định nghề nghiệp để có những sở thích không cần nhìn vào màn hình. Sắp tới tôi muốn thử gia công kim loại