timlloyd | 5 years ago | on: Show HN: Muse – Tool for Thought on iPad
timlloyd's comments
timlloyd | 6 years ago | on: Evernote Blows Up the ‘Fail Fast’ Gospel
Check out an iOS app called Ikiru.
timlloyd | 7 years ago | on: Ask HN: How do you know what your users want?
timlloyd | 7 years ago | on: Product-building articles by PMs at major tech companies
What experiences have you had which lead you to think that?
timlloyd | 7 years ago | on: Product-building articles by PMs at major tech companies
Following John Cutler, Marty Cagan and Teresa Torres helps
timlloyd | 8 years ago | on: Ask HN: How does your team handle knowledge documentation?
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/
timlloyd | 8 years ago | on: Ask HN: How does your team handle knowledge documentation?
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.
page 1
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.