Keep this in mind when coding

coding_maxims.md

Coding Maxims

• code is debt (and bad code is an unhedged call option)

  • 
  • our users dont care about the code
  • every line of code has costs (your time, readability, maintainability, complexity)
    • its like owning a house with lots of rooms. its nice when your friends come over once a month, but you pay rent every day
  • dont add features unless you're sure it is necessary
  • dont optimize prematurely

• DRY DRY DRY

• keep it simple (especially at first)

• be consistent

• be predictable (aka no magic)

• no magic numbers/strings — use constants instead

• a good repro is 90% of a bugfix

• code is written once, but is read many times

• ship early, ship often

• first code, then ship, then measure, then optimize

• remember the 80/20 rule, and the 90/90 rule

• first you don't know the rules, then you learn the rules, then you break the rules

See also: https://en.wikipedia.org/wiki/Category:Programming_principles

DRY is a dangerous mantra when applied without thinking... If your crossing architectural boundaries, and you think that it's "DRY" to share your dto from one boundary to another all the way down to your persistence layer because, if you don't, your repeating yourself, then your going to be asking for a world of pain in terms of coupling between layers ... DRY within a bounded context / specific scope is the only way to apply this principal...

The rest of your principles are well written and unfortunately I don't see enough like them in other places.

1. I propose these be numbered.
2. I propose "no magic numbers/strings — use constants instead" be modified (or a new rule added) to cover that strings are only for messages for people (e.g. to be displayed, for log files, etc.). If you are doing a comparison against a string, especially in more than one place, that is a strong sign it should be a constant. I think magic strings/numbers specifically refers to input that triggers hidden or non-standard behavior, which is a bad idea even if you are using constants.

Great Maxims Lyoshenka

I love DRY as much as the next guy but when you are moving fast, I think sometimes it’s okay to save things to factor out later. What do you think about the Sandi Metz saying “duplication is far cheaper than the wrong abstraction”.?

Thanks for the Maxims!.

@rchasman he's probably right. As the last maxim says, "first you don't know the rules, then you learn the rules, then you break the rules".

I landed to this page from

https://lbry.io/join-us
(archival copy: http://archive.is/s9kSa )

where at the section titled "Who We're Looking For"
one of the requirements was:

Someone who appreciates that our CTO would create this document and then link it in a job posting.

The following points are a total opposite to how I work in 2018_06 and
therefore I get disqualified in an instant:

• ship early, ship often
• first code, then ship, then measure, then optimize

My approach is that I first try to get a mathematical overview of the algorithm.
I lay out the variables, data movements. That way I can see, where the data movement
related bottle necks (read: one major source of speed issues) will be. That includes
CPU cache misses, even with programming languages like Ruby and PHP.
I construct the algorithm, which includes thinking about, how to encode things,
WHERE AND WHEN data is processed, by trying to minimize both,
algorithmic complexity and the traffic through the bottle necks. For example,
one of the very serious bottle necks is HDD access. It would be nice, if it
were distributed over time, so that when the user wants something,
sub-calculations of the query/command were already cached, reused.
Add to that the reliability increasement techniques and my work result
is definitely NOT KISS-able(KISS: Keep it Simple and Stupid). As my
"code-monster-frog" is not KISS-able, I also fail to meet the

• keep it simple (especially at first)

requirements. As a matter of fact, I do meet the non-repetition requirement, the

• DRY DRY DRY

but I do it by using my own code generation tool,
which implements my version of
write-once-copy-automatically-by-rewriting-content-of-blanks-at-multiple-places
but that makes my "code-monster-frog" even less KISS-able.

And if that isn't enough to scare typical, American style, business-software-developers
away from me, then despite the fact that I'm NOT as good as professional
mathematicians are, I have occasionally heard a "job interview" question:
"What do we do, if our other developers are not capable of understanding the math that Your code uses?"

Add to that that I sincerely despise hierarchy and that I'm a Anarcho-Capitalist
by my political views, and there is absolutely no chance that I fit to any
corporate team. If You want proof, check out my hobby project:

(Redirects to my softf1.com)
http://www.silktorrent.ch

I'm not applying for a job/project with my current post, because I do not think that
I could work according to the requirements listed on this page, but
I certainly like the LBRY.io project social ideals_(I dislike the "blockchain" part,
because I do not think it scales the way I prefer scaling)_. I read the
https://lbry.io/join-us
with a thought that may be I could work on that project as a remote freelancer,
but, clearly I would be a very wrong guy for that team. The main reason why
I write this comment here is to help the LBRY.io leaders realize that there are
really many different social arrangements, how to get good technical results
and the American style approach with huge teams and a lot of social interaction
is not the only option. For example, the moment You require that everybody
must be able to understand the code, YOU REQUIRE YOUR BRIGHTEST
PEOPLE TO AVOID WORKING AT THE LIMITS OF THEIR INTELLECTUAL
CAPABILITIES. In my opinion, the ones, who can't keep up,
should LEARN TO BECOME BETTER, in stead of the best being held back.

My ideal case is that I'm the stupidest person on the team and if I can't
understand what others have done, then I should be pointed to study books
and university level courses that I should learn. As You notice, that
approach is very different from the American style
"everyone-must-do-things-jointly-and-to-allow-that-to-happen-things-have-to-be-dumed-down".
To allow the brightest people to work at their intellectual limits,
the requirement that everyone must be able to read their works,
the requirement that code must be "readable", has to be abolished.
Albert Einstein's works are not readable to a common man and
this requirement that Albert Einstein should only write text that
others can read, really is against my values. Here's a link to my blog post
titled: 2015_10 "the-best-that-I-know-of" Version of Software Development Methodology

Obviously, I'm not telling You, or others, how they should run their business or
how they should do their work, but I am telling/writing that THERE ARE MORE OPTIONS
THAN THE AMERICAN WAY OF DOING THINGS. By all means, I am not a bright person,
I'm an average at best, but strategy can compensate dumbness to the point that
even the Estonian supermafia was able to come up with the following propaganda video:

https://www.youtube.com/watch?v=hj4em2gC5EQ

Thank You for reading this comment and
thank You for reading/watching
my blog, source code and other references.

P.S. I forgot to add that I do have my own view, how to replace the
non-scalable blockchain with a scalable, fast, version. It's described
as "mmmv_symsig_t1" at

https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/wiki?name=Experiment:+mmmv_symsig_t1

and it's a specification, how to use EXISTING CRYPTO TOOLS to
create a distributed signing system. At the top of the page it sais
that the project does not have any source code, but it does not need
any source code, because it's a description, how to use EXISTING TOOLS.
How's that for a KISS?