Realpolitick

It is simply amazing how many ways we can divide people: conservative, liberal, rich, poor, Republican, Democrat, compassionate, greedy. You guessed it - I'm listening to the presidential race on talk radio again. Conservative radio hosts make this race about conservatives and liberals. The politicians themselves talk about Republican versus Democrat. The president pits poor against rich. Everyone has reasons for their position. And the opponent has a compelling counter-example. Class warfare is alive and well!

As it should be. Huh?

No, I'm not writing a diatribe against class warfare. I'm writing a diatribe in favor of it! I agree that class warfare exists. I disagree with the classes. The Bible clearly divides people into classes: sheep and goats, sons and enemies, righteous and wicked. Money and politics are merely secondary issues.

Start at the beginning

Dave Ramsey describes personal finances as 20% knowledge and 80% behavior. Tom Stanley takes it even further in his books The Millionaire Mind and The Millionaire Next Door. Mindset - character - drives behavior. Improving finances involves not just doing what rich people do. It means being the same kind of people.

What, you mean greedy and self absorbed? I can do that!

No, that's not what I mean. Where does money come from? How does one become rich?

Well by working hard, saving instead of spending, discipline, and perseverance.

Bzzz! Wrong answer. Thank you for playing. You get rich by blind luck. Follow me for just a moment here. At some point, every business owner took a risk. Yes, they put research and elbow grease into their venture. They mitigated the risks through knowledge and hard work. But in the end, any one of a million adversities could have completely taken their head off, leaving a bankrupt shell of a person. In many cases, this happened several times before the one successful venture!

In any business, a thousand things completely outside of your control can go wrong. And in the earliest stages, you are vulnerable. You cannot avoid risk. That raises the question, why did none of those things happen this one time? It wasn't you. Remember, these events are beyond your control. Blind luck.

I don't believe in blind luck. And truth be told, neither do you. These events are beyond my control. They are not beyond all control. The Bible shows us that God exercises sovereign control over all things. And by sovereign, I mean absolute and total. Those events that never happened? God did that. God blessed your venture for His own pleasure. Money, aka riches, are a gift from God.

The nature of a gift

Gifts are an act of generosity from the giver. Gifts never expect anything in return - otherwise it's a reward or bribe. Gifts are not earned. They are given solely at the whim of the giver. Wake up - this is the important part. Money is a gift from God, given solely at His whim. You do not earn money. You are not entitled to anything no matter how hard you work. God gives it.

Why does God give us these gifts? Because it pleases Him. Really, it's that simple. He likes it! And He enjoys our gratitude when we understand just how much He gives.

Through the Bible, God let us know what pleases Him. And He stated, as a fact, that He showers gifts on people who please Him. In other words, the path to riches is doing what pleases God.

Now I want to be very clear - following the law (i.e. doing what God told us to do) does NOT entitle you to a lot of money. This is not a deal. Paul made tents to earn money for food. And he certainly obeyed God! We should obey God because He told us to. Sometimes, at His whim, He responds by giving gifts of wealth.

This why it is so STUPID to divide people into rich and poor. The same God who provided one man with wealth gave another just enough. And He did it as He saw fit. Wealth is NOT a measure of God's favor. It is just one possible conduit for His gifts.

Did God do it wrong?

The people who preach re-distribution of wealth believe that He did. If wealth is a gift from God, then it follows that He chose the people who receive it. By taking from them, you believe that God made a mistake. Seriously, you want to stand in front of the God who created heaven and earth, rests his feet on our world, wears the stars as a crown, tells the wind where to blow, keeps us moving around the sun in a safe orbit, and tell Him that He was wrong?

Now having said that, God Himself tells us to give away part of that gift. Notice that He never tells you that you have the right to take it. He instructs the recipient of His gift to reflect His generosity. Our giving builds the same generosity in our spirit. Taking builds selfishness.

Putting the "class" in class warfare

Okay, so we have debunked the idea of wealth as a class divider. If class warfare exists, then what are the sides? I propose that we label them righteous and wicked.

