Argument for High-Tech Sabbaticals

This high-tech professional life is damned dynamic.  Stand in the same place too long and before you know it, high school graduates are able to out-geek you in nearly every aspect.  Staying current with technology is difficult at best.  The high-tech professional must balance life, work and education...  forever!  Yes, for those wanting to get into a high-tech career, take a little note from the CrazyOldProgrammer...  continual education is key to maintain relevancy in this insane world that melds hard technology, creativity and art.

Doctors, lawyers, scientists and college professors all have sabbaticals.  Why not high-tech professionals?  Seriously.  the world of medical science, law, sciences and education is quite dynamic.  So is the world of the high-tech professional.

So why shouldn't we have sabbaticals?  Seriously?  I spent nearly a year developing an internal data management package.  About 25% of that time was spent maintaining existing production code, about 15% was spent performing standard maintenance and performing administrative tasks.  60% was spent in heads-down development, testing and development.  No training, no mucking around with my own extracurricular code, very little surfing software development and data management forums I typically frequent.

Sure, vacations help us chill out and unwind.  But a sabbatical for a year...  six months...  3 months...  hell, a two week sabbatical where I could go nuts.  Mess around with any language or OS or platform.  Maybe take a formal & directed mini-class.  Something that I want to explore within my professional field, not something I must explore in the course of my employment.  Something to help keep that spark alive, at least until retirement.

Sabbaticals for high-tech professionals.  The time has come, oh yes it has.

Curious Crazy Question

Years and years ago there was a pre-employment exam that I took for some company, somewhere.  It has been a while and honestly don't remember the name of the company.  I do, however, remember the spirit of the question...  Here goes...

You run the following SQL on a MySQL server and what is the result?

create table HAHA
(Joke varchar(256) null,
JokePunchLine varchar(256) null);

insert into HAHA values('Why did the chicken cross the road?','The question is, Why did YOU let my checken cross the road!'),
('Why did the geometry professor always eat dessert first for every meal?','He really loved PI!'),
('Why I am Majoring in Physics:','https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgo73UjyvPBVIAJOyGuyTfkuDwkZX7NIBVDr9wDMvkuklhWlD5uyMZWLoay0IT2uFRlIUbFHccNbm6nQb8fZCjJ6_BWQaWAwWWewwpoKqBeTDU5No0aLOGjEnTATeBNnzBwe9Qfu39j8e3I/s1600/physics23.png');

 select '*' from HAHA;

----------------------------------------

And, just for fun, here is a question on a pre-employment test I would give before inviting a candidate to an interview.  You would be surprised how many people got this one wrong...

On a modern computer, from a DOS command prompt, what command do you use to see a directory of files?
A) LIST FILES
B) DIR
C) SEE DIRECTORY
D) Modern operating systems no longer use DOS.

Crazy's Complexity Corollary

The complexity of a system is directly proportional to just how screwed up it is.

No NULL exception? What the Hell???

Just a little end of the day rant about one of my least favorite software packages, Salesforce.

If I do something like this, shouldn't there be a NULL exception?

integer bar = null;
integer foo = 1;
foo = bar + foo;


Absolutely.  And Salesforce's APEX language does indeed raise a NULL Exception.  However, a little different flavor of that will not raise an exception.

Say for example you have an integer field called bar__c in the standard Salesforce object Lead.  You have a piece of code that pulls that object's record into memory; like...

Lead wrkLead = [select ID, bar__c from lead where status='Lock' limit 1];


So, shouldn't there be a NULL exception here?

integer foo = 1;
foo = wrkLead.bar__c + foo;


Well, I would think so, but nope.  APEX just keeps on chugging.  Watch out for this one.  If your data field could ever be NULL, code for it!

Programming Blast from the Past

So there we were, just two consenting adults lying in bed on a Saturday night, drinking a little wine and watching television.

A topic arose; one personal to my very being.  A topic with a history originating in 1982.  One that is personal and unique to everyone with a similar background.  That topic is...  Now, please don't judge...  Is this...

