Creativity and Programming

Creativity and Programming(producing)
Difference between creativity and productivity
How does attitude affect creativity?
People have different inspiration.
Some people might need to be sarcastic and critical to motivate their creativity.  Others might need comfort, positive thoughts, sweetness and light, sunshine and angels, flowers.
Others might need to explore death, fear, panic, zombies, the 'Hieronymous Bosch' side of existence, to explore the fears of the end of life.
These forms of creativity inspire in different ways.  We are all unique!  They share a focus on evoking feelings and exploring them, manipulating, displaying emotions and resulting changes we can experience.
In this sense, productivity can be motivated by experience; we can express where we want to go, and combine expression with work.
We can free ourselves from being unable to act; we can be motivated.

On working at a new job

On working at a new job, how things can end up like a turd pile.
(They often do! How do we protect ourselves from stepping in it?)

They are delivering a coherent software product.  But it's extremely brittle!
Try to make any little change and it blows up.  (or they blow up).
When I start working at a place, it needs to be constant examination.  Constant.  You are working on a complex system so how do you become effective?
Think of a child walking through an elaborate construction carefully setup by another child before-hand.
You can barge around smashing pieces as you go.  Not good!
You can tiptoe around examining things as you go.  Look around, then try,  make a little change, here or there, maybe, -experiment- with some little alteration.
That's the rub!
How does the system respond to your little experiment? Does it BLOW UP? or does it show some possible little aberration?  Something obviously off-kilter?
The trick is simple isolation of dependencies; old fashioned structured programming, object oriented design, modularity, minimize dependencies.

If you cannot add functionality without affecting a ton of external files, macros, tables, global variables, etc.... Then, you've got some problem, no?
The question is to design in a modular fashion so that pieces can be plugged in and removed.  Perhaps this sounds idealistic but it's not. It's simple reality.

It seemed to me the lead engineers were protecting their turf.  They delivered a product that worked enough to demonstrate but that broke frequently.  They could blame changes on the breakage; on lack of 'performance' of other, new, programmers, like me.

There is some greater philosophy here.  Can you bend, change, modify, add, work on, tinker?  Can you make software that is 'robust' or not?  You decide.

First of all, every question, concern, complaint, is a gift, not a curse.  Why not keep studying something?  Why not be open to discussion?  What is there to 'hide'?  Hiding is for private members of classes, not for examination of concepts, abstractions, thought, design.

I simply believe that design can evolve.  It need not be a brittle construction.

In Software, we have this added power, this ability, to change without breaking, to add code anywhere at any time, which does not have to alter the functionality.  And need not break anything. The increased flexibility is what makes software a little better than say architecture with bricks and metal, which will certainly not allow tinkering with, if a completed structure.  In software even if it's deployed.
One can change a module to make it simpler, more efficient, whatever, and not break any of the other system, that might even be running in the field.  That's one thing that makes software special.


Young workers are interesting.  In one sense they're open to changes, differences, alternate ways.  In another way, they distrust the need to analyze, take time, think carefully.  It's some kind of trade-off.  Interesting trade-offs between new and old.

REST

I recently learned how REST is part of good design.
Representational State Transfer means that each module can derive it's state from the messages it receives.  It doesn't maintain state; state is part of the message.  So the nodes on a FSM send state along the edges.
In general: a good object is self contained,  it won't crash because it's state is violated by events that are unanticipated.

Tentacle design

What's not rocket science is the philosophy of the design, and good design.
But that's not the design itself.  The specific design is closer to rocket science.
Philosophy:
Tentacular design:
Every subsystem has some dependencies on other systems.
Any dependencies:
Common Macros, variables, common data, common timing, methods, subroutines, events that influence,
waiting for thread loops (WFMO is wait for multiple object), results, etc.
In short, probes and sensors that cause one subsystem to malfunction based on an event in another module.
Including a bug in another module.
These are all tentacles, reaching into other systems.
Some people seem to have a mistaken belief that "integrated design" is good.
This is false.  Good modular design means creating classes or any modules, that can exist independently of other modules.
That have the FEWEST tentacles as possible.
In C++ or any language.
Very very simple.

Test for Good Software Design (C++ precompiled headers are an excuse)

Here is a great and simple test for good C++ design.
If you have to add a header file for a new class or structure to one module, does it cause many other unrelated C++ files to be recompiled?
You had to add the header include to another header that is included by lots of .cpp files.
Precompiled headers are used as an excuse for bad design.

Good Software Design

1) Use standard C++ code, as few Macros and Globals as possible.
2) As few dependencies between modules as possible. Modules should be as self contained as possible.  Less dependencies on the platform the better, depend on standard C++ only as much as possible.

Conventions, Change, Uniformity, Potential

When I look at software I see potential for change, for improvement, (even if just mine, inside of me, my own understanding).
Stifling creativity.  Uniformity makes it easier to see (transparent) but also opaque to potential to change.
Conventions create the illusion of solidity but the solidity is apparent, but not real, to it's potential for reinterpretation and redesign.
Uniformity and conventionality.
I'm not stubborn, perhaps ignorant.  But the idea that (they) cannot go in and fix my code when (they) have a better idea to demonstrate what (they) feel is needed, or right, is a little odd to me, and hard to accept, and - what's the word, humiliating? hyper pedagogical? self important?
Perhaps (they) are just trying to be pedagogical and I over-react.
I can get emotional sometimes, that's another of my faults, (but even that's open to interpretation).