You see, people like wealth because it's so easy to see. Politicians like it because wealth is easy to fake. Character, on the other hand, is harder to hide. So many folks in the news today make it a point of pride that they focus on the issues. "I don't care about their personal life. Do they agree with me on most issues?" That's foolish.

Proverbs teaches us that even the kindest acts of the wicked are cruel. Look at President Obama. A lot of Americans agreed with his stand on "the issues" in 2008. They conveniently ignored the fact that he's a known liar. And they seemed genuinely surprised when, duh, he lied to them. Character matters. Opinions change. Politicians can and should change positions as they learn. Character lasts forever. One righteous man (or woman) who disagrees with me on everything will do more for this country than a dozen politicians who tell me what I want to hear. Of course, if I disagree with a righteous person, maybe my positions aren't so good?

Perl Modules and Packages

This morning, someone posted a question on the Perl Beginner's mailing list about functions. They use two modules. Each module has its own collection of utility functions. For the first module, the code calls the functions directly - with just the function name. With the second module, the code puts the module name in front of the function names. The poster asked why the difference?

One of the Perl experts on the list asked if the functions lived in a module or a package. There is a difference. And the difference is very important. I thought it helpful to explore.

What's in a name?

Let's start with a discussion on namespaces. Consider the variable named $a. Its name is, well, a. So your code declares $a and assigns it a value:

    my $a = 6;
    ...
    $a += 3;
    print "$a\n";

Now imagine that we include a module named foo. foo also has a variable named $a.

    # Main program
    my $a = 6;
    ...
    use foo;
    $a += 3;
    print "$a\n";

    #-------------
    # Module "foo"
    my $a = 27;

The code above prints 30, not 9! What happened? The definition of $a in module foo overrode our main program. Both places referenced the same variable: $a. Now imagine that every module on CPAN clobbered variables in your code! You would rename all of your variables every time you use a new module.

Perl solves this problem by putting a namespace in front of every variable name. Internally, Perl translates $a into $main::a. Technically, you can put $main::a in your code and it works. But why type all of those extra characters when Perl does the work for you?

I picture namespaces like boxes. All of the variables from your main program go into a box named main::. All of the variables from foo go into a box named foo::

    +-----------+     +-----------+
    | main::    |     | foo::     |
    +-----------+     +-----------+
    | $a = 3    |     | $a = 27   |
    | $b = 'hi' |     | $h = 'oh' |
    | $c = 10   |     | $x = 30   |
    +-----------+     +-----------+

The big match: Module versus Package

Modules are files that you can include. A module uses the same namespace as the code that included it. When we say use foo, Perl puts all of foo's variables in the main:: namespace.

Packages create namespaces. The package foo puts all of its variables in the namespace foo::. You create a package with the package command.

You use modules. The module declares a package.

So back to our original poster's question. He has two files (aka modules). That first module drops its functions into the main:: namespace. It is a module in the truest sense - a file that simply inserts itself into the code. The second module contains a package statement. Perl creates a namespace and puts the functions in there. To call those functions, his code specifies the namespace - the module name he saw in front.

Best practice says that...

1. Every module starts with a package statement.
2. Any module contains only one package.
3. The module and package have the same name.

As the original e-mail implies, Perl does not enforce these rules. You must specifically implement them. On the plus side, the rules come from very smart people who have learned hard lessons over the years. Save yourself the confusion and aggravation.

Worst Web Site Ever

I write this post as a reminder to myself. The NET10 website (as of this date, anyway) offers a perfect example of what not to do. Here's the story...

Their technical support page insists that I enter a PIN for Buy It Now. Never mind that I'm not buying anything. The submit button doesn't work at all. I hit continue a dozen times and nothing happens. Cancel works. It drops you back to the home page. This page has no way to submit a technical support ticket!

So I went looking for another way to add this PIN. I found the menu option for that. It says that I have no phone. Huh? The phone's listed right there on the home page. In effect, it's impossible to set the PIN. And it's impossible to log a ticket without a PIN. Therefore, it's impossible to log a technical support ticket.

Maybe it's your browser?

