| > [...] write good code. > When people say this, I don't know what they mean. Code does something for the business (or for the customer). Good code both does what the business needs, but is also possible to quickly and easily modify and extend as the needs of the business change. These two characteristics, that the code should fulfill the needs of the business and also be able to grow, imply a number of other characteristics of good code. It should be easy to read so you can scale the developer force up and down easily. It should be testable, to facilitate rapid changes and health within the code base. On the operations front, good code should have operational metrics and monitoring, so you can see that it's working well without digging too hard, and can see what areas need attention if any. It should operate in a reasonably trouble-free way, so you're focusing your time on what's next instead of problems caused in the past. Sometimes I hear of teams where the developers want to leave because they're continuously solving operational problems instead of doing feature development-- those teams should be working on rewriting/reworking their systems in a way that they operate trouble free, which is new development. The goodness of code is determined by how well it serves its purposes-- both in the past as well as into the future. Some of these these ideas and much more are well-covered in books such as "Clean Architecture" by Robert Martin. |