Code like a what?
Creating Passionate Users: Code like a girl:
"I think 'girl code' is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things. Things that aren't just functional, but easy to read, elegantly maintainable, easier--and more joyful--to use, and sometimes flat-out sexy. A passion for aesthetics can mean the difference between code that others enjoy working on vs. code that's stressful to look at. And whether we like it or not, most of the world associates an appreciation for beauty more with women than men (especially geek men). Women may have a genetic advantage here."
There's a good point stuck here in this mashup of quotes and references. I've always been a fan of readable code - it sure makes for less comments and documentation when you have a coding style that enables quick re-learning of something you'd worked on months ago.
I won't go as far as to say the most important thing is writing code that makes other coders drool for the sake of the slobber. The documents I've seen which fell into that category certainly did have pretty code, but it wasn't about formatting or naming. It was all about an elegant solution to a problem. It was about brevity and wit in programming. I guess you could call it beauty if you were of that frame of mind, but I don't think the two are connected in many minds.
That being said, I would wear a
code like a girl t-shirt. Mostly because I think girls are cool, and that there's not that many of them coding out there. Or rather, not enough of them coding out there.
what's a craftsman?
Def. "skilled labor applied towards practical ends"More importantly...
What's a craftsman doing with a WYSIWYG editor?
Shortly, it's about constraints. If you increase the set of rules governing what you can do in an environment, it forces you to be creative to accomplish anything. It's a certain kind of challenge that can be refreshing to creative minds.
I take a cue from music, first of all. Consider the system of pitches found on a piano. It's known as the 12-tone system, and is based on 12 semi-tone notes between octaves. An octave is basically the first and last notes in the simple scales that children sing in with the phrases, "do - re - mi ... la - ti - do". Assuming you're with me, you may also know that the 12 tone system is used in virtually all music in the known world with only a handful of exceptions. It's responsible for an almost infinite variety of types and genres and has provided a solid structure for mankind's musical aspirations for centuries.
Once science had caught up with our musical ears, and around the time that some people in western culture started discovering psychoactive substances, a new movement took hold. "Why only 12 steps between octaves, we know the frequencies, we have the tools (e.g. synthesizers), we can do it better!" Enter a short-lived stint of modern music. Composers like John Cage and others decided to blow the doors off the restrictive 12 tone system and go explore uncharted waters. They composed in 13 - 2000 tone systems, and tried to write the rules along side the music.
If you've never heard anything in this style of composing, you're not missing much. It sounds awful. It's without direction, or sense, or emotion, or resolution. Take my word for it, at its best, it's barely listenable. This comes from someone who studied music, and who loves most everything in music for one reason or another. Modernist music is a serious challenge to even begin to appreciate.
Leaving aside all the highly geeky science which attempted to link brain patterns and human-animal hardwiring to the reason we gravitated to the 12 tone system in the first place, I choose to focus here on a simpler reason why music in 12 tones is better than music in 365. The reason is constraints.
If you've ever come as far as trying to write music, you'll find only some things work, and those things are worked a lot. Only certain combinations of music sound happy or sad. There are a small number of chords that can take you out on the ledge and push you over, resolving that tension. These methods can be taught and learned, or rediscovered all on ones own, but in the end they represent a set of rules for how you hear and what it means. Some things work and others just don't.
Back to the web, please!
I write in a WYSIWYG editor because only some things work on the web. I choose to follow this convention that has been tested and documented, and proven time and time again. My purpose here is not to show you how far out there my design is, or that I don't accept your say-so that this is right or not. Frankly, I'm more interested in getting out some content, and "good enough" in the markup department is just that. If it looks good and works well, I'm happy.
Beyond that, there will be some things that I want to experiment with, and an editor like this can make you really have to understand the mechanics of a system to be able to stretch it beyond it's theoretical limit and see what's really possible. Coding in an environment like this gives me that ability by imposing those constraints. It forces me to put content first (a challenge for any nerd who're more comfortable hacking on someone else's prose than their own), and it limits the range of possibility down from 1,000,000 different design directions and possibilities, to maybe just the first 1,000 or so.
I don't need a full LAMP architecture and a XUL parser for the limited audience I'm trying to reach. As long as I can still convince them that I could install and operate XSL Transformations for their uber-geek Web2.0 enhanced application, than every thing will be just fine.
