Tuesday, September 9, 2014

Remembering your Mentors

I was recently working with a customer who had ran into someone I had mentored years ago, and expressed how great I was as a mentor.

Of course, we all love hearing that, but it made me think of not only others I've mentored, but those that have mentored me.

The first mentor I remember was while working at the Dakota Clinic in Fargo, ND.  I was still in school, but for this 9 weeks we all were supposed to take an unpaid internship.  We went through the interview process and everything, and each company got to choose who they hired.

There were really only two places that I wanted to work.  The first was the Dakota Clinic, and the next as at an elevator nearby the school.  Luckily, I got the gig at the Clinic.  It was the white whale of internships for our class of about 15 people.

I hadn't been exposed much to the AS/400 and RPG before that time.  We had done a little RPG programming in school, actually more with COBOL.  Before that I was self-taught with BASIC, and had taken other courses in Modula-II, Pascal, C, etc.

The Clinic shop was an AS/400 RPG shop.  I really didn't care for the language then.  (This was back in the V2Rxx days).  Fixed format, indicators, yuck.  But it quickly grew on me when I saw how productive it really was in real world situations.

It was while working at this job that I met my first and probably most important mentor.  Her name was Julie.  I remember watching her type commands on the command line from memory, without prompting, and thinking "how the heck can anyone do that?".

I also remember the day she wanted me to update the main screen for admissions into the clinic.  Super easy change, especially using SDA.

I made the change, compiled the display file, and moved it live.

Suddenly, Julie's phone rang.  I was oblivious to the issue, until she quietly fixed the problem and came to my desk and explained to me how level checks work.  I was scared, she was professional and understanding.  Instead of chewing me a new one, she professionally fixed the problem, then explained to me what I had done wrong.

I've had other mentors in my life as well.  But none of them did I get to make such a foolish mistake with.  Julie had taught me enough that most of my positions after that I was able to assimilate into the groups with little or no fuss.

I did have one other mentor, Brian, who was a mentor in the sense that he challenged me.

He was leaving for a trip to a company off-site.  There had been an issue with the PO program for years that he couldn't track down.  As he left work to go to the airport, I remember him telling me "if you find this problem before I get back, I'll buy you lunch."

As he waited to board his plane a couple hours later, his phone rang.  Yes, it was me.  I had solved the problem.  All I needed was that little push from a mentor and I was in high gear.  I explained what was wrong.  It was a very obscure issue, buried in the code, but once I was able to recreate it, I was able to fix it.  Recreating the problem took the longest in this case.

I guess my point of this post is, remember your mentors.  And try to be a mentor to others, using the same good qualities you remember from your past.

Tuesday, August 19, 2014

Why Field Exit? It's long overdue!

When I started talking about Field Exit with colleagues and customers, they were excited.  The community now is so spread out it's hard to know where to go for information.

I also had a couple people mention we didn't need another community, and that there were already so many.  Well, in a way, that is correct.

Some of the communities have been around for a while, and while still functional hold on to outdated technology.

The discussions also seem to repeat every few months.  Simple questions get a flurry of answers (usually all the same, just worded differently) with everyone acting like they're getting points if they answer or if they shred the smallest error in another response.

What I really want from our community is real honest to goodness peer communications discussing projects and technologies that are being used, or could be used.

  • No forcing specific solutions.
  • Using specific examples of past or current projects instead of theory or hearsay.  
  • No answering a question with "why would you want to do that?"  
  • No ulterior motives.  
  • No worry of censorship (even from ISVs and Vendors posting products as solutions).

And especially no suggesting technologies that are outdated (ie SNDDST for email, Net.Data, etc).

SNDDST is one of my biggest pet peeves (along with pretty much anything that uses the QtmmSendEmail API).  Yet these are still being slung as good solutions to sending email on the IBM i.  They're not.  They never have been.  They maybe never will be.

Yes, I have a conflict of interest here because I wrote the MAILTOOL (and more importantly MAILTOOL Plus) software.  But, with all of our software at BVSTools it came from a need or customer request.

The need in this case was for ourselves.  We were so sick of dealing with the IBM SMTP server and MSF and their oddities.  Setup of the server was painful and a crap shoot at best.  Also, since we've used Google for Business for years, we had needs that IBM's SMTP server couldn't provide (authentication and SSL or TLS).

There had to be a better way, and we made it.

Now that cloud email servers (such as those from Google and Microsoft) are becoming popular we're seeing even more customers using the MAILTOOL Plus technology.  Requirements such as SSL/TLS and/or authentication are things that IBM is frantically trying to incorporate and band-aid into their SMTP server process.

MAILTOOL has had that functionality for years.  Again, because we needed it.  And when the need changes, because we wrote the software, we can provide top level support and updates as needed.

I believe we also need a site like Field Exit.

Then entire Field Exit site is written using IBM i technologies as well as open source projects such as jQuery and CKEditor.  It even runs on the IBM i hardware and OS.  You can't say that about most of the other groups.

The site will continue to change as needed, hopefully implementing new technologies as they come along, and are a good fit.

We wanted control of the site (in a sense that we can build it any way required, not control of the content itself) as well as a nice Proof of Concept for the good old fashioned AS/400 folks.  A way to use the technology we love and put it to good use.

We hope to use the site itself as a way to discuss technologies ranging from ILE to Server Side Includes (SSI) to working with the IFS to Web Services.  Hopefully something for everyone.

So, I'm calling to all IBM i (and AS/400!) professionals, ISVs, Vendors and users to join us at www.fieldexit.com and contribute, share and discuss.  We're keeping things simple as they should be.   Check your ego at the door and help the community grow.