Code: under, over, seasoned developer

So, I was recently told by a friend that someone has developed three phases of growth for a software developer: under-developer, over-developer, seasoned developer. The first goes for the most obvious solution without regard for tomorrow, the over-developer has learned this to be bad and is now creating hugely too complex solutions to compensate for every possible scenario, the seasoned developer knows exactly how much complexity to introduce at exactly the right moment.

I have decided that I don't like these descriptions, mainly because I don't know how to evaluate myself with respect to them. So I've come up with a different scale: implement solutions which account for the farthest you can see into the definite future, and no further. If you have a nail in your tire and are loosing air at a rate such that it will be flat this time tomorrow if you fill it up now, and you have nothing else which you are required to do today, don't just put air in it and wait until tomorrow. Take it to the shop. Now, if you do have things which demand your time today, then put air in it, and make a note somewhere reminding yourself and anyone else who may drive the car that the tire's going flat.

Labeling code portions

Every portion of an object should be notated with how good the creator believes the implementation to be. This allows the most minimalistic implementation possible to be used on the first cycle, while leaving a notice about how good of an idea it is for another developer (or the same developer) to use it as a basis for other features.

functionalism in programming

The problem with most imperative programming languages is that there is no formal definition for the relationship between methods. Within one method, another is called, but the calling of the second method occurs in a way such that the formal definition of the calling method does not include the second method call.

Mind/model/reality interaction

Recollection and internal production produce a stronger understanding than recognition.

Programmatic Unit of work and information travel

So, after making some basic claims about how the smallest unit of work must be implemented in an imperative way, there's the question about what that smallest unit of imperative operation works on. So there needs, perhaps, to be some kind of declarative way to define the stuff that gets passed to this smallest unit of imperative work. Need to look into UML stuff a little deeper...

Declarative Software Design

I'm thinking that software architecture should be entirely described in a declarative fashion... well, almost. The most basic element of work in a software project probably has a built in necessity that it be described in an imperative way. The processor speaks imperative, after all. These units should be sufficiently small that they can be easily and completely described in, say, a sentence. Much imperative code has complexities which require substantial study in order to be able to say, "ok, I understand the 'why' of what's going on here". Understanding the why is the most difficult part of reading someone else's code. So, I'm suggesting that the method name, or the preceding comment be able to completely describe the why for the method. This way, you don't have to read the code. if it's behaving poorly, you trash it, and write an implementation which accomplishes the stated why. If the stated why is not working in the program, then you have an architectural problem. This problem exists at a much higher level and should be able to be described declaratively and modeled that way.