That is certainly possible. That merely begs the question, though. The site does not meet expectations. I expected to get help with a problem on the wife's phone. Instead, I ran around and around never accomplishing anything.

The user doesn't know or care about all of the little pieces that make up your application. They see that they can or cannot accomplish a goal. Anything else gets in the way. As the programmer, those details are my responsibility.

Indexes, Indexes, Indexes

Around 2:30 this afternoon one of our users comes by the Data area.

"PARS is running slow."

This is no surprise. PARS has been randomly performing mediocre to tolerable for most of my two years.

"I go get a cup of coffee and it finally times out just as I get back."

Uh-oh. Slow is annoying. A timeout means the system is down. First we check with the other users. Nope, nothing unusual here. Hmmm. This user performs a search. We emulate their exact criteria. Boom - PARS times out here too!

Okay, the search function calls a stored procedure that dynamically generates an SQL query. I copy out the relevant parts and build the query by hand. It takes 35 seconds and returns a dozen rows. First, I take out the date check. Presto, the query runs in 6 seconds.

Let's see what effect other criteria have. Comment out the client check - 6 seconds. Odd, I would have expected it was just the date search. A little more playing and it becomes clear that three search clauses take 35 seconds. Two only take 6 seconds.

Now I examine the execution plans. Aha! A clue! Two criteria go into a bitmap index. Three criteria do not have the bitmap. What happens if I index the three search fields? We use this query a lot. Relatively, we upload minute amounts of data. So an index won't affect load performance. What do I have to lose?

Well, how long does building the index take? Am I going to bring down the database for 2 hours? It's down now, so again, no harm. Turns out that I was being stupid. SQL Server built the index in like 2 seconds.

I hit the query again. It still takes 35 seconds. I found that very surprising. The execution plan put a lot of time into looking up those fields. The second worst spot was a sub-select. The sub-select checks if we have any records for this row in another table. Actually, I'm looking for the case where we don't have corresponding records. The second table has a foreign key that points back to this table.

No one ever added indices to the database. SQL Server does not automatically index foreign keys either. So for kicks, I indexed it. Pow! The query displays results immediately. I couldn't believe it. I usually hit the button, sit back, and watch the timer for when they finish. This sucker ran instantaneously! I was dumb-founded. My user was happy to get back to work.

What did I learn from this experience? First, I was an idiot for waiting this long. I had noticed that we had no indices two years ago. Performance wasn't that bad. So other priorities moved ahead.

Secondly, a well placed index can breathe new life into sluggish queries. I know, I know, a million DBA's just slapped their palms against their foreheads and exclaimed "duh!". Seriously, though, this was on my radar because, well, it might shave off a few seconds. Going from timeout to instant response, though. I had no idea the effect was so dramatic. Seeing was believing.

So go ahead and chuckle. I deserve it. And now it's time that we look at our other tables. I may be able to eek even more performance out of this system!

All That You Can Be

Vania, we went for a walk on Saturday. You won't remember. You're too young. We walked around the entire park. Okay, I walked around the entire park. You rode in the stroller. That's life with a toddler.

As we walked, I made an effort to pay attention to the trees. There are LOTS of trees down by the creek. Little trees, big trees, trees with birds, and trees with bugs. I also noticed how the trees grew together. They each found space for their leaves. Every tree had value. The ones with birds provided a home. Close to the path, trees provide shade. And all turn nasty carbon dioxide into fresh air. Plus they look downright great all decked out in green.

It kind of reminded me of people. No, not little green men. People come in different shapes and sizes. We have different talents - different ways of changing the world around us. God created a place for each of us, even you, Vania. You will never be everyone else. Your body is broken. Yet in spite of that, you will become all that God created you to be.

In his book How To Be Good In A World Gone Bad, Dr. Jim Spiegel talks about how God plants metaphors of spiritual truths in the real world [chapter 10, Living Artfully]. You have a special place in the world. You will change those around you in some way. And that makes you unique.

Being unique means that it doesn't matter how you compare with other people. God never measures us against anyone else. He measures us against His plan for our life. He gives us all that we need. And expects us to make use of that. Pastor Bob O'Bannon gave a sermon about the parable of talents. Bob made a point that the master praised the first and second servants equally even though one made far less than the other.

