"Lucky you!"?

I'm sure some of you reading this blog share my fortune in that you are getting paid to code declaratively. I also know others of you are stuck in that ghetto of churning out web-pages from JSPs or VB.NET or Oracle Forms and are wondering how to break into that fairy-tale world where you can use a sentence with the word "λ-term" in it and not have it confused with a Revenge of the Nerds reference.

Yes, Virginia, there are actually jobs/contracts out there that pay real money for you to code declaratively. In fact, if you're in the United States or Australia, then there are "lots" of these jobs, and, if you're in Europe or Asia, there are some jobs in your country or in a country near you.

So, here you are, and you're missing the key ingredients that will secure you one of these plum assignments: professional work experience in your LoCh ("Language of Choice") 'cause your stuck writing VB scripts, not (e.g.) Haskell, and phone calls from recruiters or companies wanting (e.g.) Haskell programmers 'cause you don't have (e.g.) Haskell on your resumé (because you never, ever lie on your resumé) and 'cause no recruiter nor company will ever admit they need something other than a programmer with Java or C# experience if they are hunting.

Real life story: a recruiter solicited me with no idea that I had Prolog experience for a Prolog req. because she was so used to seeking Java programmers, and all her other contracts needed Java programmers, that the thought never occurred to her. Only my "and, yeah, I also have experience in Mercury, which is like Prolog, and Dylan, which is like Lisp" woke her up to that nagging req. that she thought she was never going fill.

So, for all of you out there thinking about looking, you probably need a couple of questions answered. Like: how do you prepare for these jobs, and then, how do you find them? Well, I'm not going to give advice here on what should work, I'm going to tell you what worked for me. But since my experience may be atypical, maybe some of the readership that do have functional or logical programming jobs can chime in with your own stories that show easier routes to success.

Here's how I didn't get my paying jobs coding in Dylan and Mercury and Prolog and Haskell (yes, my current job is accepting some code in Haskell and they are building a foreign interface to Haskell in their Prolog engine. Win!):

• I neither lied on nor fudged my resumé.
  
  Some people think that reading a book on Hibernate allows them to enter a bullet on their resumé as on-the-job work experience. Those kind of antics may get one in the door, but the thing that keeps one on the payroll is "am I confident and competent building systems with this technology?" ("did I really do this?"), not "can I learn the technology I listed on my resume on the new job?" ("do I think I can do this?")



• I didn't get my job from any of the companies listed on haskell.org or schemers.org or <anything>.org.
  
  Why? Because these listings are usually from somebody who got to write a code snippet or a pet project in their favorite language under the radar and are crowing about it on their-favorite-language.org website. Sure it's wonderful that XYZ corp is using Haskell, but does the HR department know about it? No. Is is in their budget to hire a Haskell programmer? No. You don't need to believe me on this one, however. You can send an email to every single one of those companies, just like I did, and get the null-responses and the "this email address does not exist" bounces, just like I did. Knock yourself out.



• I also didn't get a job or contract working for the luminous companies in the declarative world.
  
  Don't know why here, but I can guess. It may be that Galois or Jane's Capital or Ericsson or whatever gets a few solicitations a quarter, and they are already up to their gills in talent. If they already have all the work they want in that domain, and they have already some people with some time on their hands, they aren't going to hire a new person, and give that person nothing for their job, just because that new person is so excited about the opportunity to code declaratively.
  
  And the larger the company, the harder it is to thread one's way through the layers of bureaucracy to reach the isolated island that uses your LoCh. Sure, IBM (Tivoli) and Microsoft (Windows Registry) use Prolog, but good luck finding a person to speak about that in those empires. And since your LoCh is so niche in those empire, good luck finding an opening.

So, I guess it was pure-D-luck that I was on four contracts where I used Dylan, and one contract where I used Smalltalk, and one contract where I used Mercury, and two contracts where I used Prolog, and one contract (so far) that I'm using Haskell.

... or maybe not.

So, how did I get to use these languages that I (have) love(d) on these contracts?

1. First and foremost, by being the best d*mned Java or C++ programmer their management had ever seen. In 1996, I took three Java books on my honeymoon, and read them. (Yes, Virginia, 12 years later, we are still married.) Every single night after work on my C++ contracts, I would read something from Design Patterns and Stroustrup. Work assignment scoped to two months, end-to-end, I would complete in two weeks.
   
   What did that give me? Trust, latitude, tolerance and time. Management knew they didn't need to look over my shoulder and they would allow me to do the jobs my way. It then was a very simple step from writing each web-page as its own JSP to writing a Dylan program that generated 100s of JSPs from templates. Then I would show management the Dylan program. ("This, boss, is how I've been so efficient").
   
   Most of the time it worked ("That's awesome, Doug." "Would you be willing to be a reference for me?" "Sure."), sometimes it didn't ("How are we going to maintain this when you're gone? Rewrite it in Java." "Yes, ma'am."). Where it worked, I added it to my resumé; where it didn't, I didn't.



