Zen Code

[Samurai Jack] was an elite coder from the future who was trapped by an evil
wizard, Apu. Samurai Jack are his legends.

• Audience
• Preliminaries
  • Enemies
  • Power Up
  • Cooling Down
• Attributions

Audience

This guide is for those who want to go all the way with the most powerful tool
that man has ever accomplished: the [General Purpose Computer]. It assumes
you know how to do basic programming already in a common language (outside
LISP/Scheme, etc.), otherwise follow the [OneTruePath]. The Big-Omega
estimate of the value of such a machine is Omega(2^n), where n is the number
of words. With the Internet this theoretical value of these tools is equal to
a human: Omega(n^n), where n is the number of publishers -- roughly the number
of computers or human beings.

What you do with that power is up to you. Like anything, without leaders
technology amplifies the good equally to the bad. There are good reasons why
you should master the machine: if you don't, it will master YOU. People are
changing their lives to adapt to the machines. This is to help you take back
the power.

Data and their relationships are growing faster than any programmer`s code.
There are exa bytes of data wiki:AllDataRelatesToOtherData
now, mostly feral. As such, this is for those who want to go all the way and
forge it into something great. Something Home what any of
your leaders have even thought about.

Preliminaries

Most of what passes for "software engineering" is really the equivalent of a
construction job, run by IQ-deprived construction managers. Just like erecting
a building, good architecture becomes huge in the long run and solid
engineering makes it stay grounded in reality. Otherwise, it's going to be you
and your software looking shoddy.

The only way is to be a master. Without a correct ontology of your problem
domain, for example, you can't do your data architecture, which means you'll
have to refactor constantly or support crippleware. It takes non-
programming experience to acquire such expertise and web programming
flybois/grrls don't have it. Understand? You have to have real experience
outside of programming. You also can't do good engineering if none of your
coders have a clue about machine-level instructions and architecture. Have no
doubt: making good software is just as intensive and specialized as erecting a
commercial building. A building you'll need to maintain (do you want to
constantly repair leaky roofs?).

Mastery is not something that the whole canon of certifications can give you.
Wrestling with the allies below will hone your mind like a grindstone and the
OneTruePath becomes short. Your computer is the ultimate teacher
on your progress. It will hone your critical-thinking skills like no human
can, as it allows no sloppiness and gives no favor. If you're content being a
mediocre programmer, go get your certification and join the programming
circus. Most people succumb to sucking it for the anti-Christ, generating
gigabyte silos of data and code that no one else can use, or they content
themselves with an academic understanding and spend their life writing How
to be an Academic without really knowing the craft of the
true programmer. Those are hardly noble enough destinations for the most
powerful resource of knowledge-sharing and data processing possessed right
NOW.

For those who'd like to jump ahead, start up your abacus and study the
[Gospel of Object Oriented Programming]. If you don't know why you want
Object Oriented Programming, you're probably coding micro-controllers (or
LISP). This former arena can simply be termed "programming" rather than
"software engineering". As for LISP, use it to learn to think like a master,
and then drop it -- it doesn't have the object architecture or type system for
what we/you need for the computers we're using.

Like any worthy path, there are many counterfeits. Some of them speak as if
they have the Way, but when the glamour fades, you'll be abandoned just at the
point where the road forks into a thousand different paths. And then what will
guide you? The market place? For all the programmers out there, there are very
few masters. You don't have to believe me, but the four allies are all you
need. Just bring this little scribble with you and test my words with your
experiences...

...But, hey, if towering monoliths of proprietary data are good enough for
you, you can click your browser`s "back" button now. Otherwise, plan on
growing your neck-beard (or [female equivalent]) and let's go.

Enemies

You shouldn't go into battle without knowing your opponents. On the way to
becoming a Enlightened Warrior of the machine, you'll see
there are only two real adversaries, but they are always alongside you, often
coming from unexpected corners, like Death.

ADVERSARY #1: RushingToTheFinish. You're excited to get a program to work
as soon as possible! But, hey. While everybody likes to see immediate results,
down the road this short-term savings won't be extensible--if it's even
comprehensible. Code-writing should should be like carving a masterpiece out
of marble. Why? To properly appreciate the power of le machine. Most highly-
specialized, highly-worked routines are brittle and break when used in someone
else's code. Meditate on Kolmogorov Quotient instead, grasshopper.
Hidden blow: Prematurely optimizing your code.

The best counter-weapon for this battle is
wiki:TestDrivenDevelopment.

ADVERSARY #2: CruftMonster. You made yourself a nice groove; it works
("AFAIK", right?). You don't want to do the work to re-write it. That, friend,
is the stink of the CruftMonster. OR maybe this: You wrote some code awhile
back. You're not sure how it works anymore, so you don't want to change it,
eh? You pussy-foot around it as if treading on the ice atop a deep lake that
may crack at any moment. That's called cruft. You're a software engineer, not
just a brogrammer, working for LOC? So, bite the bullet. ==>Dissolving
barriers you could be the synthesis who's going to
make it happen!