God expects Vania to be Vania. He gave you very special talents. Never let the things you can't do distract you from the things you're supposed to do.

Sounds so simple, right? Never is. Too often, people let themselves get distracted by what they think they should do. Schools will want to make you a well rounded person. Your genetic condition puts you in a unique position to ignore all of the noise. Some things will come easy. You already solve puzzles, learn about machines, and manipulate shapes. Focus on those things. Struggling with some subject? Then ignore it. Don't waste your precious energy on things that come hard. Grow in the space God carved out just for you.

Catalyst Credentialing

I really like the Catalyst web framework. It handles all of the boring, repetitive details while leaving me the juicy, fun pieces of coding. For the most recent web application, I added authentication. I pieced together the functionality by reading module documentation. Here's what I learned - all in one place.

Catalyst has a plugin for authentication - Catalyst::Plugin::Authentication. It performs authentication in two steps: look up and password check. Catalyst calls these store and credential respectively. The store accesses your list of users (look up). The credential then compares the password.

Okay, let's walk through this. Henry comes to your web site. You greet him with a normal looking login screen. Henry types in his user name and password. Then he hits theLogin button. Your backend code passes off the user name and password to Catalyst::Plugin::Authentication. The plugin searches the store for the user name. At this point, all we know is that this user is on our list of valid users.

Next, the plugin compares the password Henry typed to the password in his user record. If they match, Catalyst::Plugin::Authentication authenticates Henry and he logs in successfully. Now we know that Henry is who he claims.

The User List

To use Catalyst::Plugin::Authentication, you first configure a store. Remember, the store is where you keep your list of users. Search CPAN for Catalyst::Authentication::Store. There's a whole bunch of them. Shoot, they even have one for when you don't need a store

The store populates a user object with the user's information. The exact fields depend on what your store holds. That's good news. Catalyst::Plugin::Authentication provides standard ways of checking the user without limiting the information you keep.

I used Catalyst::Plugin::Authentication::Store::DBIx::Class. The application keeps a list of valid users in an SQL database. The examples had everything to get it up and running.

Check the Password

99% of the time, you can use the simple Catalyst::Authentication::Credential::Password. It compares the password Henry typed with the password in his user record. Catalyst::Authentication::Credential::Password fully supports encrypted passwords. This part was dead simple to setup.

Unfortunately, my application required a little more. Work uses Active Directory as a single sign-on system. My Linux server accesses it through LDAP. To validate a password, I actually have to log into LDAP with that user name and password. If the query returns a record, then the password is valid. My code never sees a password from the LDAP server. And anonymous queries fails.

I couldn't find an existing Catalyst credential for this type of password check. So I wrote one. Turns out much easier than I thought. Catalyst::Plugin::Authentication calls the authentication method in the credential. Then the credential code calls down into the store for loading the user.

My custom module loads the user from the database with Catalyst::Plugin::Authentication::Store::DBIx::Class. If that succeeds, it then queries the LDAP server with the login and password typed by the user. This is not the normal way that you authenticate with LDAP. Our setup at work is, well, odd.

I created the custom credential module specifically for our setup. Server name, dn, and all of the LDAP settings are hard coded into the module. On the up side, it makes adding single sign-on a piece of cake.

4.01 != 5

Ran into an interesting problem at work this week. And when I say "interesting", I mean "crazy annoying". See, I developed this small Catalyst web application on my Linux laptop. Added cool gradients, box shadows, and round corners using CSS. Everything looked GREAT!

I moved the application onto our test web server. The app should work exactly the same, right? Yeah, I didn't buy it either. Type the URL into Chrome and pow - there's no background on the links. These links perform actions. So I styled them like buttons. All of the styling disappeared.

Long story short, the style sheet set the --webkit-appearance property for those links. I thought that it made the links all the same width. Turns out it does more, and that more messed up their appearance under Windows. Remove --webkit-appearance and the links looks like buttons again.

