Finding Financial Peace

What is financial peace? I used to equate it with more money. Boy was I wrong!

We were paying off everything but the house when Vania came into the world. Vania's first formula came from samples the hospital provided. They were those little 1 or 2 ounce pre-mixed bottles of formula. Vania drank the bottle down, and two minutes later spit all of it right back up. So we decided to try another brand.

A new brand gave us the same result. On to soy based formula then. That worked for about a week. Vania still spit up as much as she drank down. My wife moved to a hypo-allergenic formula. That worked well. As a test, we moved Vania back to soy - maybe the dairy had a lingering effect. Nope, less than a week and she spit up the soy too. Hypo-allergenic it was.

Vania was born October 29. It was mid-December by the time we had this sorted out. January's budget was the first accounting for the new feeding regimen. Most parents know that you can buy five pound cans of formula for around $15. One or two cans a month only hits your budget for $30 - not a big dent to the groceries.

The hypo-allergenic formula comes in 1 pound cans. Those cost $27 a can. At eight to ten pounds a month, we were looking at $270. One-fifth of our family (the baby) took one-third of the grocery budget. That's a significant dent.

So I sat down, preparing my emotions for the worst. Down through each category - $270 for the baby's food, gas, electricity, our food, etc. Dropped the remaining debts to minimum, and it balanced! The three debts we paid off that year came to $270 a month. In that moment, I felt like we were winning with money.

Financial peace didn't come from having an insane over abundance of cash. It came from taking control of the cash God did provide. And seeing that when we obey Him, God meets every need. Vania has been a great blessing in our lives. God ensures that we do enjoy her, without financial stress taking anything away. That is financial peace.

We paid off those debts following the Baby Steps taught in Dave Ramsey's Financial Peace University. Proverbs 15:4a says...

The tongue that brings healing is a tree of life.

In our case, this was literal.

Do Compuhters Think?

Chuck: Uhmm, you spelled compuhters wrong.
Narrator: Oh, hey, you're right. That was on purpose? Yeah, that's it, on purpose. It's ironic - talking about stupid machines by misspelling a word.

Okay, I don't buy it either. Truth is, I spelled the word wrong entirely by accident. A fortuitous accident, though. Computers are dumb as a box of rocks. Silicon makes up a quarter of the earth's crust. That qualifies as a rock. Making your computer a box of rocks.

A computer does exactly what you tell it. Nothing more, and nothing less. It makes no judgment. Never considers alternatives. And could care less that you spent 6 weeks writing this term paper. The computer will happily delete it without a second thought.

See - even I anthropomorphise the box of rocks. And I know better. The computer is not out to get you. You won't make it angry. It doesn't get revenge. The computer is a thing - like a hammer or saw. It has no intelligence.

Now, programmers can tell your computer how to do amazing things. Hundreds of millions of instructions go into the word processor so you can write a letter to Aunt Polly. So how does the machine know to put a red squiggly under spelling mistakes? Because some programmer accounted for that. A human being saw the problem, devised instructions for solving that problem, and gave those instructions to your computer.

Fear is the Path to the Dark Side

All of this to say - don't be afraid. There's nothing magical about a computer. Sure, bad things can happen when you get careless. That's why my 7 year old daughter can't use my power saw. She might lose some fingers. When she's 16 though, I can teach her the dangers.

Learn the dangers. Study what you shouldn't do. Then you're free to do everything else. Once you understand the danger, you can use this tool without fear.

The Blind Spot

Our conversation begins with this article by Mark Whitehorn. I've been there. How about you?

My first real life project - fresh out of college - converted data from a 9-track tape into the company's database program. Each record contained 1,200 fields. And every tape had all of the previously loaded data. You read that correctly. The tapes were cumulative.

I finished the project and learned a lot about file processing. Called our client, asked about delivery. He was not sure either. He said to call the data processing center. The center had no idea who my company was or how we could deliver our software. My supervisor was just as perplexed as I.

As we walked down the hall, I happened to glance at the installation schedule white board. There was my client's name - a month out. They did not even have our product yet! No wonder those poor people were confused by my questions.

Assumptions

We make assumptions about the world around us every day. You assume that gravity works. You assume that the hamburger the waitress brought for lunch is really hamburger. This is a normal and healthy part of our lives.

Remember the first rule of programming: Theory and reality never match. And its corollary: My theory's right, reality needs to be fixed. At least, that's how we behave.

Coding Standards: Do It My Way or Else

