[HN Gopher] The Rules of Programming (2023)
___________________________________________________________________
The Rules of Programming (2023)
Author : davikr
Score : 26 points
Date : 2024-12-08 20:13 UTC (2 hours ago)
(HTM) web link (www.therulesofprogramming.com)
(TXT) w3m dump (www.therulesofprogramming.com)
| joaquincabezas wrote:
| The first rule of programming is you do not talk about
| programming
| 00kevn wrote:
| That's Fight Club
| Vordimous wrote:
| Or book club
| avg_dev wrote:
| The list of rules covered can be found in the book description on
| the purchase links, like: https://bookshop.org/p/books/the-rules-
| of-programming-how-to...
| lukan wrote:
| "The rules in this book include: As simple as
| possible, but no simpler Let your code tell its
| own story Localize complexity
| Generalization takes three examples Work backward
| from your result, not forward from your code The
| first lesson of optimization is don't optimize A
| good name is the best documentation Bugs are
| contagious Eliminate failure cases
| Code that isn't running doesn't work Sometimes you
| just need to hammer the nails
|
| "
|
| Sounds quite solid - as guidelines. My only rule for
| programming is, that the result is correct and usable.
| XorNot wrote:
| My arbitrary rule from recent experience is this: you do not
| need to lint your JSON by compiling and then running a Serde-
| based Rust application as part of your CI/CD pipeline for
| every single commit, when the project is entirely Python and
| Ansible for systems deployment.
| zabzonk wrote:
| This is an ad for a book.
| markrages wrote:
| The Amazon preview included a page advocating for systems
| Hungarian in naming variables.
|
| I am no longer interested in the book.
| rurban wrote:
| He was a Microsoft manager, so this insanity is expected.
| nuancebydefault wrote:
| As programmers we are ingrained to look further than the problem
| at hand. We try to see the bigger picture, solve problems in
| holistic ways if possible.
|
| Often this can lead to over-engineering, creating more corner
| cases and ambiguity in requirements and reduction of test
| coverage. That is a trap to lok out for.
|
| On the other hand it also can lead to better understanding of the
| problem space, increase understandability, and less need for
| later refactoring.
|
| Just stating, 'don't look further than the problem you are
| required to solve' is not an excellent general rule.
| gherkinnn wrote:
| The trick is not to stop at the birds-eye view but to see that
| one small change that is actually required from up high and
| dive back down.
| maxverse wrote:
| There are several books that commonly get recommended for all
| around general programming knowledge (Pragmatic Programmer, A
| Philosophy Of Software Design, etc) Curious how this is any
| different!
___________________________________________________________________
(page generated 2024-12-08 23:00 UTC)