[racket] Racket consultants

This is just a message to see who Racket-consulting-inclined is 
currently out there and would like to compare notes.

To start, here are some frank thoughts based on my experiences 
consulting using Racket thus far.  Pardon the run-on sentences in quick 
brain dump.

I have been working as a consultant primarily using Racket and PLT 
Scheme for several years (except for a break for a scientist term 
appointment).

There is some work for people who can sling Racket.  Not a lot so far, 
but some.  The good clients I acquire, I try to bend over backwards to 
keep happy, out of natural professionalism, and also because good 
clients are precious.

The majority of Racket projects are secretive.  There is little upside 
to advertising that you're using a not-currently-mainstream platform, 
even if your business itself is not secret.  For now, "The first rule of 
Racket Club is: don't talk about Racket Club."

Thus far, the consulting work usually requires a lot of other skills, 
other than just being good with Racket.  Sometimes the client wants 
someone who both knows Racket and is a top-flight "programmer" in 
general.  Other times, they seemingly want someone who is expert at many 
related disciplines, including doing Racket well.  There's also 
sometimes a need for application domain knowledge (e.g., from one of the 
sciences or engineering disciplines), which sometimes I have had, and 
sometimes I have not.

Industry and government clients seem to generally be a better match than 
academia for consulting.  Academic researchers usually seem to be 
looking for grad students and the occasional staff Research Programmer 
(who I think is often easiest to hire from among known-quantity, 
indoctrinated recent alumni).  Also, people fresh out of undergrad 
(noteworthy exceptions who helped develop the high-quality Racket 
platform aside) often don't yet have much experience collaborating nor 
producing maintainable software, which is a problem when the task is to 
produce production-quality software together.  In industry, new grads 
would be mentored more on their first substantial projects, rather than 
tending to be in charge or having produced a base of legacy code to 
inherit.  Also, academic compensation usually is not very livable 
long-term, unless you are getting the university lifestyle, which you 
won't get as an outside consultant.  When I've seen consulting for 
academic research work, it's been a former grad student employed 
nominally as a consultant by a tenured professor/scientist who has lots 
of funding, and they collaborate directly and co-author publications 
(like an unusually well-paying, part-time post-doc).  These comments are 
based mostly on having spent a lot of time around various universities 
in various capacities, not as much from first-hand consulting.

There's also potentially consulting for startups using Rackets.  
Compensation would probably have to be a mix of pay and equity, unless a 
VC is ready to spring for market rates.  You'd need a special VC to let 
you do something in Racket, rather than Java or whatever the VC heard 
Google/Facebook/Twitter is using.

I do think that there are some people using Racket in industry, who are 
not using consultants as much as might be to their advantage.  You get a 
lot of people who are doing pilot projects, usually quietly (say, the 
manager doesn't want some other manager to start complaining about them 
using anything other than PHP or COBOL or the like), and are trying to 
use internal resources rather than put in a PO for a high-priced 
consultant.  Doing it without consultants is certainly doable, thanks to 
Racket attracting smart developers, good documentation-- and to 
pseudonymous GMail accounts for posting to the great Racket "users" 
email list, where people can get good and prompt answers to generic 
technical questions.  However, the email list isn't under NDA, and can't 
review designs, do code reviews, answer questions that require 
examination of the application code, mentor much, give much proactive 
direction, design or implement particularly tricky bits, help plan 
infrastructure, answer questions that require hours of research, do 
emergency troubleshooting of a deployment, participate in requirements 
analysis, understand and influence the big picture, etc.  I see a role 
for consultants in this, which is essentially helping new Racket 
adopters get up to speed and be successful with their initial projects, 
at the same time helping them build internal expertise.

Once an organization has internal expertise in Racket, two thoughts: (1) 
Racket success stories should increase new adoptions, and therefore 
increase demand for consultants to help the new adopters get up to 
speed; and (2) Organizations that are successful with Racket will still 
need need consultants, because they don't always have enough top talent 
in-house for all their opportunities (and companies like outsourcing 
these days, anyway), for things like "we want you to make a tricky 
library to do X, which we can use as part of our Racket-based 
application" or "we want you to make a tricky application to do Y, 
preferably using Racket" (which can be some of the best kinds of 
consulting work to get).

Eventually, there might be a need for a consulting firm that focuses on 
work involving Racket.  I don't yet see enough demand that I'm ready to 
start having people's livelihoods dependent on business I can round up, 
nor to end up spending all my time on management and marketing.  But at 
some point I would consider transitioning from being someone who makes 
things work, to being someone who wears a suit and makes other people 
make things work. :)

Somewhat separate from consulting, now that some key libraries of mine 
are coming together, I'm about in a position in which I can very rapidly 
develop and deploy mini-startup Web sites using Racket, with each site 
bootstrapping its operational costs from the start by using cloud 
servers and ads.  Doing mini-startups as a background task seems 
complementary in several ways to consulting in Racket.

Notes-comparison is welcomed.  Feel free to email me privately.

Neil V.

-- 
http://www.neilvandyke.org/