Now how do I make them the same width? The correct property is display: block. Poof - we're back and running!

Pull up the same page under Firefox. Everything looks great. Links still look like buttons. I'm making good progress here.

Internet Explorer 8 comes last. Ugh! This page is all wonky. Worse - the standard elements I copied from the main web site look all wrong. That's impossible. That exact same HTML appears just fine on our main page. Why not for my page?

I'll spare you all of the dead ends inherent in debugging. In the end, the problem came down to the <!DOCTYPE> declaration in the HTML. Dumb me, I copied it from an older project. So this current document declared the 4.01 DTD. And the HTML content blithely contained HTML5 tags. Oddly, Chrome and Firefox both ignored this contradiction. IE ignored the HTML 5 tags - making the page look downright nasty.

Knowledge in the World
This little experience reminded me about The Design of Everyday Things by Donald Norman. The book talks about the distinction between knowledge in the head and knowledge in the world. See, my problem and its solution with <!DOCTYPE> completely dealt with knowledge in the head. That in and of itself is another problem.

Nothing in Chrome, Firefox, or IE told me the problem. Yet all three clearly saw the contradiction.

Error messages are very difficult to do right. Users really don't care about the technical details. Shoot, I'm a programmer and I don't care about the technical details. I want to know how to fix the problem! Error messages should put knowledge in the world. When I went looking for the error, a message about  tags not matching the DTD would have gone a long way. It would have taken knowledge the browser had and placed it in the world - so I could see it.

That brings up another good point - know you audience. Error messages for developers leave hints. Point a good developer in the right direction and they'll find the solution. Users, however, may require more hand holding. I would never expect a browser to show users messages about DTD's and HTML versions. Communication means understanding.

Litterbugs and Dirty Houses

Three things happened this last week that all struck a chord. For better or worse, my mind drew a connection between these events. Let's see where this leads...

The first event happened on Saturday. The missus went shopping for pre-school clothes. No, not her pre-school - Vania's (our 4 year old). My wife went shopping with the van. The van has Vania's one and only car seat. I expected to visit the library and park, taking the girls with me in the van.

So there we are standing in an empty garage, Dad, Deanna, Lucy, and Vania. I spent the next hour distracting Vania - who expected to go to the park. Why? Because my wife is uncomfortable driving the car. She can drive it. She has driven it. She doesn't want to drive it.

The second event occurred at church. I was standing around outside. A girl and boy walked along the street. I watched the boy unwrap an ice cream cone. Without even missing a beat, the boy dropped the wrapper right in the grass. Never even looked back or down.

The third event happened on the way to work. I drove by a business owner walking by the highway picking up trash. People had hurled fast food bags, cups, and wrappers from their car onto his property. Bags and wrappers attract bugs. They look ugly.

These three things reminded me of the book Leadership and Self Deception: Getting Out of the Box by the Abinger Institute. The book discusses how we view people as objects. In this state, we hold a fundamental disrespect of other people. Those three events display that fundamental disrespect.

Take the boy with the ice cream wrapper. He had a problem - how to get rid of the useless wrapper. Did the boy solve the problem? Well, no. He imposed his problem onto someone else. Now someone at the church will pick up the wrapper and they must find a way to dispose of it. See how the problem still remains - getting rid of the useless wrapper. Just the responsibility shifted.

The missus did the same thing. Driving the car presents an inconvenience. Taking the van imposed inconvenience on the rest of the family. It didn't overcome anything. It shifted the responsibility. That shifting - the imposition - shows a fundamental disrespect for the person on the receiving end.

I read another Slashdot discussion vilifying the user interfaces for GNOME 3 and Unity. Personally, the new interface is growing on me. Since I just finished the book Psychology of Everyday Things, I wondered how it applies. So with five minutes contemplation, I came up with visibility and gulf of evaluation.

Principle of Visibility
A person has to know what they can do. Visibility tells the designer to make possible options visible. You won't know what you can't see.

Okay, Unity starts up with a large empty area, a gray bar at the top, and some pictures on the left side. What now? All of the geeks immediately said push the icons. And there lies the problem. Notice that our imaginary geek called them icons. He knows that they are and what they do. To him, the next action is visible.

