Hacker News new | ask | show | jobs
by lethologica 2094 days ago
There was a comment posted on HN a while ago that has always stuck with me[0] that basically said that plain old pen, paper, and a system of rules was more than enough to start a business, organisation, or, as a follow up comment said, even Rome.

This has rung true in my life many times over. I've tried complicated note and habit tracking apps that just do far more than I ever need and I tend to get stuck in the weeds, missing the forest for the trees with these types of platforms. The default reminders app and notes app on my iPhone so far, has been more than sufficient for everything I've needed to tackle in life from moving overseas, starting a business, and fostering relationships as well as building every habit I currently have.

Basically, this is just a long winded way of saying "keep it simple"

[0] https://news.ycombinator.com/item?id=21222150

2 comments

> This has rung true in my life many times over. I've tried complicated note and habit tracking apps that just do far more than I ever need and I tend to get stuck in the weeds, missing the forest for the trees with these types of platforms.

Exactly. Use something simple that works for you. Design a system yourself if you can. Here is a system that works for me, either on paper and with a simple text editor in Markdown. https://github.com/YJPL/personal-kanban

>[0] https://news.ycombinator.com/item?id=21222150: "if you can't do it on paper first, you're not ready to computerize the problem."

So true.

> if you can't do it on paper first, you're not ready to computerize the problem

One of the first things I do when on-boarding engineers to our business is to walk through the entire flow on paper, in terms of assets, people, and handshakes (as if there were no computers involved).

The industry my company's in is old enough that our competitors actually used to process everything with pen, paper, and stamps. technology made everything faster, but the water flows through the same pipes, so to speak.

Our programs are an incomplete and evolving map of a real-world transaction-territory, and it sometimes takes people a while to grok that. Once engineers do, they gain the ability to predict behavior in un-mapped territory. Having this ability saves everyone an immeasurable quantity of time.

I guess the most important takeaway, is that one must have distinct mental maps of the business process and of the program implementing the business process.

This obviously varies a lot depending on the technology you're building. Although, I guess even something as abstract as `malloc` can be analyzed in this way (a map for the program, and a map for the idea of the program: allocating memory).

Until you misplace the paper notebook..