Mike's Blog

We are by no stretch of the imagination "the ultimate ColdFusion shop."  Our applications have flaws that are not only inherited (we did purchase our software from another company) but also home grown.  However, we aim to travel down a road of best practices going forward.  That means we expect our ColdFusion developers to follow a pattern of smart, well-planned programming, with the understanding that we'll stumble over some not so optimal code along the way that needs an adjustment.  These are the expectations of our current employees, so it seems only logical that we have the same expectations of our applicants.  Most of our applicants, however, disagree.

We phone screen our ColdFusion developer applicants before interviewing in person.  This saves them time and saves us time as well.  If you don't know your stuff, you don't want the discomfort of sitting in front of us when that is realized, and we don't want the discomfort of ending an in-person interview early.  Unfortunately, this method of interviewing exposes us to uncomfortable pauses, blatant Google searches for quick answers, and sometimes just outright, made-up nonsense.  Here are some examples:

• Applicant A uses Unit Testing to test performance issues.  "If the 'unit' takes too long to, ya know, finish up then you know the 'unit' needs to be tweaked."
• Applicant B uses CFQUERYPARAM the same way he uses CFPROCPARAM.
• Applicant C answers all of my object oriented questions from the first Google search result that she and I BOTH found when I overheard her furiously typing after my question.  I began staging all of my questions to following that article to the letter.  I'm sure she was delighted!
• Applicant D uses CFLOCK and CFTRANSACTION interchangeably assuming they both do the same thing.

Yep, nobody is perfect.  But these applicants knew they didn't know the answer before they attempted their answers.  So why the BS?  Our environment is one that fosters growth and learning, but we need to know what you need to know first!  But most importantly, we need to know that you intend to be honest with us and that you're not representing yourself as something you're not.  Honesty is the key to fitting into a group, discovering what you do not know, and learning.

Do I have your attention?  I thought so...

But really, there's some truth to the title of this post, at least from what I'm seeing whenever we open up a requisition for a new developer and begin interviewing.  ColdFusion has been around for a while now, so we're seeing resumes from developers with over a decade of experience.  What we're not seeing are developers with enterprise level experience on enterprise software solutions.  Is that because ColdFusion isn't deployed in the enterprise?  No, that can't be it... We know that it is!  So what gives?

Here's a quote from the comments on another blog:

The "Jobs available" argument is spent. Yeah, there are more .Net and PHP jobs out there, but there are more developers available for that work too. Those positions, in my view of the market, pay less, and well they should - it's a race to the bottom and the supply is plentiful.

ColdFusion is niche, and niche pays more. You want PHP/.NET developers to realize the power of CF, embrace it, see it as a viable language? Be careful what you wish for!

Is this really true?  Am I expected to pay more because you're a ColdFusion developer instead of a .NET developer?  Because guess what... I won't!  If you're unable to demonstrate a senior level skill level after a senior level detailed technical interview, and I mean TECHNICAL in the true sense of the word, then you will not be "paid more."  If you indicate that you use the createObject() function in ColdFusion and are therefore familiar with object oriented programming but you cannot define polymorphism, I'll recognize your potential to be trained but will NOT consider you a highly paid resource.  Screw "niche!"

In my entire career, and I am not exaggerating, I have accepted job offers and have been presented with job offers by people who haven't asked me one single technical question about my experience in ColdFusion.  I've been asked what versions I've used, what IDEs I've used, what size teams I've worked with, what frameworks I've used, but nothing to indicate whether or not I understand and use any of the intermediate or advanced ColdFusion functions or how I've used ColdFusion to solve advanced or complex business problems.

I have never been asked what the CFQUERYPARAM tag does.  I have never been asked how to prevent a race condition.  I have never been asked to define encapsulation.  I have never been asked how to roll back a SQL transaction in the event of an error.  And when we ask questions like that in the interviews we conduct, most applicants seem really taken aback.  And honestly, few do well under the pressure.

My point is that our community is full of bright developers with huge potential, but our community has some growing up to do.  Our small size shouldn't confuse us into thinking we should be paid more than our Java and .NET counterparts, however, many of whom perform exceptionally well with our team's interview style.  It's all about your skill.  Period.

The blog post right here from Micky is what makes me love working with these guys. I was initially disappointed by the reaction to this TechCrunch article, but the disappointment blew over quickly and we all moved on.  But Micky just read it thoroughly and has a lot to say on the topic.

Micky nails it.  I won't bother rehashing it here.  Go there and check it out!

It may not matter to most, but I'm definitely not down with the whole Hal Helms leaves the ColdFusion Community thing.  The very notion that a community has high profile members who have to spend time soul-searching before making an announcement that they won't be using ColdFusion going forward troubles me.  Have we as a community enabled these people to believe their decisions will impact our own use of a software platform?  Have we put these people on too high of a pedestal, making them believe they have to take a deep breath before making a grand statement about trying other platforms?

In the ColdFusion community, a lot of time and effort has gone into the best ways to write ColdFusion based applications.  Should we use this framework over this other framework?  Is ColdFusion best used without applying Object Oriented principles, or should developers apply strict OOP in their designs?  If Hal Helms says Ruby on Rails is better than ColdFusion, does that mean I should start studying it?

Over the past several months, I've learned that what's important to be thinking about as a professional ColdFusion developer is not about OOP versus Procedural or Framework A over Framework B.  Rather, the best way to get yourself going down the right path is to think about how to write good software -- simple as that.  One of the ways to do that is to remove yourself from ColdFusion for a while and discover what else is out there.  Most of my studying of Object Oriented Programming has been with a C# book.  This forces me to set aside what I know about CF and focus on the concepts rather than the syntax.  I can then take what I learn and apply it to CF.  If CF doesn't support it, I know what to ask Adobe for.  And guess what... Adobe is listening!

My programming mentors are Brian and Micky.  These guys are well versed in other languages, but they are passionate about and prefer ColdFusion.  I wish our community consisted of more people like them.  They don't think in strictly absolutes.  And after 11 years of programming in CF, these guys enabled me to bring "joy" back to ColdFusion programming.

Good luck, Hal Helms.  You'll be missed.  But I've got new mentors now.