Our imaginary geek has knowledge in the head - he knows what those pictures are and what actions they afford. Other people do not have this knowledge. The innate actions are not visible.

Okay, for the Slashdot crowd, this is a pretty poor example. Anyone discussing user interfaces on Slashdot knows about icons. Do they know that right clicking brings up a menu? Or that you can create your own menus, effectively making drawers? Where do you go to look at everything installed? Finding these answers means fumbling around the interface. I'm not getting work done while I'm fumbling.

Unity relies on knowledge in the head. You have to know certain things for Unity to be useful. That violates the principle of visibility. A menu puts knowledge in the world. You see all of the choices right in front of you without any extra knowledge. Knowledge in the world is easier to learn.

The Unity and GNOME developers are right, though - knowledge in the head is faster. Once I know the tricks, Unity is more efficient than the old menu structure. The problem is how to move people from knowledge in the world to knowledge in the head. Doing that by fiat leads to revolt.

Big Icons
Unity's icons are way too large. No, I am not being hypocritical. For one single icon, bigger is more visible. When I'm exploring 200 for something that looks interesting, I want more options. Bigger icons leave less room. Now I have to scroll or page through the options. To compare options, I have to remember information about what I saw two screens ago. Unity make me memorize things.

See - the interface makes me do more work. That's terrible. A computer is supposed to help. Adding tedious memorization does not help. The interface steals my time and energy.

Gulf of Evaluation
This is pretty easy to explain - Unity is SLOW. It has a noticeable time lag between pressing the Dash key and being to type into the search box. Shoot, randomly, the search box doesn't have focus. I hit the Dash key, start typing the program name, and pow - nothing. I expected to see the icon for my program. Instead, Unity lost my typing and I have to start over again.

As we perform actions, people check the results. Did this action move me closer to the ultimate goal? That is evaluation. The time between performing an action and seeing the results is the gulf of evaluation. We call larger gulfs interruptions. It's rude to interrupt, even for a computer.

With the user interface, we want to keep this gulf very, very small. Your action should have an immediate, verifiable consequence. Unity fails when it takes too long displaying the Dash.

Thoughts?
Judging user interfaces is like judging art. Everyone has different tastes. I memorize commands easier than symbols (icons). For me, GNOME Do was perfection. That most definitely affects my perception of Unity. We'll have to see where Unity goes next...

Working in Your Strengths

I'm sorry this started out on such a negative note. The guy I work with - Nik - once quoted this idiom: worry is like praying for what you don't want to happen. Why in the world would I invite the stuff we don't want? That's crazy! Instead, we're going to stop looking at negative things and instead focus on the positive. Let's work on the good things - I want more of those.

And so you don't think that I'm completely insane, Philippians 4:8 says Finally, brothers and sisters, whatever is true, whatever is noble, whatever is right, whatever is pure, whatever is lovely, whatever is admirable—if anything is excellent or praiseworthy—think about such things. You go where you look. If that's true, why do we spend so much time looking at our weaknesses?

This is how the book First Break All the Rules (by Marcus Buckingham and Curt Coffman) begins. People waste a lot of time trying to fix weaknesses. I look, examine, and analyze my weakness. What happens when I eat, sleep, and live that weakness? I'm miserable. I do things that I can't do well. I never really make a lot of progress. I feel like a complete failure. And that's helpful how?

Instead, why not spend time and energy strengthening things that I'm already good at? Proverbs 22:29 says Do you see someone skilled in their work? They will serve before kings; they will not serve before officials of low rank. Take a strength and make it something exceptional. Now that's cool!

Talents and Skills
At this point, it is important to understand the difference between strength and skill. Ever heard the phrase work to your strengths? First Break All the Rules calls them talents. God created you in a unique way. He made you so that some things come easily and others don't.

Imagine these as roads inside of your brain. Talents run like interstates - four lanes, wide open, and a high speed limit. Add more lanes, smooth out the ride, then you go from point A to point B a lot faster. Like the road system, you have different levels of talents. Interstates represent your strengths. Other talents are simply highways, county roads, dirt lanes, or even underbrush.

