ysw081's honest review, Practical Harness Engineering Completed in 2 Hours course
Reviews 16
Average rating 3.9
It feels more like an SSOT lecture rather than Harness Engineering... While it's not technically wrong if you view Harness in a narrow sense... Even calling it an SSOT lecture feels like it's lacking in various elements. It seems more suitable as a fragmentary case study presentation at a conference; it doesn't feel like a lecture intended to actually transfer knowledge to someone. To be honest, the screen is so small I can't even see it. Regarding the individual .md files provided as lecture materials: The core is ssot.md. While multi-level control is an advantage, it consumes costs inefficiently due to increased context (token) usage. Although it claims to maintain the existing structure through SSOT after the MVP, it causes excessive technical debt, making future refactoring difficult. Rather than showing the "forest" of Harness Engineering that connects SSOT + SDD + TDD, it delivers only a single branch of a single tree. It seems to have more disadvantages than advantages, such as creating excessive documentation or causing confusion by jumping back and forth, making it easy to make mistakes. Furthermore, it feels like a lecture calling itself Harness Engineering through extremely unfriendly, fragmentary examples without any explanation of ticket units like Sprinter, Epic, Story, or Task (though if one already knew these concepts, there would be no reason to take this lecture).
1
Thank you for your feedback. I am revising my previous response to be more specific. It is true that the issues with screen readability and the increased token consumption due to the nature of the document structure are actual trade-offs that were not sufficiently addressed in the lecture. While the explanations for SSOT design and ticket design are covered in Section 2, it seems they did not meet the depth you were expecting. Regarding the technical debt portion, it is slightly different. The flow of the lecture is designed to have Cursor analyze the structure of the MVP, modify the SSOT based on those results, and then proceed to ticket-based development. It is a structure where the existing framework is not simply layered on top, but rather refined after analysis before being applied. However, it is true that this flow was not sufficiently communicated in the lecture. Since the concepts of sprint/epic/ticket were set as prerequisite knowledge for this course, it may feel unfriendly if approached without that background. I should have made the target audience clearer in the course introduction. Thanks to your specific feedback, I believe I can make the content much clearer next time.
1