How I reassure users that even us IT Pros are human…

Anyone whose worked in the IT world has encountered situations where a user might feel a bit embarrassed when you fix a problem what seemed kind of obvious.   You know the types of situations where the situation can be resolved by plugging in the device.

Being a fallible human,  I have more than my fair share of these…and have posted some of them here

Whenever I need to reassure someone that I’m not at all put out by the situation I tell them my Snowblower Story….and yes, this is a true story.

A few  years ago I lived in Barrie Ontario which was frequently hit with heavy snowfalls.
Shortly after we got hit with about 3ft of the white stuff I suited up and headed down to my garage to fire up the snow blower.

It wouldn’t start….I tried everything!!!

I happened to have the tear down manual for the snow blower, and having no aptitude for mechanical things, decided that it shouldn’t be an issue to tear down the workings and find the problem.

Some time later I had all the external stuff stripped off, and was about to take apart the motor itself (I don’t know why…while I understand the principles of the internal combustion engine I did not have any experience, knowledge or skill in fixing them),  my friend and neighbour Tim came over with a couple of beers to see why I hadn’t cleared out my drive (and his).

When I told him what I was up to, he chuckled and moved the gas tank so he could sit down.

As he did so he paused…

He then handed the gas tank to me and asked if it was empty when I started…

Yes…yes it was.

Sometimes a zebra is just a donkey!

Advertisements

How my stand up comedy class instructor made me a better coder

Years ago, while I was still serving as a military medic my sergeant asked me why I hadn’t signed up for a unit golf tournament.

“Well sergeant,  I don’t like to do things that I do not excel at.”

Her facial expression upon hearing this was very memorable.

As I grow older I’ve started to realize that my drive to find better ways to do things sometimes gets in my way.

 

I was working on a function to recursively parse a string with multiple delimiters into an associated array.

I had it working,  but thought that I could make it more efficient.

That worked,  but thought I could make it ever more efficient.

…you get the idea.

It was getting to the point where I was getting frustrated.  There was an issue with recursive function calls weren’t returning the proper data.

I couldn’t figure it out.

I took a break and saw an email from Jim,  the instructor of the Stand-Up Comedy class I’m taking at Second City in Toronto.

The email contained some notes on a 3-minute set I’d delivered at the last class.

Jim gently pointed out that I was striving for perfection right off the bat and that it was getting in my way.

He talked about how even seasoned comics work to avoid that trap.

He was right.  I had practiced bits of the set for hours working on every nuance of delivery and wording.

I turned back to my code a few minutes later and realized that seasoned programmers and seasoned comics have some things in common.

73 lines of code became 127 lines, and done!

 

 

 

 

Silly mistakes even seasoned IT pros make #1

I keep meaning to post these…I’ve got a bunch,  but I’ll start with the one I just made.

I came into my office first thing this morning,  coffee in hand, and opened Outlook.

I was surprised that I didn’t have any unread mail….

I went to a short meeting,  came back,  sent an email and saw that it appeared that the recipient had responded immediately…except that there was no RE: in the subject line.

That’s right…the reason I didn’t see any unread mail is that last time I was in Outlook,  I was in my Sent items folder.  If I’d bothered to look at the left hand pane I’d have seen Inbox (60)

So yeah,  if an IT person ever makes you feel stupid…remember everyone does silly stuff like this….

 

 

Why Your Programmer Friend Doesn’t Want to Hear About Your Idea for a Great App

I think a safe assumption is that anyone who is identified as a programmer (including the kid whose grandmother says is “good with computers” because they spend 90% of their time in the basement playing Call of Duty) has heard the phrase, “You’re a programmer?  I’ve got a great idea for an app!”

 

I once had this happen to me while out shopping for a new router.

The guy helping me pick one out perked up when I mentioned what I did for a living,  and then proceeded to tell me his great idea.

His great idea was actually pretty good!

So good that I was, at that point, about 75% of the way to a working proof of concept.

That’s one of the main reasons,  that based on my own experiences,  that many programmers don’t appreciate unsolicited ideas for applications.

And yes, we realize that you probably wouldn’t make a fuss if we “stole” your idea,  unless of course the product is in the 0.000000015% of applications that are fiscally successful.

Of course another issue with coming up with an idea for the next Facebook is that many people place too much value on the idea,  and too little value on what it takes to take concept from idea to an actual thing that people can use.

A couple of years ago I was approached by a friend who told me that she had a friend who had a great idea for an app.  All they needed was a programmer!

I resisted, and wasn’t even swayed when the dollar amount “in the millions” was mentioned.

Finally she offered to shut up about the whole thing if I agreed to meet with her friend.    That offer was too good to pass up, so a meeting was set up.

I listened to the pitch.

It wasn’t a terrible idea,  nor did I think it was a great one.

I asked some questions to ensure that I understood the concept.

I then asked what he thought would be his fair share of the profits.

He suggested 50%.   His justification was that without his idea,  that I would not make any money from this endeavor.

I then asked him what he would be contributing to the project.

His response was a confused “The idea?”.

He then responded in the negative when asked if he could provide anything in the following areas:

Database design
Scripting (back end or front end)
User Interface Design
User Experience Design
Server set up and maintenance
Project Management
Business Management
Legal Advice
Marketing
Money

By the time I listed all these off he looked a bit shell shocked.

Then came the big question.

What happens if this fails?