"How many programming languages do you know?"

Damn.  I poured another glass of wine and thought...  'How many computer languages DO I know?'  The incomplete list, of course starts with ones that I know very well and trails off from there.

• C#
• SQL (Including MSSQL and MySQL)
• HTML
• Foxpro (Visual and DOS)
• CA Clipper (Yes, I am old enough to remember CA Clipper.)
• Java & Javascript 
• VB (Although, if asked, I will deny knowing this sorry excuse for a language.)
• Pascal (Includes Turbo Pascal, Delphi GNU Pascal and Fast Pascal.)
• COBOL (includes mainframe COBOL and Microfocus COBOL)
• C & C++ (Just enough to be able to navigate a program.)
• APEX (Salesforces' version of a programming language.)
• SOQL (Salesforces' version of a data query language.)
• IBM 370 Mainframe Assembler
• JCL
• JES2 (Really more of a command interface than a language.)
• Visual Objects

That last one surprised me.  I remember that cold winter afternoon in 1994.  We were told to leave the office before the heavy snow hit.  Not being one to ignore my boss, I hopped in my car, lit a smoke and headed home.

JAVA JAVA JAVA!!!

No, not Java, the computer programming language (or any of it's relatives.)  I mean coffee, java, espresso, mud, perk, decoction, ink, mother's milk, nectar of the gods...  I could go on...  Don't worry, I won't.

What better time than an early Saturday morning to approximate just how much coffee I have consumed since drinking my first cup of Folgers.  I still remember that chilly fall day, some time in my twelfth year or so.  Oh, just a little bitter but with a shot of milk I was hooked.

Many times I have blamed my lack of height on all the coffee that has passed down this gullet.   Or maybe it's genetic; The folks on my Mom's side of the family are all pretty short.  Maybe my lack of height is due to my questionable appreciation for good whisky.  Maybe...  ah...  I digress.

So...   How much coffee have I sipped, slurped or gulped since that chilly fall day?  Let'e do the math, shall we?

Years of drinking coffee:	33
Average cups per day:	4
Number of coffee drinking days:	12,405
Total number of cups:	48,108
Fluid Ounces:	385,440
Fluid Pounds:	24,090
Fluid Tons:	12
Gallons:	3,011
Grams of ground coffee per cup:	9
Pounds of ground coffee:	956

DAMN, that's a lot of coffee! Think I will go make myself another pot.

Salesforce DML Limit... ARGH!

So there I am...  5AM on a Friday morning and I check a Salesforce task that should have run hours ago.   Thunk Thunk Thunk...  Is this thing ON???   Apparently not.

I run it manually and THWACK...  " Too many DML statements: 151"  After an hour of Googling and poking at the execution log the reason for this THWACK is obvious.  This Salesforce job was updating leads within a loop.  That's OK if the loop makes less than 150 iterations.  Shit...  This loop was trying to update thousands of leads.

The solution?  Pfff...  Rather than update each individual lead I need to change the code to place my updates in a List<Lead> and then, after the loop, updating the List.

What the Hell?!?!?  It worked in the dev Sandbox fine, just the way it was!  This is like taking a hot sports car out for a test drive, turning heads while driving 95 MPH down the freeway, feverishly buying the thing, then, once you are sitting in this testicular expression of your manhood, discovering it will only do 65MPH.

The specific lesson here is this...  When writing a Salesforce job (or anything for that matter) in APEX, DO NOT update table data within a loop.

Now leave me alone.  I gotta go rewrite this damned APEX job.

***Edited Oct 17, 2014 - 3PM***
Fine.  Just Effin Fine.  I found out why it worked in the sandbox.  Another programmer meant to refresh his leads in the sandbox while I was testing.  Guess what...  He refreshed my test data as well.  So, even if the 150 DML Limit works in the Sandbox, my testing wouldn't have caused a problem because there was only 50 leads in the damned Lead table!!!

New version is done and tested.  Guess I will get up before the dogs Monday and roll this out.