2. Next, I was the best salesman in the organization, better, even than the PR department. At socials with the customer, all the programmers would line up against the far wall ('cause programmers are shy, don't you know), except me. I would cross the room and walk right up to the customer with a ready handshake ("Larry, hi; I'm Doug Auclair, and I'm working on solving your problems"), this also applied to internal customers ("Paul, nice to meet you; I'm glad the VP of ITT is checking out this satellite program").
   
   What did this get me? Call backs and word-of-mouth that allowed me to set the terms of the contract ("Hi, Doug, this is Bruce at Raytheon, we need somebody good on this new contract, so we called you." "Sure, Bruce, this is my rate." "That won't be a problem").
   
   If you want what you want, you must be good where you are and you cannot be a wall-flower. People with the power to decide must think of you first because a) you've excelled in your current work and b) you've told them so.



3. Next, I always had my eyes and ears open and, when I was good, I opened my mouth only after someone had gotten their gripe off their chest. You know what a gripe is? To me, a gripe is a contract. "!@#$%^*, we need a phoneme-based name-matcher but the programmer who built it in assembler retired years ago!" (Trans: Doug, we need you to write a fuzzy ILP system in Mercury) "I sure wish we could use the function object templates you've written about in the C++ system I'm building." (Trans: Doug, come on board to show me how Dylan will make this a whole bunch easier.) "We want your system to extract meaning from text documents, but extracting meaning from the images is too hard; don't bother with that." (Trans: Tell us about image processing and classification with Self-Organizing Maps and Pulse Coupled Neural Networks.). Each of the above gripes led to work, that is authorization and funding, for me to write in my LoCh (Mercury, Dylan, and Haskell) that was outside the, erhm, comfort-language of providing company.
   
   How did I have the confidence to offer those suggested courses of action and then have the competence to build them to delivery? Listening is key. Nobody listens in our industry, so when somebody does listen, the griper is so relieved that somebody cared that they weigh the response with much greater significance. That I had these novel, but workable, courses of action to offer comes from what I did in the next, final, point.



4. Finally, I became a teacher. Being a teacher, a real teacher, means first you are a learner and learn more than anyone you know about the topic, and second you are a doer and are better at using the technology to solve the given problems than anyone else on the team. Those two things are prerequisites to being a teacher, but they don't make you a teacher. No, to be a teacher, you must write, write, and then write some more about the topic: documentation (users manuals and programmer manuals), white papers, articles, quizzes, aphorisms. Then after the writing comes the lecturing: I spent years developing and then teaching continuing education courses at the local community college after I gave brown bag lunch lectures at my place of work. I got two of my better contracts from company owners tripping over my written materials: a Dylan project and a Prolog-based agent project.
   
   By the way, teaching is not droning on for an hour or for four hours. Teaching is preparation, to the tune of 13 hours of prep work for each hour in front of the class (I did). Teaching is getting up on top of the desk to do flamenco (I did), teaching is jumping up and down, up and down, jackhammer-style to drill in the point (I did), teaching is having the students wonder what I was on and could they get a prescription ("Class, this is Doug without coffee!"). Teaching is inspiration; it is the flame to ignite the students' imagination.
   
   I had something like 3,000 students under my tutelage from the brown bags and my continuing education courses (that I was paid to teach), from coders to company presidents ... do you think I have a problem with my contact network?
   
   Oh, but that's easy for an extrovert like you, Doug! But I'm naturally shy. Dude, don't give me that line! On Myers-Briggs, I'm either INFJ or INTJ, my "I" (introversion) is so extreme that it actually blows the percentile curve. I HATE interacting with people, so much so that it takes an additional 8 hours for me to recover from a meeting or class that I run (and since I'm president of my independent consulting firm, I run all the meetings and teach all the classes), but I LOVE coding declaratively more. Once you know what you must have, you'll find a way to get it. The excuses you used to make for not getting what you must have become just that, excuses; when you have that burn, that's when you start finding ways to the desired end.

Well, unlike Java jobs or C# jobs or VB jobs, where one can scan the newspaper or go to dice.com, these magical jobs are not the ones I get when recruiters solicit me (three times a day). No, they appear between the cracks of the sky when it rends in two. All but one contract (that did come from dice.com) came from the company CEO pulling me aside or phoning me out of the blue from the materials I had published inside the company where I was employed, or from my web-sites on programming languages.

Usually and because of the exclusivity of the work it takes anywhere from at least 3 months to 2 years to secure these kinds of contracts, so the adage "Don't quit your day job" is an appropriate one here. When I do get these contracts, however, they usually last longer (3 years) than the Java/C++/XML/web-services-code-grinder ones (that usually last around 6 months), and the peer group is much more intelligent, genteel and just plain more interesting than the code-grinding crowd. Is is harder to find these magical contracts? Yes, they are rarified air. But are they worth preparing for and then finding? Definitely.

So, yes, I was lucky to work on 7 paying contracts using declarative languages, because I was the best code-grinder on my current job, I used my LoCh effectively and then wrote about the successes and taught techniques to my peers, all of which luckily attracted the notice of hungry companies needing a competitive advantage.

Luck, you see, is when preparedness meets opportunity.