The Derisive Moment :: My overly complicated journey to simplicity.

The Derisive Moment

The Best Decision Is One That Can Be Changed Easily

October 20th, 2007

The other day, my wife and I were talking about personality types. She confessed that she had never taken a Myers Briggs test. Back when I worked at GE, these tests were all the rage, and my own type flip flopped back and forth between the two INT? categories, so I was curious not only where my wife fell, but where I did as well. The Google’s first result looked like a good place to start.

Most of these questions hardly require any thought to answer. There’s not supposed to be a right or wrong answer, but based on your personality, your answers pin you into a type. I blazed along with my yeses and noes until I hit #12:

“You believe the best decision is one that can be easily changed.”

What a question. No “maybe”, no “it depends…”. Just Yes, or No.

My gut instinct immediately leaned toward “yes”, but I didn’t feel sure. There wasn’t the feeling of absolute certainty I had when answering, say, #4: “You feel involved when watching TV soaps”. This question was deeper than that.


Better is the enemy of good

So what caused the uneasiness with my choice? It plagued me for days. I struggled to come up with a devil’s advocate position for why “no” might be the proper choice. “Indecision is frowned upon by society.” “We put an intrinsic value on making decisions.” They seemed so subjective, and they all paled in comparison to the logic behind my “yes”–An easily changeable decision is flexible. Plus, an easily changeable decision doesn’t have to be changed. It’s the best of both worlds!

I asked Tanya what her answer was: it was “No”. I couldn’t wait to hear the logic behind this. It turns out she interpreted the question completely differently than I had–in fact, 80% of the other people I ended up asking saw it this alternate way.

She interprets an “easily changeable decision” as suggesting the decision has a temporary nature, and therefore implies some level of slipshoddery or jury rigging. A more permanent solution is, therefore, a better solution. “Easily changed” is a negative attribute, not something to aspire toward.

I, on the other hand, see “easily changeable” as implying flexibility and strategy. Maybe it’s the engineer in me finding the value in easily-changed decisions, but my mind immediately lunged down the techy path: In software architecture, there is great value in designing a system in a modular way so components can be completely redesigned later without affecting the overall system. Why lock yourself into a decision (or solution, or design) when there is the option to keep it flexible?


Types of questions

Perhaps my initial discomfort with “yes” is due to decisions of a completely different nature. All of the truly big decisions in my life just wouldn’t be the same if they were easily changeable. Marrying my wife, having a child–all things that lose something if there is an “easy way out”. In a way, the enduring nature of these decisions adds quality and value to them. It’s the reason people get married (permanent) instead of dating forever (temporary/easily changed). That isn’t to say that a person actually thinks this way when making decisions, but that viewed retroactively through easily-changeable-decision tinted glasses, one could interpret it that way.

Still, I’d argue that this is different from Tanya’s interpretation (and that of the majority, at least from my impromptu study). I’m only applying it to big “life” decisions, and the permanentness forms a sort of meta-synergy with these decisions. It adds to the permanent decision, as opposed to taking away from the temporary one.


A matter of interpretation

Perhaps the question is not so much designed to collect your answer, but to discover your interpretation of the question. Interpreted as I do, the answer is obviously “yes”. Interpreted the other way, I could understand a “no”. Or, maybe to determine your off-the-cuff scope for the word “decision”: Large, life changing choices vs engineering options vs tonight’s dinner.

I decided to leave my answer as “yes” and move on down the list of questions. After all, I could easily change it later.

Spec Work = Investing Cash Money

October 16th, 2007

Back when I performed a lot of freelance coding, potential (and existing) clients often approached me to do speculative work with them. I was drawn in on more than one occasion by fancy salesmanship and the idea of large returns on my time. After all, I wouldn’t be investing any money into this business, only my time.

Spec work, at least as it has applied to me, usually comes in the following proposal: “Hey, Elliott. I have the next million-dollar idea: neckties on the internet. I need a website/application/etc to make it work. How about you develop that application, and I’ll give you a percentage of the profits/company equity/etc.” This is usually accompanied by some number-dropping, claiming large returns in the months/years to come.

On the surface, this sounds great. After all, who wouldn’t prefer to generate recurring, passive income instead of a one-time fee. The problem lies in the assumption that the client’s business model will actually work. Maybe it’s the particular clients I’ve dealt with, but in my experience, this assumption has always been false.

Unless the returns are greater than what you would have charged to do the work, Speculative work is equivalent to investing cash money in the client’s operation. Let’s say that you would have normally charged $10,000 to develop the an online necktie shopping cart for the client, but instead did it for 50% of the profits. After all, he’s going to revolutionize the necktie industry. “The Google of neckties”, he is fond of saying. How is this different from:

  • Client pays you $10,000 to develop e-necktie.com.
  • You do said development.
  • You invest $10,000 in e-necktie.com in exchange for 50% of future profits.

I would wager that an intelligent client sees it exactly that way. Only they continue to make the interest on the $10,000 while you work for free.


No Vested Interest

The root problem with speculative work is that clients have significantly less vested interest in ensuring their operation succeeds. Without that initial $10,000 outlay, so what if it turns out that neckties aren’t the future of online clothing. If, however, they had invested cash in the delopment of the business, they are going to try much harder to make it work. Additionally, I’ve found that non-investors are significantly more wishy-washy about exactly what they want. They’ll go back and forth on designs, layouts, and operational aspects of the project. After all, they are not directly paying you for your time.

There are a couple of alternatives to spec work that I find interesting. One, called Risk Reversal, suggests getting money up front, with the promise that if it doesn’t work out of the client, you’ll refund the money (but keep ownership of the product). That’s fine and good, but people who are trying to get speculative freelancers typically don’t have the money to spend.

