> People who have never returned an output parameter via
> a stored procedure.  To me this is really basic stuff.
> But some of these guys have years worth of
> experience based on their resumes.

You'd be surprised how many large and completely professional
companies never use stored procedures in their cf code. And in all
honesty not all of them really need them.

> This tells me these guys were dozing off for years in
> the corner of some office maintaining someone else's
> back-end CF code running on a single server, who relied
> on a dba to do all their DB design and procs.  Or they
> worked in a team and the others in the team did all the
> heavy lifting.

Neither of these are _necessarily_ true. I have worked in places where
there were no dba's and where all the cf developers either wrote
stored procedures or didn't. In most cases I've seen, whether or not
stored procedures are used depends almost entirely upon the lead
developer on the project -- if he likes them, he yells when he sees a
cfquery tag. If he doesn't like them, then he yells when he sees a
cfstoredproc tag. There are a handfull of lead developers or project
managers who are in-between or indiferent to stored procedures, but
most of the ones I've worked with seem to have been pretty firmly
entrenched on one side or the other of this imaginary fence they've
made, which has little to do with what kind of software they're
working on and whether or not stored procedures would be good for a
given environment, situation or circumstance.

> If someone got into that situation, fine. But have the
> initiative, have the curiosity, to spend some of that
> free time cracking open a CF or SQL book and filling in
> the gaps of your skillset for the next time you have to
> find a job.  You are NOT going to get the job based
> solely on your resume.  You are going to have to show
> that the time you spent at these jobs actually
> made you a good developer.

It's an unfortunate truth that most developers are simply in the job
to earn a living. They're 9-5'ers... Most companies don't pay for them
to be trained or to learn on the company's time, and they're not
willing or interested in learning on their own time. So by and large
the only time they learn something is when it's absolutely necessary
because they're staring down a deadline. I don't blame them, ya know,
I gotta eat too, and it's nice to be able to have some time away from
work or work related things, although I do wish more of them would
have more initiative to learn more about their jobs.

> It looks _really_ bad to me when I see that sort of
> thing. I expect more from these people.  I'd be more
> forgiving if they only had a few months of experience.
> A lot of these guys have plenty of other computer-related
> experience under their belt too, like Comp-Sci degrees,
> prior experience with other languages, most of which
> with higher learning curves than CF (like C++ or Java)
> so there really is no excuse for them not knowing the
> fundementals.

If they had degrees and held-down long-term jobs with C++ and Java
yes, I'd find a lack of knowldge of CF and database fundamentals quite
frustrating as an interviewer.

> Of course, the recruiters don't see this up front so
> they keep sending these guys over to waste our time.

Recruiters don't have the kind of understanding necessary to weed them
out... The only way you could hope for a recruiter to have this kind
of understanding is if the recruiter is also a CF developer competing
for the same job their clients want... which isn't very likely. :)

Though you left out a couple of my big issues -- I think everyone
should have a thorough understanding of how to write (and therefore
how to interpret) custom tags (attributes and end tags at minimum -
sub-tags is a plus) and functions. An understanding of CFC's is also a
big plus, but for the most part I wouldn't be terribly upset if
someone didn't have a deep or thorough understanding of them. At least
not yet... maybe in a few years if the CFC discovery process improves,
which unfortunately I don't see happening soon.

s. isaac dealey     954.927.5117
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to