Theta Code

In Handbook For Preclears*, L. Ron Hubbard writes:

Man is successful. That is evident because he is here today after eons of trial and error, good and bad planning. And he is successful because he can change.

Now, you really should read that whole chapter (Chapter One in the book) for the complete context of the quote. It’s actually quite a beautiful and inspiring chapter–well worth reading. But that quote is enough for what I want to talk about today.

Those of you who read my main tech blog know that I talk a lot about change, so this quote from L. Ron Hubbard made me smile when I read it.

What do our software systems do? They change. The environment changes, requirements change–things change. It’s our ability to change our software effectively that largely determines whether we are good or bad programmers. It’s not our ability to construct a system that “works”–although that’s certainly important. No, what distinguishes the great programmer from the mediocre programmer is that the great programmer writes systems that can be changed.

Granted, just being able to construct a working system can be quite a challenge! When you’re a brand-new programmer, that’s what takes up most of the time–learning the language, figuring out how to do things, just making things work. That’s completely understandable if you’re a new programmer, or if you’re new to some language or technology. But once you’ve got a handle on that, it should quickly (or slowly) become apparent that there’s going to be a future to your code, and that means that you’re going to be changing it. If you didn’t plan for change, that’s going to be tough.

What do I mean by “plan for change?” Well, just have the idea, when you’re writing the code, “this might have to change some day,” and think, “what would keep this flexible, while still keeping it simple?” Sometimes that takes learning more about software design, but it’s always well worth it. The more you program, the better you’ll get at it. Just have “changeability” as a goal, and as you become a better and better programmer, your code will become easier and easier to change. It only becomes a problem if you never even care about it, and just spend the rest of your days as a programmer building spaghetti code that “works” but can never be fixed or changed when needed.

And as a note very related to this, never let anybody tell you, “If you’re not coding, you’re not working!” No! Planning, designing, refactoring, and even a bit of scribbling thoughts on paper are all extremely valuable uses of your time, and should not be neglected. Those are a large part of what help you cope with change. Programming isn’t all typing–it’s a bit of observing, thinking, and talking, too.

-Max

* A preclear is the most commonly-used term for a person receiving Scientology counseling. The term “preclear” is used because the person is on the way to being a Clear.

In a series of lectures called the Philadelphia Doctorate Course, L. Ron Hubbard says:

All of your work…is motivated by the future, not motivated by the past: you want to eat tomorrow, why, you work today.

That’s from the seventh lecture in the series, on December 2, 1952, for those who are curious.

So why program? Are we doing it because the boss tells us to? Maybe we’re doing it to eat tomorrow and pay our rent and buy nice things for ourselves. I think a lot of programmers are doing that, and there’s absolutely nothing wrong with that. I mean, it sounds a little unpleasant–working so you can live, while spending most of life at work–but it’s not evil or wrong or something like that. But in addition to all that, aren’t there some people who might take a little pride in their work? Maybe there’s something in the future that we’re working toward–a completed product, a happy user, a piece of software that helps people–something.

Well, that means our software must have a future. And we’re creating that future, right now. In fact, you could go so far as to say that everything we do to the software in present time is somehow motivated by the future. It might be the future five minutes from now, or it might be two years from now. It doesn’t matter how far into the future we’re talking about, it’s just clear that it’s the future that motivates the tremendous amount of thought and effort that we put in to our systems.

We write code now so that we have a working system tomorrow. We put effort into the system now so that it can save us effort in the future. We work on our software architecture so that we don’t have to continually fix our software in the future.

It’s very easy to think of a system as “a series of decisions made in the past that led up to what we have now.” But who cares, because our work now isn’t motivated by a desire to affect the past–you can’t affect the past, that’s a pretty fundamental law of this universe.

You are the programmer, you are the cause of the system right now, and that cause is motivated by the future, one way or another.

-Max

In Scientology: The Fundamentals of Thought, L. Ron Hubbard says:

To stop any creation, it can be established that one once knew one was creating it (finding that thought) and making it known again.