So, I suggest the following, rather obvious approach: the client needs to get a loan from a bank to invest in their business. If a reasonable person honestly believes that an idea will produce $100,000 per year the first year (and more into the future), then it makes no sense for them not to take out a $10,000 loan to pay you right now. In fact, it’s overtly stupid for them not to. Plus, it’s tax-deductable! Combine that with Risk Reversal, if you want.


Well…usually…

I’m not saying that taking equity is never the right decision–only that it never has been for me. Maybe an idea is so brilliant that you’re convinced it will work, too. Maybe the client has significant experince in this area, and a well thought-out business plan. Just be wary, and know that there are options the client is neglecting to put on the table.

I may be cynical from my own repeated flops in speculative work, but I hold little faith in a prospective client who talks about big money, but won’t lay any on the table. I’m in the technology business–not the necktie business. And I’m not particularly interested in investing my time nor money (and don’t let them fool you–they’re the same), nor in sharing the company’s risk. Especially if he calls it “The Google of neckties” one more time.

Secure Your Passwords with TrueCrypt

October 7th, 2007

I have a fairly paranoid outlook on security and privacy, and I’ve been known to go a bit overboard in some areas. The passwords I choose, specifically, are a frequent source of jest from my wife and friends. I tend to use long, random passwords for pretty much all of my accounts–from my bank, to my blog. Horray for security.

However, boo for convenience. There’s no way I could remember dozens of 12+ character alpha/numeric/symbolic passwords. TrueCrypt to the rescue.

I keep a small (128kb) file handy on all of my frequently-used workstations that simply contains all my passwords. I have them divided up into various text files, such as “bank.txt”, “shopping.txt” and “internet.txt”. When I need a password, I simply mount my TrueCrypt volume, copy/paste the proper password, clear the clipboard, and dismount the volume. I’ve reduced it to remembering one password. And if my laptop gets stolen? It’s encrypted.

I understand that there are various plugins for FireFox and IE to do most of this, but I also store sundry personal information in there as well. Drivers license numbers and expiration dates, Social Security numbers for my family, etc.

A TrueCrypt volume makes for a fantastic place to hold private data like passwords, personal information, scanned images of personal/financial documentation, and financial files (Quicken/Money/Quickbooks).

Todo List Format

October 4th, 2007

I’ve been thinking about making a list-to-HTMLifier lately. An HTML version of my lists could have nice checkboxes and pretty formatting, and when printed out will allow me the satisfaction of physically checking items off–an unnaturally good feeling.

I almost used markdown to maintain my lists, but the lack of checkboxes was a dealbreaker for me. Perhaps I should have tried to extend it. Oh well.

Now I maintain my lists as regular text files, with very little markup. While I’m guilty of faltering, I try to make sure that the majority of what I add are discrete actions. These, being the highest and most noble form of “to do” item, get a pseudo ASCII checkbox, ala:

[ ] Bring clock to work

[ ] Sort pending photos into the next DVD
[ ] ..burn photo DVD

Obviously these will render as HTML checkboxes. Also, note that I nest subtasks that can’t be performed immediately. Until the higher-level tasks are completed, there’s no sense bothering with the lower ones.

One step below an actionable item is a project. GTD defines a project as anything requiring more than one action to complete it. So, we have:

{ } New Menu changes
[ ] Add 'current' class to currently selected item to highlight it
[ ] Make newly created items populate in 'current' directory, not default directory
[ ] Clean up class names--make a default

Those three tasks belong to the “New Menu changes” project. Note the squiggly braces. This could render as a radio button, perhaps. Or a larger checkbox.

To complicate things, I’m guilty of using my inbox.txt list to just hold random notes and thoughts, as well as specific actions and projects. I eventually filter these out into the appropriate list, but if some program is going to process and render ANY list, it needs to be able to process EVERY list–including the inbox. So, here are a few more formatting rules I try to apply across the board;

  • Lines starting with an asterisk are bullet-point items. Render as <li>.
  • Lines starting with dashes are section breaks. They could render as <hr />
  • Subsequent lines are to be grouped together if there is no blank line between them. This applies to bullet points, tasks, and projects.
  • An ‘x’ in the braces ( like [x] ) indicates that the task/project has been completed. Render this as a checked checkbox.

And, since I’m lazy and end up just typing unformatted junk at the end of my inbox half the time, the magic rule that saves me:

  • Lines with no special character at the beginning are free-form text. Render these as <p>text</p>

Now, armed with a very loose grammar, I can begin really thinking about a rendering engine for this.

Version control your todo lists

October 1st, 2007

I’m a fan of GTD, but there are several places where it breaks down in my life. My entire work day is spent at a computer, as is a fair amount of my time at home. Between my work desktop, home desktop, and my laptop, I have a large amount of items in my various “to do” lists that I’d love to keep synchronized. Enter Version Control.

I happen to be a fan of subversion, but any version control package will do. SVN allows me to easy tunnel my traffic over https, which makes life easy and secure in my world of oppressive firewalls and open access points.

What’s the secret? Simply keep your lists under version control. I have oodles of separate lists for various purposes, all under a ‘lists/’ folder in my home directory. The trick is to update in the morning and commit when you make changes, but even much of that is automatable.

Beside the benefit of maintaining synchronization between multiple workstations, this has a few non-obvious benefits as well. The version control server, by its very nature, provides backups of your precious lists. You could provide read-only access to your lists (or a subset thereof) to specific individuals. Or, you can do fancy server-side scripting/programming to operate on these lists. You could have a script to auto-checkout your lists and generate a daily HTML version. It could sort by priority, or pick stagnant tasks that have lived there for too long. If you’re clever, carefully crafted “tasks” could be pattern-matched at the server to actually perform simple tasks.

That reminds me…I have to add “make list-to-HTMLifier” to my lists…