# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 6
# self = https://watcher.sour.is/conv/gg4pbpa
Saw this on Mastodon:
https://racingbunny.com/@mookie/114718466149264471
> 18 rules of Software Engineering
>
> 0. You will regret complexity when on-call
> 1. Stop falling in love with your own code
> 2. 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
> 5. Everyone hates code they didn’t write
> 6. Don't use unnecessary dependencies
> 7. Coding standards prevent arguments
> 8. Write meaningful commit messages
> 9. Don't ever stop learning new things
> 10. Code reviews spread knowledge
> 11. Always build for maintainability
> 12. Ask for help when you’re stuck
> 13. Fix root causes, not symptoms
> 14. Software is never completed
> 15. Estimates are not promises
> 16. Ship early, iterate often
> 17. 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.
Saw this on Mastodon:
https://racingbunny.com/@mookie/114718466149264471
> 18 rules of Software Engineering
>
> 0. You will regret complexity when on-call
> 1. Stop falling in love with your own code
> 2. 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
> 5. Everyone hates code they didn’t write
> 6. Don't use unnecessary dependencies
> 7. Coding standards prevent arguments
> 8. Write meaningful commit messages
> 9. Don't ever stop learning new things
> 10. Code reviews spread knowledge
> 11. Always build for maintainability
> 12. Ask for help when you’re stuck
> 13. Fix root causes, not symptoms
> 14. Software is never completed
> 15. Estimates are not promises
> 16. Ship early, iterate often
> 17. 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? 🤔)
(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 Yeah, not too bad. I completely agree with you on completeness. Also, I hate complexity without having to learn that during on-calls. :-)