I explained to him that in addition to the approximately 2500 hours of development time this project,  that business expenses,  server hosting,  contracting out work and various other expenses would likely run to $15K to get to the point where we could being testing.

I gently explained to him that while his idea might be a good one,   that getting it to the point where it would be profitable requires a great deal of effort,  time and money.

 

So now you know why your programmer friend doesn’t really want to hear your idea.   And if they do,  make sure you have a contract in place prior to discussing it.   Otherwise there is nothing saying they have to pay your for using it.

This is the standard every vendor should strive to!

Its not often that I gush over customer service.  I will express appreciation and fill out surveys when I’m happy, and leave it at that.

We have been using the iPeople Connect suite as our data repository for just over a year now.   Having our Meditech data available in SQL Server has made it possible to implement solutions that would’ve required expensive vendor assistance in the past.

The iPeople team has always provided stellar support and we’ve been very happy with them.  Today though, they blew us away with their dedication to customer service by reaching out proactively on an issue.

I am working on a project that uses data pulled from nursing interventions.  The project is not yet live and until an hour ago,  I hadn’t had a chance to work on it for the past week.

I noticed that there was no information crossing over from Meditech.   It did’t take me long to discover the reason.  I had screwed up the start date of the download query.

iPeople ECHO allows us to customize download queries in order to ensure the we can get only what we need.   I decided to take advantage of that,  but in doing so I had neglected to add a line of code.

I started the download,  and was immediately distracted by another, unrelated task.

As I was finishing that up my phone rang.   It was Drew Sher from iPeople.

I was a bit shocked as there were no major issues with our system.  I knew this because I was looking at it at the time.

Drew had noticed the error in the download I was working on and called me to help me get it working the way I wanted.

Seriously,  how awesome is that?!

It would be like looking out at your driveway and seeing your dealer’s mechanic pull up to fix something because your car called them!

This is a big kudo’s to iPeople and their excellent staff!

 

 

The Real Reason Why Many Programmers Don’t Have Social Lives

I often have difficulty speaking to other humans.

After hours buried in code,  when I’m forced to communicate with other humans I have difficulty in switching to the rather arbitrary syntax and structure of Conversation.

Many people believe this is why I don’t have much of a social life,  but that isn’t the real reason.   Like most full-stack programmers I only need a few minutes to get comfortable with the current language/platform.

Here’s what happens to many of us when we’re planning on going out…

As we’re leaving we realize we left something important, like our phone, keys etc near our computer.

When we approach the computer,  we think about something we’re working on,  or we remember that we wanted to try something,  or had an idea to fix a problem…

So we think:

I’ll just take a minute and try that…

What follows are thoughts like

Well, that didn’t work!  Maybe if I….

and

now where was that chunk of code I used before??

then, finally..

Wait, why am I hungry?

and/or

OMG, Why is it so dark out??!!!

Then when you look out and see that its not an alien invasion with ships so big they blot out the sun, but rather that its late at night and life has once again passed you by.

Mirth: Making sure that dev/test code doesn’t get into LIVE (Is this lazy, or just accommodating reality?)

In a perfect world database connections and other things that must be changed when you migrate code between environments are neatly stored in one place where they can be easily changed.

With Mirth you can do this using global maps,  however when you do that,  they are exposed to anyone who has appropriate access to Connect.

I get around this by declaring variables at the top of the filters or transformers where I make database calls.

One of the things with my position is that I wear many hats and am the organization’s ‘go to’ for a great many things.  This means that interruptions are frequent.

This means that I when I’m doing something like preparing an interface to move from TEST to PRODUCTION that I can miss things.

Some of you might scoff,  but that is the reality of my world,  and almost 50 years on this planet has taught me that reality is often very far from ideal,   so you plan for reality.

I’m working on a project where I reach out to a couple of databases to pull data that isn’t included in the HL7 message.

Some of the transformations are complex,  and things were complicated by very tight deadlines,  and a situation where the spec “needed clarification”.  (as in I built my end to spec but they wanted a change).

Those of you familiar with this reality thing will know that this often leads to kludged together solutions.

After spending several hours making sure that our iPeople Echo downloads were moving the correct data from our test environment and copying/altering stored procedures and SQL functions I finally got to combing through my Mirth interface to make the changes there.

To give you an idea of the complexity,  I have 13 transformers in my source connector.

I realized that when I moved this to Live that there were too many potential failure points and wanted to prevent them.

So I added this code to my source filter:


var channelName = ChannelUtil.getDeployedChannelName(channelId);

if (channelName.indexOf('LIVE') > -1) {

logger.error('******************** CHECK ' + channelName + ' FOR DEV/TEST SETTINGS! ****************');
 return false;
 
}

return true;

/* Changes for Live
-remove anonymizer
-change db settings in source PID, PV1, OBR and ZDR
-change db settings in destination MR PID transformer

*/

Hey look…a checklist of sorts!

My thinking is that if I forgot to make this very basic change that I’ll look and wonder why all my messages are being filtered!

But then I got to thinking of how many times I’ve been interrupted today and what would happen if I missed a single change…

So I wrote this:

function envcheck(sql,strTest,strLive) {

 var channelName = ChannelUtil.getDeployedChannelName(channelId);

 if (channelName.indexOf('LIVE') > -1) {

 logger.error(channelName + ' **** CHANGE SQL STATEMENT FOR LIVE ' + sql);

 sql = sql.replace(strTest,strLive);
 
 }

 return sql;
 
 
}