Mastering Programming

Being a good programmer is very easy,

if you keep everything in order.

It gets even easier when you program for yourself,

you become a master of your world of little machines.

Things get difficult when too many machines,

start biting each other, this has been called Leaky Abstractions.

You can think of things inside a program as machines,

some machines move objects that have named values.

Fox example a commonly used object is User,

the name of a commonly used value is email, and value of email is user@example.com

Such an object can be passed through a machine that detects bad email addresses,

example.com is a special fake domain name, so it is a bad email address.

When detected, the entire user object will be bounced, or sent, of copied over,

to a program that suspends accounts, prevents the user with that email from longing in.

When you fill out a login form on a website,

you create a short lived login object, that goes into a system of such little machines.

There could be a machine that has a list of bad emails that will CRUSH! this packet,

and sent an error object back to the login page.

Or there could be a machine that right before password verification,

checks if the user is suspended, and will just say "Invalid Password" instead.

If all you ever do is deal with these little object-passing machines,

then that means you are a pretty good programmer.

But when you search for a job,

people will try to force you to know 50 different things.

No one should tell you what you should excel at,

or define what programming should consist of.

Nor are you allowed to focus on memorizing answers to those questions,

because to really know an answer you have to encounter and solve the problem yourself.

In the course of you mastery of programming,

you will bump into every interview question there is inside out.

Interviews are strange things, because you can build your own Object Oriented Language,

and when asked about Polymorphism, Encapsulation, Abstraction, and Inheritance not recognize it as a definition of Object Oriented Programming.

A definition using those four beautiful words is found in a school text book,

if you don't associate those four words with OOP by having encountered them in a text book, you will fail the question.

Even if you build you own OOP systems, and especially if you frequently employ Polymorphism, Encapsulation, Abstraction, and Inheritance

though other means, such as Event Oriented Programming, or Aspect Oriented Programming, Or Agent Oriented Programming.

Failing an interview does not make you a bad programmer,

it makes you an expert in things that they can't conceive of.

Do you understand what this means,

you can't expect schools to teach you.

What schools teach will make a mess out of you,

you have to learn on your own.

The machines have to be yours,

to connect together.

You must become a Rōnin Samurai,

make people confused, embarrassed, maybe even angry.

The point of programming is not to get a job,

it is to change the world.

The nay sayers will check me here,

what good is a programmer that knows not how to operate DOM, or CouchDB or SQL.

But the answers is, my dear critic,

what good are you for knowing those things.

No good at all,

it is all in your head.

There are just two types of databases, in-memory, and on file system,

if you combine the two together and prefix it with a append only log, you'll have all you need.

Keep your indexes in memory, name your directories after record id like in CouchDB,

and updates with a version-number and a UUID so that they may be saved into that folder without overwriting anything.

Conflict resolution is achieved by looking at the UUID,

just a simple sort on the UUID gives you the winner and thus eventual consistency.

Then just sync servers with rsync,

remember all file names are named with a random UUID in it, no data will ever be overwritten, just updated.

Nay sayers, critics, benchmark sticklers, and ACID Database Test lovers,

go home, eat your vegetables, and drink plenty of water.

In the world of programming you are always correct,

because it is a world of your own making.

You are the creator of your software,

and you also the hacker, the tester, and the administrator.

It is easy to grasp what you have invented,

and use what you have invented to understand, reverse engineer, and infer other technologies.

Your greatest power is simplicity and order,

learn from Ward Cunningham.

Mr. Cunningham connected WikiWikiWeb pages by removing spaces between capitalized words,

if something was camel case, it would immediately become a link to a page named after those smushed words.

The only thing you needed to link pages together was: capitalizing the words you wanted to make a link out of, and removing spaces between them,

system would detect an uppercase letter in the middle of a word, and turn it into a hyperlink to another page.

And best of all, if that page did not exist,

it would say "Hey there, stranger, this page does not exist yet, why don't you create it."

Mr. Cunningham mentions the HyperCard,

and yes, HyperCard is a wonderful idea.

This is what being a programmer means,

you start with node or electron , and your first line of code, and then you move on to OOP or EventEmitter.

Create your first Game, WikiWikiWeb, MUD, or even Interactive Fiction Adventure,

or a bot, or a music programming environment.

So as long as you create your own systems,

within your own realm, you will never get lost, and you will never stop learning about everything else.

Programmers are both Rōnin Samurai, and Real Magicians,

they are unafraid to cast spells and build worlds, and create universes.