Posted in ColdFusion | Posted on 05-17-2011 | 4,572 views
Nicci wrote to me last night with the following question:
I was recently approached by an IT recruiter friend of mine regarding a position looking for an expert-level Coldfusion developer.I have been working with CF for about 5 years and in no way consider myself expert-level, but my question is this; with "expert-level" obviously being a very subjective phrase, what would you expect from an expert-level CF developer?
Just hoping to get a feel for the expectation, within the community.
I love easy to answer questions like this! The answer is "It Depends." Thanks, and good night.
- While not necessarily an Expert quality, the number one thing I look for in a developer is what they do when they are stuck. This could be as simple as not knowing what the syntax is for a particular tag. I do not believe that an Expert has to memorize all arguments to every tag/function in the language. I do expect that they know where to find them. The answer is - obviously - the docs (or the built in help in your IDE), but an expert is going to have these references ready at all times. I'd expect an Expert to know that ColdFusion has Exchange functionality. I'd not expect them to rattle off the syntax off the top of their head.
- Conversely, while I expect everyone to know how to work with the basic docs, I'd go on to say an expert knows where to dig when something goes wrong. Given a typical bug report ("It's just not working!"), an Expert understands how ColdFusion applications "flow" and would be able to trace a process to find out where the issue is. This could be as simple as recognizing that the error occurs after a CFC is called and the result was something unexpected and not handled by a CFM. This could be as complex as a MVC framework that expected a particular model call to run before another and is misconfigured order-wise.
- Going deeper, an Expert should have some understanding of the guts of the low level operations of ColdFusion. Notice I said "some understanding" - I know enough about JVM tuning to know what I don't know. But I know at least to look in that area if I see performance issues or out of memory errors. An Expert knows where to find the logs. How to use them to help diagnose issues. I'd also say that an Expert should at least have some familiarity with either FusionReactor, SeeFusion, or the built in ColdFusion Server Monitor.
- An Expert has a basic idea of what code is going to perform poorly. I'm not talking about knowing that compareNoCase is better than eq (and I'm not saying it is - but I've seen folks make those types of comparisons), but being able to look at code and recognize inefficiencies in the design. For example, I've seen code that recreates large CFCs on every request. An Expert should recognize that the CFC could be created one time and stored in the application scope.
I think there's one common theme to everything listed above: Understanding how ColdFusion works and having a tool set ready for when things don't work. This is less "I can do everything" and more "I know where to turn to." Speaking for myself (and I know some people think I've got a big enough ego already, but let's just assume for today I'm an expert ;) I know who to turn to for issues. Mike Brunt for performance. Pete and Jason for security. Shannon Hicks for Solr. Etc. If a client came to me for a problem in those areas and I couldn't answer them directly, I think it's valuable that I know who to turn to. I'd think that would be valuable in any employee.
I'll make one last point. The question here specifically relates to what defines an Expert programmer. I tried to answer that. (Although I hope my readers can flesh it out a lot more.) I think it's an entirely different question to ask about hiring an Expert programmer for your organization. In other words, how to get that great person in your organization as opposed to just hiring the hot shot Ninja for a week of consulting. For that I'll leave you with an article written by Hal Helms: Hiring and Cultivating Great Developers
Again glad you said an expert is not someone who memorizes stuff.
Also, glad you gave an opinion on this...I hope others especially others that are company owners, managers, etc chime in. It would be great to keep this around to pass on to managers in the future for a hiring guide.
thanks for the question, and the answer(s)
And as you say, they need to know enough about the tools to set the vision for what they can do with them. Just knowing the 3rd parameter of the CachePut() function does not make a great developer, but knowing that CachePut() exists and what you can do with it goes a long way to becoming an expert.
@ChrisB: Did you mean certification?
@Roger: Good point. How you would write a job 'ad' is different than how you would actually go about examining the candidate.
Less experienced CF programmers, on the other hand, especially if they started in another language before CF, are often heard commenting, "Oh, really, I could do that directly in CF? That's native?"
Wow - that is WAY badly written - but I hope you get my point. What's the quote - 'real developers ship'? Sometimes you have to make decisions to get things done even if it means the code is not as architected as you would like.
I second this, with emphasis.
In the past, CFC creation was a bit slow in CF. So if you didn't need to recreate the CFC on each request (ie, it was a collection of methods that had no state info), then you would make it once and not recreate it. CFC creation is MUCH faster now. That being said - it's silly to recreate a CFC on every request when you don't need to. The generally accepted best practice is to create them one time (either via simple creation in onApplicationStart or via a framework like ColdSpring).
We see a lot of CFers who have been using CF 10-15 years but would certainly not be considered experts by any of the criteria discussed here.
It's probably true of developers in other technologies too but I suspect it's true more often in our community because CF makes things so easy that developers often don't need to learn much in order to be successful - and then have no real incentive to grow their skills.
I also think a lot of recruiters inflate the true skills required on many job ads because, let's face it, you won't get many people applying for "average CF developers wanted to do maintenance on a giant legacy / spaghetti app" which is often closer to the truth.
All that said, I agree with pretty much every point Ray makes: knowing how to find stuff out is more important (than just knowing stuff), an ability to debug problems (which seems a horribly rare skill these days!), understanding the Java stack on which we live, an instinctive feel for performance and/or architecture. Those are what makes an expert. Most of it only comes with experience but not all experience is created equal...
I can tell you this much - the day I believe I am an expert programmer in any language will be the day I change my career choice. The more I learn, the more I realize I don't know - that is what keeps my fires lit. Good post Raymond!
However, when confronted, they either say one of two things:
"Yeah, you're totally right. I didn't have enough time to give it the attention it needed."
or
"Yeah, you're totally right, I hated having to do that way, because I knew X was going to cause Y, but I would have to have rebuilt Z first..."
Guess which one of the two just quietly realized you found a glaring misstep in their bad code?
I'll give you a hint: It wasn't the person who knew *why* he was making a bad choice.
In my experience, that is often the determining factor between a hobbyist and an expert.
What is this exchange functionality?
http://www.adobe.com/devnet/coldfusion/articles/cf...
Expertise is often thought of as knowledge, but it's really about skill and judgement gained from trying stuff out and learning from successes and (more importantly) failures.
Sorry for feeding the off-topic part of this, but the differing of opinion here might feed back into the "what is an expert" discussion.
I'm wholeheartedly against putting CFCs into the Application scope. It might save a few milliseconds, but you then open yourself to a bunch of concurrency issues. The content of all unscoped variables are now shared with every visitor to the site. You've got to worry about how you're creating and destroying structs, arrays, etc inside the cfc. This is asking for a lot of diligence from your developers.
Additionally there's the issue of refreshing the CFCs when code changes happen.
Most of our pages over many websites complete in 35-75ms so we don't miss the few ms consumed by re-initing the CFCs.
And for those interested we use cfcs as singletons where everything is var scoped except for init config stuff and request scoped caching. Which is probably the best case scenario *for* putting the CFCs into the Application scope.
Seriously though - let me start a new blog post on this today. Cool? I'll quote you and explain why I think you are wrong - and you can then reply (as can others of course).
The *only* types of CFCs that are appropriate to be placed in the application scope would be "singletons" with every variable var scoped. "Beans" or other similar types of instantiated object classes would clearly not work in application scope, and I'm certain that was not Ray's intention to suggest. In fact, I think the ability to make that distinction would be key in determining whether or not a developer candidate even understands what he's modelling ...
Yep, I'm happy for you to use me for your punching bag, but please remember your own advice: http://www.coldfusionjedi.com/index.cfm/2011/2/2/W...
@Jason
If you want to be 'pure' then singletons are the only type that work. However, there is a lot of impure code out there. And it's the lack of explicit "there are exceptions to this rule, don't follow this advice unless you understand why there are exceptions" that niggles me. Hopefully we can touch on this more in the new post.
That's not the case. We know that. And most of the time folks like Sean and myself try to be careful to say that.
However - at the end of the day - it really is the responsibility of the noobs to get to a level of maturity where they realize that you can't apply X to every single situation.
It's like listening to a politician answering a question. They spend 45% answering and 55% ensuring they can waffle. Sometimes an answer should be just that - an answer. ;)
Expert
Critical knowledge of multiple IT environments/languages required due to the complex interfaces of various systems/languages.
No technical direction is required to complete tasks.
Advanced
Advanced knowledge of multiple IT environments/languages is required due to the complex interfaces of various systems.
Requires minimal technical direction to complete tasks.
Career Minded
Basic knowledge of IT systems/languages. Technical direction is required.
Beginner
Basic knowledge of IT systems/languages. Technical direction and mentoring are required.
What I find amusing are job posts that ask for the expert super programmer that expect to pay little. When seeing posts for expert super programmer, I would advise candidates not to worry too much about checking off all the boxes as long as they have some of the key transferable skills to get the job done.
Nicci, don't hesitate to find out more about the job if you are interested. Don't get hung up on titles. Too often the person who posted the ad is not clued in to what is really needed. 5 years, unless you have learned little in that time, is good enough to at least ask for more info about the job. 'Expert' is in the eye of the beholder.
[Add Comment] [Subscribe to Comments]