My guiding principles after 20 years of programming (2020)
Few problems with this:<p>&gt; Don’t attach your identity to your code<p>Others in your team will. Example here is a craftsman taking pride in their work. Think about that the next time you are reviewing someone elses work.<p>&gt; Security &gt; Reliability &gt; Usability (Accessibility &amp; UX) &gt; Maintainability &gt; Simplicity (Developer experience&#x2F;DX) &gt; Brevity (code length) &gt; Finance &gt; Performance<p>Performance is last ? Code length is more important than performance? That&#x27;s wrong. Also correctness is not mentioned at all surely that has to be in that list.<p>&gt; Don’t use dependencies unless the cost of importing, maintaining, dealing with their edge cases&#x2F;bugs and refactoring when they don’t satisfy the needs is significantly less than the code that you own.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Not_invented_here" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Not_invented_here</a><p>It&#x27;s impossible to determine the cost of using a lib using these metrics. I bet this person has had a problem with a dep a few years ago that caused a lot of emotional damage and the response is to never use 3rd party deps where possible. That&#x27;s not a professional response to what happened it that&#x27;s the case I&#x27;d hope most Staff Engineers don&#x27;t have this attitude.<p>&gt; Good code doesn’t need documentation<p>This is impractical at the end of the day you&#x27;ll need to have something for the user to lookup for reference.<p>&gt; Never start coding (making a solution) unless you fully understand the problem<p>Most devs don&#x27;t get to decide this they will be told to do X by someone in a large org and given a brief description of why. Refusing to do your work until you fully understand a problem will lead to dismissal.<p>Some good stuff in there but also some problems.