Setup the Playground 1st!

Before starting any development project, start by envisioning the perfect environment in which you want to develop said project.  If this environment does not exist, start by creating it - then move on to the project at hand.  Any services, features, helper methods/functions that can be handled abstractly by the environment should be considered 1st.  Only after "the playground" infrastructure has been setup - then move onto the actual project at hand.

The interesting thing about this process is that it is completely recursive, from a large - think operating system scale project - all the way down to an individual line of code.  Literally (as in, the literal definition of literally - not the figurative one!)

In other words, you're going to develop an operating system.  This system will need a file system, memory management, process management, thread management, etc. ... eventually.  But to begin with, whichever of these features are implemented, all operating systems need a bootstrap module.  You (definitionally) can not have an operating system without a bootstrapping function.

So, let's start by designing the much smaller concept of a simple kernel.  Not the final, full OS level kernel - but just the smallest kernel that I can think of.  i.e. If we were given 12 hours to write an OS - could we develop a kernel that could bootstrap a piece of hardware to some sort of "operational" state in 12 hours?  Even though I've never done anything even remotely like this before, I think that with the appropriate training, I could create a kernel in 12 hours.

In fact, there are probably 5 or 6 different ways that a "kernel" could be written.  This is where the creative/editing/design process really kicks into gear.  Because, now (hopefully as just a thought experiment at this point), each of the different approaches can be considered, in the larger context of the 6 months full OS development project that we're actually working on.  Most likely 1 or 2 of these models will show a substantial benefit over the others.

These 2 now become "finalists" as the potential model for our kernel.  At this point, it probably makes the most sense to just pick one and give it a try.  Within the first 3 hours, we hopefully have something productive.  In fact, we probably have enough to be able to really (in depth) re-evaluate our direction, and make sure that our assumption about the two finalists was accurate.  Often at this point in the process, it becomes absolutely apparent that the other approach (or possibly, even one of the 3 that was originally discarded) is actually a much better way to solve this problem.

The key to note at this point in the process is that it's REALLY cheap to switch completely the design at hand.

If we take the full 12 hours before we re-evaluate we're already pretty "locked in" to the design that we started out with.  Be open to change.  Be ready for the fact that many to most of the decisions that you make might be wrong (fail!).  But if you're open to that idea, you're much more likely to recognize the failure, and change course, early!

Axioms, Limitations and Freedom of Thinking

Axioms, Limitations and Freedom of Thinking

Argue for your limitations, and sure enough, they're your's.

-- Richard Bach, Illusions

Where do ideas come from?

That is a harder question to answer than this one:

What prevents ideas from coming?

What I think prevents creative, outside the box thinking, is in most cases arguments for limitation.  In other words, one is never going to break free of "the box", if step one is arguing that there's an unbreakable, cubic shell surrounding your idea!  If you start by coming up with all the reasons that you can't get outside the box, it's unlikely that you're going to find a path out (even if one exists right under your nose).

I've spent many years thinking about this quote, and I think that today, for possibly the first time, I may have begun to understand why arguments for limitations are so costly.

I would contend, that what we "know" is always based on axioms.  Unfortunately, "thinking outside the box" often involves changing ideas that were originally considered to be axiomatic.

When arguing for your limitations, things usually unfold as follows:

Dave: "I want to go skydiving, but I hear you only fall 125 MPH - I want to fall faster.  How can I do this?"
Bob:   "Sorry Sir, it simply can't be done."
Bob:   (often unspoken) "...Because that's how terminal velocity works, and unless you're going to gain 50 lbs, you're just not going to go any faster than that.  Sorry."
Dave: Ya know, I think you might be right.  Oh well.

By starting with a claim of impossibility (before the discussion has even begun), Bob has now (usually inadvertently) hardened as AXIOMATIC the reasons that it can't be one.  What if one of these assumptions (axioms) proves to be either completely, or even just partially wrong?  What if the outside the box idea, requires changing one of these ideas that are held as sacred?

Rather than starting by arguing for your limitations, consider this discussion:

Dave: "How can we accomplish Project XYZ?"
Bob:   "Well sir, that seems tricky.  It appears that for this to happen, A would have to change fairly substantially.  Hmm, B also, does not seem like a viable option.  Although... ya know, if we swapped D and E, then we could remove C altogether and that would solve the problem!  Hazah!"
Dave: "Fantastic - when can we get started?"

The point is, that if Bob starts out by stating the obvious - that it can't be done, he has already taken the "outside the box" idea that D and E could be swapped off the table.  Because for his original statement to hold true (and everyone always wants to be "right"), then D and E CAN'T switch places, so why on earth would he even think about it?

Notice that bob started at A, and first ensured that A and B were not viable solutions.  Only then did he consider the better solution.

Always be open to any idea being "wrong".  That way, you won't miss the really good ideas when they're staring you right in the face.

Writing code is like a mediation/negotiation

There seem to always be two sides of a story when writing code, and to some extent, the process of finding "the right" code, or the most elegant solution ends up proceeding as follows:

I just allow the code to essentially battle itself, with me as the programmer acting as the mediator in the negotiation.

So, the negotiation typically starts with the calling system asking attempting to call a function on the responding system that does not originally exist.  Consider this an "opening offer" where the calling system provides as much (or as little) detail as IT thinks is necessary for the responding system to answer the question or request.

This will generate a matching method in the responding system.  Now, we try to respond to the calling system's request, specifically from the perspective of the responding system.  Hopefully, the information provided is sufficient and an answer can simply be provided.

In many cases though - the responding system will need more information - so it should "request" this additional information by adding a parameter to it's function signature.  This will generate an error in the calling system's code.

By switching back to the calling system's perspective, providing the additional parameter is usually possible. But if it is not directly possible, either the calling system needs to go get the relevant information, or provide the next best option available.

By switching back to the responding system now, maybe the alternate information provided actually works, or may cause the responding system to change it's usage again.

This process continues until a  mutually agreeable set of code is found.

An important note about this process is that at the point that the original "opening offer"  was presented, a final solution to the problem was NOT completely understood.  This process is the method to FIND the solution.  It is NOT presumed that the solution is known at the beginning of this process.