September 6th, 2006 2:11pm
In martial arts there is always the fight to decide who is best.
In programming their is no equivalent. A suffiently clever person can always justify a way by appealing to a certain aspect that makes X better under these conditions.
The master programmer is only a master of self-delusion.
Unfortunately, people who make martial-arts metaphors ( and Japanese metaphors, and ZEN metaphors) tend to focus on the wrong thing. Especially when extending those metaphors to programming.
Software is implemented using a relatively rigid framework -- the computer, the computer language. It's not warfare. It IS "knocking on silence, to hear the answering echo" -- basic creation of something concrete out of a fuzzy concept.
But far too often people focus on the Zen Mastery approach in order to try to define what a Master "should know", or how a Master "should do it" -- with the goal of defining what THEY know or how THEY do it as BEING the 'Master' way.
I think "mastery" in Programming is instead wrestling with complexity. Applying hierarchy upon complexity to achieve clarity. And using the tools you know appropriately -- which unfortunately keep evolving under us.
And part of that "mastery" is knowing there IS no "one right way" -- just as in Zen there is no "one right way" either. "There are many ways, but one Dao".
But there are many ways which work well enough. And that's the beginning of enlightenment.
ah, I don't know. I didn't listen to all that. I went straight for the "simplicity is better" angle. I believe that, and I enjoyed the martial arts metaphor as far as it goes.
His idea that a master can reduce complexity to one move is well taken.
I have a habit of simplifying things. It is a talent of mine. I want to be better at it.
But my simplifications annoy my seniors. If a basic simple construct can accomplish the same thing as a more complex construct, which is better? The simpler one, of course. But simple doesn't lead many to satisfaction.
September 6th, 2006 2:48pm
> "simplicity is better"
I have noticed a lot of people use the simplicity argument when they really don't have a deep understanding of the problem and all the implications. It's easy to create a simple solution that's wrong and fall in love with it because it is simple.
Well, now, there you have a very good point. There is a large tendency in programmers (and their supervisors, and their customers, for that matter) to want "complicated". If it's too simple, well, how much work was that?
But really, making it simple can be a lot of work. Condensing many lines of algorithm into the necessary few. Personally, I value that talent and approach. But I acknowledge that few people in my experience do.
"I have noticed a lot of people use the simplicity argument when they really don't have a deep understanding of the problem and all the implications. It's easy to create a simple solution that's wrong and fall in love with it because it is simple."
I've noticed just the opposite. The difficulty is that people who are too deep into the problem don't understand how to simplify.
I spent a day with a senior colleague once arguing about a decision matrix in financial software. He couldn't understand my logic when I said that the 10 or 11 "statements" really broke down to 2 or 3 decisions/branches. I drew a graph and I showed him the outcome (coincidentally it was a true/false graphic with a couple of deviations) and it was like magic.
What he thought would take a whole bunch of code I was able to simplify to a fairly short case statement.
I wish I could do this more often. This is just one situation.
It took him a couple of weeks to get over the embarassment.
September 6th, 2006 3:01pm
Oh, yes, and we still do have the issue that the solution-space is COMPLEX. You can control that complexity by imposing a hierarchy upon it. But there's still an irreducible complexity in there.
You can't get rid of the complexity by 'wishing' it away, either. Which is why trying to implement straight-forward solutions is a good thing. Why make it more complex than it has to be, when it already has to be kinda complex?
"...a certain aspect that makes X better..."
Have you ever *tried* programming X directly? There's a *reason* KDE and Gnome are around. Geez, I'd almost rather stick a fork in my eye than that...
Oh, wait, ok, X is better than a fork in the eye.
Aaron F Stanton
September 6th, 2006 3:37pm
> He couldn't understand my logic
And that's the problem. I have had similar conversations with people. You take a set of stories and they map to a series of tests. Then somone says we can simplify these tests down to a bunch fewer. And they are right.
Sometimes the smaller set of tests is clearer. They reveal a simpler logic that was hidden in the forest.
But just as often the code is less clear because you can no longer map the tests to the stories. So if someone asks you if X happens it's hard to tell because the tests do not reflect the stories anymore.
> Have you ever *tried* programming X directly?
Why yes I did. Back in the day I did quite a bit of X programming. I was horrible at it, but I did it.
There's a Sux donut for ya.
Aaron F Stanton
September 6th, 2006 4:39pm
> There's a Sux donut for ya.
I remember my first tabs at Lisa programming and the original Mac too. That's shit is no less complicated.
Lisa? You poor sad bastard.
Aaron F Stanton
September 6th, 2006 4:43pm