As you may imagine, interstates get you more places faster. Underbrush goes nowhere. Some things feel easy. You enjoy them, lose track of time, and feel great when you're done. That's driving down the interstate.

Highways run a close second. You make good time. Traffic flows freely. These talents have a lot of promise too.

County roads are okay. You can get things done. Though you'd avoid them if you can. Improving them doesn't really get you anywhere sooner.

Let's just skip right to underbrush. Face it, in some things I have no talent. And that's okay. I won't waste my time on them. Now remember, the talents aren't a waste of time. Me working on them is a waste of time. I could spend years taking voice lessons and never be better than mediocre. Why? I'd rather spend those years working on my strengths. They'll become exceptional. Mediocre or exceptional - not much of a decision is it?

I'm using a lot of generalities. Talents are like that - general. You cannot learn talents. You're born with them. Skills, on the other hand, you learn. Skills are things that you do. They're physical manifestations of your talents. My best skills are those that correspond with my strongest talents. That is working in your strengths.

So What?
You used to make a joke of putting domestic engineer as an occupation. Take it seriously instead. I'm the employer. This is your job. The great thing about this job - you have the power to make it whatever you want! Don't change who you are. Let's change the job so that it fits you.

We begin with some career discovery questions. These questions come from First Break All the Rules. Their purpose is identifying talents:

• How would you describe success in your current role? Can you measure it?
• What do you actually do that makes you as good as you are? What does this tell you about your skills, knowledge, and talents?
• Which part of your current role do you enjoy the most? Why?
• Which part of your current role are you struggling with? What does this tell you about your skills, knowledge, and talent? What can we do to manage around this?
• What would be the perfect role for you? Imagine that you are in that role. It's 3pm on a Thursday. What are you doing? Why would you like it so much?

We'll go on from there.

What's In a Name?

Do you listen to the speeches about the economy? It grates every time when a politician says millionaire in one sentence and high income earner in the next. Seriously, pay close attention to the next speech - Republican or Democrat. Occupy Wall Street protested against highly paid bankers while citing the statistic that 50% of the wealth belongs to 1% of the population. Even the talk radio host I listen to on the way home does it daily. And I like (aka learn from) what he says. Yet I continue hearing this lie. Say a lie often enough and people think that it's the truth.

Gut Reaction: Lie? Wait a minute, what lie?

Yes - it's a lie. Millionaire and high income do not mean the same thing. Millionaire refers to a person with $1 million or more net worth. Net worth has nothing to do with your income.

Gut Reaction: Potato, potato. Does the difference really matter?

Yes. Okay, let's imagine for a minute that the politicians are right. It really takes a huge, six figure salary plus obscene bonuses to become a millionaire. Getting that kind of gig means you know somebody. You, hard working middle class person, will never become a millionaire by yourself. To get more, you need help. So who's going to help little old you?

And in steps the politicians. Give them your submission and they will give you the money. You need them. You cannot do this on your own.

Now imagine the opposite - there is a difference. You become a millionaire by saving money. You sock away a little bit every month over 30 years letting it grow and grow. This scenario requires no special knowledge. It depends on your character, not a politician.

So yes, the difference does matter. It all starts with whether you have hope or despair. Hope comes from power. With hope, I know that I can change the world. I will become a millionaire. The goal is in my power. Net worth grows with hard work, discipline (saving), and divine blessing. Who I am shapes the world around me.

With despair, I can never reach such a lofty goal. If I can't, then those people who do must have some special power. And it must be evil, because I'm good and I can't. They don't deserve good fortune. Dumb luck.

I read a great book called Leadership and Self Deception: Getting Out of the Box. This book posits that we choose first and justify second. (That's a very shallow summary. Read the whole book. It's worth your time.) That is what I'm saying. I choose hope or despair. Then my economic view becomes what justifies my choice.

Now our conversation shifts from money to character. Hope (or despair) rises from our character - who we are at our core. All of the arguing over money hides the real issue - who am I? And do I really want to know?