Test-driven development with doctests is the TightCoupling to
glue these forces together. It is both a security blanket and documentation
for others and yourself. That blanket is helpful because of the large
disconnect between your code and it`s results. By getting rid of any
ambiguity, you can move on with other tasks, allowing a faster cycle of:
coding -> running -> feedback -> re/architecting. That is the essence of Agile
and wiki:XtremeProgramming, by the way. It will
accelerate your progress towards the "insanely great".

Well architected code saves 100 log2 (unarchitected)LOC. That's a huge
savings. The Gospel will help you achieve that, but ultimately you'll need
this project, PositionOS, to see those results. Do you understand the
significance? Apps will take 10k of memory instead of 10M as if you're on a
DOS machine but you will be performing complexities equal to your windowed
applications.

Power Up

Practically, there can be several different "breakdowns" of how you go about
structuring your program, but if you're constraining yourself to a particular
programming language, chose the axis in which your language was designed:
concurrent vs. sequential , procedural vs. functional , iterative
vs. recursive dimensions, et cetera. If you're really going "hard-core",
choose a hardware architecture that fits your application. Otherwise, if
you're not constraining yourself, choose Python/C and make it easy on
yourself.

Understand how to construct expressions in your language. Understand how to
join these "sentences" together to tell the logical story you wish to inform
the computer. Learn how to save that, compile it, and run it. Know that, just
like in literature, there can be several ways to fashion a sentence and say
the same thing, but pick the best way: accurate , precise , clever
, and brief. For Object Oriented Programmers, you should check out the
Gospel of Object Oriented Programming, so you can be sure of
salvation.

Basically, YOU are going to constrain yourself at the top by keeping the
purpose for your program in mind while your language will constrain you at
the bottom , forcing syntactically-valid expressions. That leaves the
middle with the most degrees of freedom, putting ModularityDojo in mind. So the first thing to do is to start there, writing
boilerplate. If your language is as easy as Python, you can write your
function stubs and tests first (showing and documenting all the behavior you
want to be considered passable) and save the first program that will run
(passing the test). If it doesn't give you the right result, you've gained
some knowledge and continue the cycle -> go back and correct it. Continue
Talk:Divide until it passes all tests. The general
idea is that you're going to keep Conquer by
SeparabilityOfDomains the problem with your
SeparabilityOfDomains and TightCoupling, while
the design of the language keeps Divide
forcing you to conquer your Optimize. In the middle, you
Talk:Synthesize -- forming abstract, categorical groupings
(named functions, classes, modules), while simultaneously optimize
your code towards greater perfection until it works and becomes a
ZeroSuperfluousNames that other programmers can appreciate
and re-use. Add TightCoupling and you've put the polish on
your code and can ship it out to the wiki:DataEcosystem. You're
mastering coding, memory use, object communication, and sharpening your code
towards the perfect amount of terseness (truly vorpal code). This scales
from the CPU to larger and larger units (modules, files) like a fractal until
you're at the top and can just send the data, that is: "run" and like a
perfect chain of cause-and-effect, it goes. That's the whole process in a
paragraph. Click on each link for the 3-hour tour, Skipper.

If you're not coding alone, you do it like this. It's called
wiki:PairProgramming. One of you writes all the tests and
the other writes the code. Let the one who conceived of your initial
wiki:DataModel rest while the others start with writing the
tests. As soon as you have the first tests written, the resting person starts
righting code.

Started off with the wrong data model or got a whole team? Whiteboard out your
main architectural blocks as an outline until you get to a fine-grained enough
level that you can start writing tests. Put each block into a file (for your
revision management system) and let programmers decompose different spots
until you can combine files and have a workable app.

Cooling Down

wiki:TestDrivenDevelopment without tools like
Python's wiki:DocTestss become their own [bureaucracy]. The
goal of the Free and a data ecosystem is community. That means
re-useable code/objects, which means trustable and understandable with a
minimum of effort. Readable examples, like DocTests, are other programmer`s
best path to understand and trust your code. When you've got an ecosystem as
big as the Internet, you don't want to have to wonder about the logic in
other objects. DocTests give you that and you get code-testing as a bonus
-- truly great.

Note that I haven't said anything about revision management (where I'd
recommend svn since it has the best partnership with the allies) or
SublimeText (two other hidden "attractors" of
programming) because your relationship to the allies determine these. Remember
they are what's going to hone you into a master -- not the language and
not your tools. These essential tools help you with [ClotheYourData],
[SeparabilityOfDomains], [TightCoupling], and
someof([MinimizeWork]|[ReduceMemoryFootprint]), but this only covers half
of the crucibles, at best. So, you have to figure out whether that's your path
or not -- nothing else.

