Recently, when Eliezer wanted to explain why he thought a certain person was among the best rationalists he knew, he picked out one feature of their behavior in particular:
I see you start to answer a question, and then you stop, and I see you get curious.
For me, the ability to reliably get curious is the basic front-kick of epistemic rationality. The best rationalists I know are not necessarily those who know the finer points of cognitive psychology, Bayesian statistics, and Solomonoff Induction. The best rationalists I know are those who can reliably get curious.
Being curious is important in software development.
In a project that I am involved in, we are evaluating technologies to use. We have different approaches to tackle this problem. This leads to heated discussions, which is good because it shows that people care about the product. However, too much arguing can be a demotivator and have a negative impact on productivity.
Here is the heuristic I use to design and build a system:
- Find subsystems. Maybe you decide on a client/server architecture. The server needs to communicate with clients and be able to save data. Iterate. Focus on the server and find its components, then look at the client.
- Find constraints. You may need clients for two or three platforms, maybe they need to work with a slow or missing connection. Fast feedback is important, and the only viable communication protocol is HTTP. You can get websockets to work on the clients, and it would be a perfect fit. So the server should support websockets.
- Find third-party libraries and frameworks that solve your problems. Evaluate them. What are their benefits and drawbacks? Have they been put to the test? Is the community strong? Is the project being maintained? Would it be better to make an in-house solution for this or that part, and how long would it take?
- Build prototypes. Test them. Find out if a solution built on these technologies would break or hold in the real world. Focus on the experience of your first users but keep scaling in (the back of your) mind. Think of possible maintenance issues.
- Build. Ship. Refine.
