Saw this on Mastodon:

https://racingbunny.com/@mookie/114718466149264471

18 rules of Software Engineering

1. You will regret complexity when on-call
   
2. Stop falling in love with your own code
   
3. Everything is a trade-off. There’s no “best” 3. Every line of code you write is a liability 4. Document your decisions and designs
   
4. Everyone hates code they didn’t write
   
5. Don’t use unnecessary dependencies
   
6. Coding standards prevent arguments
   
7. Write meaningful commit messages
   
8. Don’t ever stop learning new things
   
9. Code reviews spread knowledge
   
10. Always build for maintainability
    
11. Ask for help when you’re stuck
    
12. Fix root causes, not symptoms
    
13. Software is never completed
    
14. Estimates are not promises
    
15. Ship early, iterate often
    
16. Keep. It. Simple.
    

Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.

(Of course, if we’re talking about a project you’re doing for a customer and the customer keeps asking for new stuff, then you’re never done, and you have to think ahead and expect changes. Is that what they mean? 🤔)

@movq@www.uninformativ.de Agree! Good list 👌

@movq@www.uninformativ.de Yeah, not too bad. I completely agree with you on completeness. Also, I hate complexity without having to learn that during on-calls. :-)