There is another another set of tools, commonly filed under code analysis
, but I haven't seen anyone implement them well. Most programmers simply
aren't good enough to architect large code bases for complex problem domains
as might be encountered in big business, and most tools mislead them because
they don't understand that either (hence Agile's ascendance). Nonetheless,
like code profilers, they could offer the programer important lenses into
their semi-linear (2-d really) codebase. One tool, for example, would be a
code visualizer that graphs all objects and their function calls into a
3-d visualization with edges to indicate where calls were made. You could even
step through the code and watch the action move around between screen objects,
clicking the objects to inspect them, etc. The other is add a heat map to
your profiler (or even aforementioned visualizer) that adds degrees of color
so you can see the degree of usage of every function or object call in a way
that the visual cortex can process immediately.

Anyway, stamp a version number on your program when you get something
interesting (
The right outcome of the battle between You and the CruftMonster is
Parsimony (read: simplicity + harmony) and personal Enlightened
Warrior.

I'm going to give you another lens in which to view the value of the tools you
have at your disposal: the
wiki:GeneralPurposeComputer and the Network.
Earlier I suggested that these, with transactions and the creative economy,
will give you O(nn) value. Since this was not an algorithm analysis, we should
be using big-omega (Ω), as the claim was a view from the outside, from the
top, but I don't have time to update this document. Here's the analysis from
the data scientist`s perspective (I'll use the term m to distinguish from
the usage above):

The basic programming environment gives you O(m) value out of the computer
by turning repetitive tasks into simple computer routines that, thereafter,
make them constant complexity (done in the mind of the coder). The other
complexity being managed is your data. There,
wiki:ObjectOrientedProgramming and named functions will simplify
things further to get you an additional O(m) value. The value from these two
tools, I'll call looping and grouping. (What is m?, then, you might ask:
m is representing the complexity of the world and you are condensing this
complexity into something simpler and more manageable -- that is what all
these electronic gadgets are doing generally. Unless you're going to simulate
the whole universe, I'd estimate m on the scale of millions. Combine them
and you don't get m + m or even m * m. No, OOP allows you to create arbitrary
groupings so you get 2 m value -- that's about enough to simulate a
universe. Why is it geometric? Reed's Law again. Their value is like having
two axiis/dimensions rather than one. O(2m): that's the general value of
programming enterprise and you can see how Steve Jobs and IBM made the
personal computing revolution.

There's more, though. We're not in the 70's. Again, I'll change the term used
( p ) and now add the social scientist`s perspective. We've got p
programmers and so get p as a multiplier, each one having access to this 2m
value of the general purpose computer. Adding the network combines another
p factor via the time savings of sharing data + code. This is linear
because, as the computer just sees both of these as the same (a la
VonNeumann), it's simply transferring these across without processing them.
The wiki:DataEcosystem combines these two into O(p * p) or
O(p2) -- Metcalfe's basic value of a fully-connected network, as you should
expect, but p here is the people.

Now, how do you leverage the value of the Internet revolution for software
engineers? How do you combine these two separate tools offering O(p2) and
O(2m) value to express their awesome, theoretical power? Again, they are
orthogonal to one another. The former is like two axiis on the plane, the
other is like the objects created thereupon. So, cancel out the common
exponential in each one and you get O(pm). (That's a neat trick, eh?) With the
vastness of the internet and the world at large as p eople continue
generating data over time, m and p approach parity. In other words, the
needs of a functioning world government and it`s complexity of data will tend
to make m (the quantified or ordered complexity of the world) be rise with
p (the population). Therefore, I'll argue, that the value of our project
here is O(nn) (distilling back to our original term: n ). Radical. And
that's not even all, because we can be free agents in a thriving [macrocosm]
(offering another cross-product with a separate O(nn) system) with our
technolgoy. That's O(nn). Tetration. Redemption. Grok it.

Whatever the case, once you make it to the end of this road, you'll have found
that the enemies and techniques of programming are applicable to life itself:
don't rush, but beware of your own cruft. You will have achieved Elegance
and have become the wiki:MasterOfTheMachine!

Perfection is attained not when there is nothing more to add, but when there
is nothing left to take away. -- Antoine de Saint Exupéry

Now sacrifice your wiki:NetHack and let's go!

Attributions

Special thanks to the denizens of
wiki:RefactorMercilessly and the
wiki:wikiwikiweb (creator of WikiWords and home of eXtreme
Programming), wiki:TimPeters for inculcating Python with some
powerful Zen via wiki:DocTestss, wikipedia:Bjarne
Stroustrup for providing the concept of encapsulation to
me, wikipedia:Niklaus Wirth and PLU for
the concept of modular programming and [Big O notation], Wikipedia:Bell
Labs for inventing C and many other old-school programmers who lit
Zen. Inspiration for this document and format from don Juan
(Carlos Castaneda) and the Tao te Ching. See also the C
FAQ for some powerful wizardry. Folks from wikiwikiweb,
feel free to add your name to this document below -- you helped make it
happen. Sunlight Labs: Get in touch! User:Average (User
talk:Average) 15:00, 17 September 2015 (UTC)

Other credits: .add.your.name.here.
[Category:Programming][Category:Reasoning]