Money Makers and Money Counters

I like working as a software consultant. I meet new people from varied domains of knowledge and I get to work with several technologies. I am able to learn new things continually; and boredom is an unfamiliar, unacquainted stranger.

However, there is one aspect of being a consultant that I don't like one bit: accounting for my time and expenses. As a consultant, I'm invariably asked to keep a running total of time and expenses in two (and often more) disparate, unconnected software systems. One is maintained by my employer, the other(s) by my host organization.

Of course, entering data about hours worked and dollars spent in multiple systems as a violation of the DRY principle is antithetical to my professional practices. But even if I had to enter time in only one system, I would find that only slightly less unsavory. And that's the distinction I want to draw in this article.

I like to think of myself as a Money Maker - I like to maximize the business value of people's activities. I strive to inject automation, simplicity, robustness, reliability and other tenets of good design that maximize the value of the tasks people do in their daily professional lives.

I know that other colleagues of mine like to keep track of wealth - I use the term Money Counters for them. They are good at auditing, tallying, arranging, allocating and distributing wealth. I admire them, but I know I am not one of them.

I hasten to add that my classification is neither hierarchical nor a source of pride or denigration. I don't think it's "better" to be a Money Maker or a Money Counter. I do know that most people I'm familiar with vastly prefer one activity to the other for themselves.

I further know that rather than classifying others according to this non-absolute division, it's more important for me to know where my own preferences lie. This allows me to work to my strengths and seek the support of others to overcome my weaknesses.

Embarrassing Acronym

Acronyms abound in my line of work. So much so that we don't smirk but often groan when someone mentions the self-referential initialism TLA. These abbreviations are meant to make conversation easier to conduct by creating nouns [1] from long phrases. Often, however, their brevity does not compensate for the obfuscation they create [2]. Once in a while, an abbreviation can cross the border from the annoying to the embarrassing. 

On a recent project, my colleague Steven "Doc" List spotted the humor (perhaps unintended) in a project named "BO Cleansing". BO stood for Business Objects, not Body Odor. 

Of course, most people would catch deeply embarrassing or offensive accidental acronyms before they become an Internet joke like [WARNING: strong language in linked document] this one. However, the occasional slip in allowing an inadvertently funny acronym may be enough to make a mockery out of an otherwise serious subject. 

Here are a few embarrassing acronyms (or similar) I've run across in my career:

• The IBM Websphere Application Server stores some authentication information in a file named WebAS by default. On more than one project, I've heard hushed references to this file as "the Web with the big AS"
• Borland's C++ Builder had files of type Project Description Language, with the extension PDL − which some some people pronounced as "pedal". If you said "I need a PDL file" quickly, you were bound to get a few giggles and few "ahems". 
• In many demo projects, the names "fubar" and "snafu" are considered par for the course − until you run into a situation where you have to expand these acronyms into their full phrases.

I have no problem with injecting some levity into everyday work and an apt (or even funny) acronym is a good way of doing that. However, the case of the accidentally embarrassing acronym is quite a different story. 

[1] Or verbs: I have been told that "TDD-ed" is the past/past participle and "TDD-ing" is the present participle of TDD.

[2] I've heard people say (and write!) "ETL the OSB data from GAPROD to TSPROD"