Egoless Creativity

This was best placed into words by RobertFripp (paraphrasing): the goal is to place ourselves in a state of mind where music places us in its confidence. Throughout his writings, he never talks about what he does to make music. He considers himself a conduit. Music is out there and it reveals itself to him. I know that I feel the same way when I am creative.. that it is outside of me, it is right, and it reveals itself. There is an automatic aspect to creation. I suspect that it is pattern matching on a grand scale. We, as conscious creatures absorb patterns (in the dictionary sense). Creativity occurs when a problem matches against something that we're barely aware of and then rips out much that we are not aware of so that it can have full form. This is not completely atomic, it is a dance between an automatic part of our minds and the environment.

This is a different aspect to egolessness than that of EgolessProgramming. It is akin the artistic temperament. A person who believes that what is right is outside of themselves can, at times, be just as strong headed as someone who thinks that they are creating it themselves. Perhaps more so. RobertFripp talks about how he had a vision of what each person in his band, King Crimson, should be doing.. how the band was to be a completely democratic set of four egoless participants playing what was the best expression of themselves in the group context. Unfortunately, he was the only one with the vision of the kind of music they should be playing, so he was rather covert and dogmatic about trying to impose this "freedom" on the group. FormLiberates.

EgolessCreativity does not have to be a trap. It can be a useful story to tell ourselves.

Why is it trap at all? I think it is me at my best.

Then you are a good leader. With the right blend of personality traits, EgolessCreativity finds its outlet and reward. Without them, it can be downright anti-social.

It is really a matter of imagination. There is the old advice that I've heard: if you have a very hard decision to make, sometimes it makes sense to imagine that some other person whose judgment you respect immensely is there with you. Ask them how they would do it. If you start to do this with (largely) inanimate things like software you'll find yourself observing more than you ever have before... developing a sense of what feels right... how software actualizes its potential.

If your software has to be done quickly, imagine it impatient, action oriented, here to do a job but waiting for you to complete it. It'll tell you what to do.

-- MichaelFeathers

Bright emotions can enhance your experience of the wiki much much more than they can tarnish it. It may be necessary for you to handle an obstacle to your comfort here by addressing the one who brings it directly. Be in the spirit of the familiar oyster simile. You are like an oyster stranded on an oyster bar where a grain of sand becomes a bother. But, in time, it is transformed into a pearl.

The moral of the story here is that it is not necessarily “bad form” to single out personalities you meet on the wiki. A well-delivered piece of advice can initiate a healthy personal relationship, and it certainly wouldn’t have to imply an ill will. But remember there’s usually more than one kind of viable approach to a solution to this sort of problem. Thich Nhat Hanh tells a story about a young girl attending a foreign school who was in constant strife with her peers because her speaking accent came from an enemy nation. Her easiest way out, naturally, was simply to change it.

One good way to get into flow is to write UnitTests and run them all the time. Write test, write line of code, run test, repeat. It builds a rhythm that sustains energy for longer than I've ever experienced any other way. And the code generally works, so there's less frustrating debugging. -- RonJeffries

Do you always write UnitTests first? ... in code?

Yes, we don't write test specs first. We take the UserStory, and with (usually brief) verbal input from the customer, we write the EngineeringTasks needed to implement the story. We start on one of the tasks. It might say "change the savings system so that over 42,000 dollars of base, savings percentage can only be 29% overall". We write a UnitTest in code that sets up a guy with 42,000+ base, and some kind of savings plan, and the test checks to see if his percentage is 29%. It isn't, so we "fix" the code so that it is. Then we set up another guy, until we've covered the cases. In a complex situation, the developer might sit down with a couple of other developers, kick the problem around, do a little CRC, write notes on a card describing the cases. That's as close as we get to "English test specs". When the tests and code are done, she'd throw the card away. (Some would actually squirrel it away in their desk drawer, but rarely do they ever get referred to, and they're not a tracked or formal document). -- RonJeffries

Does this require having a TestingFramework?

You don't need the framework, but it helps. It's available for Smalltalk, Java, C++ and Python. It could certainly be ported to most real languages. Another way to set up a suite of UnitTests is to write them as functions in whatever the language is, and build a main program that just calls them all one after another. I'd advise using a similar setup to the TestingFramework, in that it's best to set up each test, run it, record results, tear it down, so that each test gets a clean space to run in. This helps avoid cascading errors. -- r

I have tried the Write test, write line of code, run test, repeat approach, and found that (after a little practice) I did fall into a strong rhythmic pattern of work. Admittedly, I usually wrote a couple lines for code between tests, but it was never more than about 9. I churned out more code than I ever had before, I was very confident in the quality of the code (it passed the tests), it was all directed toward the problem I was solving ('cause I didn't write what I didn't need), and apparently well-factored (much later I came back and easily understood and extended the code). The best part was that I did not feel drained by the process - I went home happy and, well ... not rested, but not wrung out. I had more energy to spare for my family. -- BillJamison

CategoryCreativity