4 ms·
Some really simple technical principles: Explicit is better than implicit. All state is hard to reason about and debug. Code that doesn't have tests is brittle
by moomin 9y ago
Some really simple technical principles:
Explicit is better than implicit. All state is hard to reason about and debug. Code that doesn't have tests is brittle. Short code is better than long code and no code is better than both. Inheritance of implementation is hard to reason about.
Some technical advice:
Write comments about why you're doing something, not how. Write lots of comments. Check preconditions, especially nulls. Write explicit error messages for every failure: you'll be searching for them one day.
One non-technical thing:
Understanding the problem you're trying to solve is often better than any technical knowledge. Understand the business processes, the users and the people and you'll find you're vastly more effective.
- continuational 9y agoI would give almost the opposite advice: Whenever you feel like writing a comment explaining why you're doing something, step back and consider if you can refactor the code so that it becomes self documenting. Code and comments get out of sync easily. Instead of checking for preconditions, step back and consider if you can make the illegal states unrepresentable. If you have a decent type system available (sum types, no nulls), that's often straightforward. The best peice of code, the best test and the best comment is the one you didn't have to write because of good design.