Over the time of learning and practicing various programming techniques, on personal and organizational projects, I have developed a discipline on the way I code - I should code for my users.
If I want to make some programmable interfaces or a service in hope to help fellow programmers with their development tasks, I should think of myself as them who can:
- Get straight to the point introduction with just the right amount of information to get started, and clear indication of this project’s limits and strengths.
- Find the APIs (application program interface) easy to use, hopefully takes no more than a few lines of code to accomplish certain tasks.
- Find concise documentation with clear, self-contained code examples when in doubt.
- Read well structured source code and its in-line comments to get further insights.
- Easily raise issues, and provide constructive suggestions or enhancements in form of code changes to participate in this project’s development.
I should ease their life or work, not to burden them with more.
If I want to make an application that allows users to directly interact with, then I must aim for solving certain problems of its potential users who would benefit from using it to save time and resources. This allows me to focus on the high level objectives. Then I must act as its end users who should find the interface to be pleasant and intuitive to use. The latter allows me to perfect on details.
These points could change over time, but I should always code for my users.