The time has come, once again, for the dreaded coding standards committee. I don't imagine this conversation - I lived it. Every other year or so someone resurrects this tradition. And then utterly fails to accomplish anything useful. Why?

Coding standards solve the wrong problem. All of those discussions about placement of braces, number of spaces to indent, and routine comments mask the underlying issue - your application is complicated! These minutiae are merely fire and motion discussions. You spend so much time focusing on the bullets whizzing overhead that you never shoot back at the enemy.

Don't believe me? Then why does some form of the standards committee meet every other year? And they discuss the very same issues again and again?

The problem is understanding. Your company drops you into another module/package/program with no training. And you spend a lot of time just learning those little intricacies that build up over the years. How do we cut the learning curve?

Coding standards won't improve understanding. How about comments? Every programmer in the world knows to comment their code. And we get beautiful gems like this:

if x then
  #if condition is true
  [do something]
end if

Writing good comments is very difficult. Now I'm really going off the deep end. Comments are difficult because we write schizophrenic code. In code review, the two biggest non-technical issues are readability and performance. We balance writing code for the computer versus writing code for the human maintainer. Two audiences: human and machine.

Humans and machines understand differently. Go figure, who knew. People read code differently than the computer does. Actually, people have noticed. Coding standards and comments all try to fix one common defect: a person and the computer have to understand the same thing.

Think about that for just a second. People and machines process the code in opposite ways. Yet we're trying to write code where both have optimal understanding. So we move in opposite directions, hoping to reach the farthest distance in both directions. Compromises don't work that way.

Literate programming addresses this problem by organizing code both ways. It provides a framework for writing human oriented code. Then re-arranging it for the computer. You write the program for people. And then instruct the compiler in the most efficient arrangement.

Imagine yourself writing functional specifications and then adding the code right there. Link the code directly with the specification. Seems like the best comments money can buy.

One Time Software

Scott: I'm having trouble with a programmer. As a programmer, he does really well. As a salesman, well, not so much.

Narrator: What do you have him selling?

Scott: He sells his time - his programming services. We consult with small and medium size businesses. My programmer sells his skills for their IT projects.

Narrator: And how do you bid these jobs?

Scott: Well, the programmer talks with the client. Then he estimates the project size. And we quote them a price.

Narrator: I see your problem. It has many causes. And one good solution: iterative programming.

When you quote an entire job, start to finish, you just pit the programmer against the client and sales people. Every project becomes a battle. The customer you so desperately want to help is your enemy. Or it feels like it, anyway.

Iterative programming gives the client control over spiraling costs. At any time, they can say enough. Because every iteration provides working software, you reach a stopping point at regular intervals. The programmer doesn't hide in a cave, running up your bill, until they have a Mona Lisa.

The programmer, on the other hand, has a definite agreement on what the client expects. You see, the client, the programmer, and everyone else involved decided what pieces work by the end of the iteration. The programmer can tweak those pieces to his heart's content. The plan focuses his effort.

This problem boils down to communication. I finally made the connection between my monthly budget and how I write software. Time is money. We follow a written plan with our money. It starts with a perfect month. In the ideal life, how would our money divide out each month?

Then we ignore it. Each month gets a budget based on what we'll actually spend. See, life never happens according to plan. Rather than force life into our shape, we plan for change. Iterative development does the same thing.

You start with an ideal plan. That plan does not reflect what actually happens. It only shows what can happen. The ideal keeps everyone grounded in reality. With a budget, it demonstrates that you live within your means. With scheduling, it means you can deliver what you promised.

Then each month - or iteration - you plan what actually happens next. This step is the key. The communication matters. You can agree on anything - as long as everyone agrees. Regardless of their role, everyone involved is a person.

What's in a Name

Why the whacky name - Imaginary Conversations? Well, simply, I have a vivid imagination. Topics that tickle my fancy turn over and over in my mind. An audience (of one) forms. He/she takes on a life of their own, offering counter points. Rabbit trails materialize, are followed, and come back around. This eventually morphs into a discussion of the pros and cons with my make believe foe. It's pretty sad when I lose.

Right now, I can see you sitting there, a quizzical look on your face, thinking that this guy is plain nuts. Well, yes, just a little. We just had a conversation. See - it's pretty simple.

Topics cover all kinds of diverse, unrelated fields: finances, programming, leadership, freedom, etc. You may notice some common threads underneath. Let me know what they are.

Browse, enjoy, and join the conversation...