At first, that might seem like a funny thing to apply to programming. After all, aren’t we trying to create programs, not stop their creation?

Well, yes. But there are a few things that we don’t want to create, like bugs, or bad designs. I know I’d be happier if those stopped being created. So how can this quote help us?

Well, have you ever noticed that some programmers produce far, far more bugs than other programmers? They just can’t seem to stop creating bugs. Now, these programmers, have they ever thought back to the moment they were making the bug, and found for themselves what decision they made at the time? Have they ever really taken responsibility for having made a decision that caused a bug, or do they just “fix the bug” and never try to understand the source of it?

Many of the greatest programmers I know have an instinct that they should go back and find out where a bug came from. They just know that this is important, even if they can’t quite articulate why (other than the practical sense of “Well, it might also be affecting other things” or “It’s educational”). When they find it, if they caused it, they’ll say, “Oh, yep, that was me.” They might even explain a little of what they were thinking, at the time.

On the flip side of the coin, some of the worst programmers I know spend a lot of their time blaming others for having caused bugs. Whether the blame is right or not, it doesn’t matter, because what needs to be established is “that one once knew one was creating it,” not that somebody else knew one was creating it. You have to find out for yourself what happened!

This whole thing also happens with software architecture. Somebody makes a decision like, “Okay, we’re going to design this poorly because we’re crunched for time.” Then, years later, they wonder why that part of the software is so hard to maintain! They never went back and took responsibility for having made that decision, they just hacked and patched and fixed–in other words, they kept on creating the bad design.

Often, it seems like there’s no way to handle bad designers or poor programmers. That they’re just hopeless and have to be let go or removed from the project. But maybe–just maybe–something could be done about it by teaching them to go back, note “Oh, right, I did have a thought about creating this,” and then get on with making it better or creating something new.

-Max

In a book called Scientology 8-8008, L. Ron Hubbard defines a “universe” like this:

A universe is defined as “a whole system of created things.” There could be and are many universes and there could be many kinds of universes.

If you’ve never thought about it, it might be hard to envision the idea of a universe that doesn’t look or act like this one. Here’s a way to think about it: Yesterday, I ran into an abstract artist and I had this thought about her art–I asked her, “If you could create a universe, would it look like this one [the physical universe]?” Instantly, she said, “No!” This is something that I had not understood about abstract art until that very point–that it represents a whole universe made by the artist, not a representation of this universe. Her universe has colors and swirls and represents things in a whole different way than this universe.

So that’s a very wild example of “a universe”–the things that you see in abstract paintings. That’s “a whole system of created things” completely different from the universe we’re used to seeing (the physical universe).

In a much less wild way, a computer program is also a whole universe. For example, let’s take a simple program that adds 1 plus 1 and gets 2. (Read More…)

We’ve long known that a programmer’s productivity depends largely upon how much he enjoys his work environment and the task that he’s been assigned. We know that various things that make the environment nicer assist productivity, for some seemingly ungraspable reason.

To me, at least, this has long been a mystery. Why is it that a programmer, given total understanding of his field, excellent training, and high intelligence, could yet produce better in a more enjoyable environment? It would seem to have nothing to do with the interaction between a person and a machine, as programming seems to be.

Well, in Dianetics: The Modern Science of Mental Health, L. Ron Hubbard talks about pleasure, over and over. One of the things he says is:

There is a necessity for pleasure, a necessity as live and quivering and vital as the human heart itself. … The creative, the constructive, the beautiful, the harmonious, the adventurous, yes, and even escape from the maw of oblivion, these things are pleasure and these things are necessity.

Talk to anybody who worked at Netscape in its early days, and they will tell you that there was a sense of adventure in what they were doing. Talk to some of the people who work on Google’s greatest projects, and ask them about how pleasurable they find their jobs. Ask the Apple engineers how enjoyable it was to create the iPhone, or to design Mac OS X. Ask the world’s greatest user interface designers if the harmony of a perfectly usable, good-looking interface isn’t something that makes them happy.

Or just ask me why I have spent the last four years of my life working on Bugzilla.

The world’s greatest creations don’t come from the desire to make a quick buck, or the fear of a manager’s wrath. They don’t come merely from some programmer’s desire to prove how smart they are, and impress their peers. And they definitely don’t come about from organizations where programmers sit, blank-faced and void of thought, forced to stare at a computer to the exclusion of all else for eight hours a day, deprived of the pleasures of life. No, true creation flourishes in environments that bring into being that necessity “as live and quivering and vital as the human heart itself”–pleasure.

-Max

In Scientology 0-8: The Book Of Basics, L. Ron Hubbard says:

Goodness and Badness, Beautifulness and Ugliness, are alike considerations and have no other basis than opinion.

I’ve heard many programmers talk about “beautiful code.” Of course, it seems to mean something different to everybody! People can definitely have arguments over what is good or beautiful in code.

Now, most people don’t write code and then think, “Aw, that code was terrible, horrible, and ugly.” Most programmers are pretty happy when they complete a project, and tend to admire their own creations. They might have a terrible tangled mass of code, but to them it might be beautiful. For us, though, who have to fix their terrible, tangled mass of code, maybe it’s not so beautiful.

So what can we do about people this like? Obviously, we know that there are better ways to write code and worse ways, and we’ve formed our opinions based on experience or having read some sensible things and agreed with them. We can’t just let people write terrible code and mess things up. So what do we do?

Well, has anybody ever changed your opinion about something? How did they do it? If you read something and thought it was sensible, and came to see why “good” code was “good”, and “bad” code was “bad”, then perhaps that person could read that thing too! Perhaps you could explain to them gently why you hold your opinions, and give them the chance to change theirs. Perhaps you could show them some good evidence, and they’d change their mind.

At the very least, a little communication probably wouldn’t hurt anybody.

No matter what you choose, once you realize that all that’s happening is you have different opinions, the way is open to do something about it.

By the way, the quote above is part of the “Axioms of Scientology.” In Scientology, “axioms” are:

axioms: Statements of natural laws on the order of those of the physical sciences.

That’s from the glossary of a book called Advanced Procedure and Axioms, by L. Ron Hubbard.

The axioms are numbered, and the axiom above is Axiom 31. The rest of them are all very interesting, and I’d recommend you get a copy of Scientology 0-8: The Book Of Basics, if you want to read the rest of them.

-Max

In Dianetics, L. Ron Hubbard mentions:

Only things which are poorly known become more complex the longer one works upon them.

Have you ever seen that happen with a software project? It just becomes more complex, and more complex, and more complex, and eventually it’s just a huge mass of complexity that nobody can maintain anymore?

I think it might be interesting to think about that in the context of the above quote. Perhaps there’s actually something more that could be known about the system. Maybe your users don’t actually need or want all those features. Maybe there’s more research that could be done on different areas of the system. Anything, really–just know more about it. Maybe there’s even some fundamental missing data about life or programming that’s hampering the project.

Whatever it is, I think it’s pretty interesting to think that knowledge could defeat complexity!

-Max

In Dianetics: The Modern Science Of Mental Health, L. Ron Hubbard says:

It is not untrue that where one finds the greatest controversy, there he will also find the least comprehension. And where the facts are least precise, there one can also find the greatest arguments.

There are some areas of computing that are very difficult to comprehend. There are also areas where the facts are very imprecise, or where no real facts are known (there are just guesses or theories, instead).

In these areas, programmers can get into endless technical debates that seem to get nowhere.

The subject of “security” is often like this. Developers can get into extremely long technical debates about how to implement security features in their programs, how to fix security issues, and so on. But, um, security from what? Security that allows the user to do what? How important is security? What level of security is important? What is the basic, fundamental point of computer security? What do we even mean when we say “computer security”? If I say my program is “secure”, what does that mean?

Can you see that there might be some things there that are hard to comprehend, or that there might be some imprecise facts in that field?

The subject of user interface design is also like this. Developers can get into some knock-down, drag-out fights about user interfaces, probably because they don’t understand them, and because the field is full of imprecise facts. I personally leave most UI work to the UI engineers, and stay out of it. I let the people who do comprehend these things do their job, and I don’t encourage debates in areas that are poorly understood.

When I don’t understand something, or when the facts aren’t precise enough, I think there’s nothing wrong with saying, “I don’t understand this!” or “We need more data!” And that’s the end of the conversation. There really shouldn’t be any more debate after that, because it’s going to get nowhere!

Whenever a technical debate goes on and on without resolution, I say, “Okay, obviously something is unknown here. What more could we find out about this?”

There’s nothing wrong with debating the pros and cons of technical issues. But when it becomes really controversial or people become strongly argumentative, that’s when I start applying the quote above from Dianetics.

As an exercise, you can see for yourself if this applies. Look at an area in computing where there’s a lot of controversy (such as operating systems, programming languages, security, etc.), and check: Are there some imprecise facts, or is there some missing comprehension in that field?

-Max

In Dianetics: The Modern Science of Mental Health, L. Ron Hubbard discusses a principle called the Introduction of an Arbitrary:

An aribtrary structure is one in which one error has been observed and an effort has been made to correct it by introducing another error. In progressive complexity, new errors must be introduced to nullify the evil effects of old errors.

How many times have you seen this happen with a software project? It’s poorly designed in the first place, and then somebody discovers an error. Instead of fixing the design, they tack on some “hack” to fix the error. In other words, just like Ron says, they keep introducing new errors.

It’s long been known that this is a bad idea, but the new idea here is to look at this as a process of introducing errors. Just because some code “fixes a bug” doesn’t mean that it’s not an error to write code that way. You are actually introducing new errors into your program every time you “hack” in a fix instead of fixing the real root cause of a problem.

I think most professional developers have long felt uneasy with “hacking” in a fix, but perhaps didn’t quite have anything to back them up when they protested and said, “I just want to fix it the right way!” However, if we look at “hacks” as errors, then it becomes easier to see why the “right way” is the right way.

So in the future, when you’re fixing an error, don’t introduce new errors to fix it. Do things the “right way.”

-Max

In Scientology, one of the most important ideas is called ARC, which stands for Affinity, Reality, and Communication.

I was thinking the other day about an interesting way that this applies to computing.

The first thing you have to realize is that as a programmer, your user interface is a Communication to the user. Over a very long distance, you are actually communicating something to the user. You happen to be communicating a window with some buttons and funny words in it, actually.

Now, it’s always mystified me why users like pretty interfaces that are impossible to use. That is, why does it sometimes seem like aesthetics is more important than usability? Well, one important thing to consider here is that the user will have to have some Affinity, or liking, for your user interface. People tend to have more affinity for pretty things. So the more “likable” your user interface is, the more effective your program is going to be. Of course, I think “likable” also includes usable, since I personally really dislike user interfaces that are hard to use. That is, my affinity for them is low. So, both “pretty” and “usable” are important to affinity, for user interfaces.

You as a programmer should also have some affinity for the user–generally if you’re thinking, “I’d like to help this nice guy be able to use my program better,” that’s a lot better than, “All my users are stupid and I don’t care if they can use this thing at all.”

The final aspect of the triangle is Reality, which we usually think of as agreement. Does your user know what that weird little icon means? Is there actually reality (agreement) between you and the user? There are lots of important pre-arranged agreements with computers that are important to remember. For example, “When I click the X button, the window will close.” That’s pretty much true on all operating systems (even Linux, which I’m using now). If I clicked the X button and I got a screen full of dancing pigs, I’d probably be annoyed (though slightly amused), because “dancing pigs” wasn’t really my reality, there.

All together, ARC adds up to Understanding. So, if users are having a hard time understanding your program, check which component you’re missing! Are you failing to communicate something? Is the affinity between you and the user too low? Or is there some missing reality (or some reality that you enforced upon them without their permission)?

There’s lots of ways to use this concept of ARC in user interface design, and lots of different ways it could go wrong. The items in the blog above are just examples, to sort of get your mind rolling on it.

-Max