Hacker Newsnew | past | comments | ask | show | jobs | submit | timlloyd's commentslogin

I’m with you. The comparison with Netflix is pertinent for me. When lockdown started here in the U.K. I cancelled my subscription and started spending more time reading and exploring.

Didn’t think twice about paying for Muse when the time came. There was an available slot in my subscription budget :p It helps me think things through, which helps me do better work, which makes me happy. And it feels good to support principled people who care about how tools, environments, aesthetics, affect our thoughts. No regrets.

iPads/many things aren’t worth the price for some people. We don’t all have the same priorities, and that’s OK!

Maybe the price doesn’t bother me much in the long term because for me, Muse isn’t where things end. It’s where they start, take shape, get fleshed out, discarded, iterated, improved. It’s my desk not my library. If a better “desk” comes along I’ll use that instead. But right now, Muse is it.


Check out an iOS app called Ikiru.



What experiences have you had which lead you to think that?


Following John Cutler, Marty Cagan and Teresa Torres helps


Maybe the problem can be reframed?

> the problem is more for processes. Things like "How do I create a build from my commit?"

With well set up CI and automated builds, would you need this documentation at all? Could other processes which you currently document also be automated?

In my (limited) experience there's no great way to handle documentation, apart from reducing the need for it as much as possible.

The team I'm on (as a PM, I'm not a programmer) used to use Confluence for almost all technical documentation, apart from the odd Readme file. We use it for product, product range and other team documentation too, which makes choosing sensible top level hierarchy difficult! I don't recommend trying this.

But we finally have decent automated builds in place, and it's made a world of difference. We will soon have decent CI set up too (with Gitlab), at which point lots of project specific technical documentation will move to Gitlab wikis, living alongside the repo it relates to.


> With well set up CI and automated builds, would you need this documentation at all?

We have that. But how would you know that we have that without documentation telling you? How would you know where to find the resulting builds or to check the status?


Fair enough. We currently document such systems details in Confluence, which I can't recommend for all the reasons given by others here.

> We could have the documentation in a separate repository, but if we are going to be making this leap, we want to be sure we are using the right tools for the jobs.

If you haven't considered this yet, it would be very easy to set up a Mkdocs[1] site for testing, using all of your existing documentation. Should be as simple as making a new site and dragging your current docs folder contents into the docs dir. It has good search built in with Lunr[2]. Try the Material theme[3] if looks are important.

[1] http://www.mkdocs.org [2] https://lunrjs.com [3] https://squidfunk.github.io/mkdocs-material/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: