Re: How to speed up Clojure Training for New Recruitment

2012-06-20 Thread Julian
Thanks Jay, 

Those articles are indeed inspirational. I was just wondering - back from 
your TW days - would the arguments in those articles make sense for a TW 
consultant to present to a client?

Cheers, Julian

On Tuesday, 19 June 2012 01:22:34 UTC+10, Jay Fields wrote:


 learning curve, and training time be reduced for new recruits ? Also how 
 do you pitch it to the management ? 
  
 I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even 
 suggest they read it. http://www.paulgraham.com/avg.html 
 Related: http://www.paulgraham.com/icad.html

 Cheers, Jay


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-20 Thread Jay Fields
That's a complicated question. I think consultants* are incentivized
to present new technologies to clients and convince them it's the
right choice.** However, I don't think it ends up being the right
choice for the company on most occasions. I wish that weren't true,
but I believe that's the most common case.

If a client is already using Clojure, and wants to bring a consultancy
in, that's great for the consultancy. However, if a (traditionally
Java) client wants to bring in a consultancy, they are not likely to
be able to support any application written in Clojure. There will
definitely be exceptions; however, I think the general rule holds.

Adopting a language is tough and requires deep organizational
commitment. If a client is willing to make that commitment, great! If
not, you're likely going to fail - sooner or later. The most
interesting technical project I ever worked on was 75% abandoned when
our team left, as the in house devs were not able to support it. Part
of that was due to the way the client structured the contract;
however, the technology choice also contributed to that outcome.

I do believe that Clojure provides an advantage. I use it every day,
partly for that reason. However, you need the people around that can
support it, or it needs to be 'complete' - meaning zero maintenance. A
good example could be building a prototype.

* my statements are generalized to all consultancies, none of my
comments reflect opinions that only apply TW.
** given current consulting models. It doesn't have to be this way.

On Wed, Jun 20, 2012 at 7:53 AM, Jay Fields j...@jayfields.com wrote:
 That's a complicated question. I think consultants* are incentivized to
 present new technologies to clients and convince them it's the right
 choice.** However, I don't think it ends up being the right choice for the
 company on most occasions. I wish that weren't true, but I believe that's
 the most common case.

 If a client is already using Clojure, and wants to bring a consultancy in,
 that's great for the consultancy. However, if a (traditionally Java) client
 wants to bring in a consultancy, they are not likely to be able to support
 any application written in Clojure. There will definitely be exceptions;
 however, I think the general rule holds.

 Adopting a language is tough and requires deep organizational commitment. If
 a client is willing to make that commitment, great! If not, you're likely
 going to fail - sooner or later. The most interesting technical project I
 ever worked on was 75% abandoned when our team left, as the in house devs
 were not able to support it. Part of that was due to the way the client
 structured the contract; however, the technology choice also contributed to
 that outcome.

 I do believe that Clojure provides an advantage. I use it every day, partly
 for that reason. However, you need the people around that can

 * my statements are generalized to all consultancies, none of my comments
 reflect opinions that only apply TW.
 ** given current consulting models. It doesn't have to be this way.


 On Jun 20, 2012, at 7:37 AM, Julian wrote:

 Thanks Jay,

 Those articles are indeed inspirational. I was just wondering - back from
 your TW days - would the arguments in those articles make sense for a TW
 consultant to present to a client?

 Cheers, Julian

 On Tuesday, 19 June 2012 01:22:34 UTC+10, Jay Fields wrote:


 learning curve, and training time be reduced for new recruits ? Also how
 do you pitch it to the management ?

 I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even
 suggest they read it. http://www.paulgraham.com/avg.html
 Related: http://www.paulgraham.com/icad.html

 Cheers, Jay


 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: How to speed up Clojure Training for New Recruitment

2012-06-20 Thread Andy Coolware
 Oh, and I also believe training is mostly a waste of resources. Training is 
 pushing information.

It really depends how it is constructed. If it is a domain knowledge -
this is just a info push. If this is a skill to be acquired -  I have
seen many hands on dedicated labs very effective.

Now in terms of Clojure - training seem to be a bad word. It is more
an exercise and practice what is needed. Like getting a black belt.
I say give them koans and 4clojure problems to solve (individually),
week of time  and this will lay out a good foundation. Speaking from
own experience - a month ago I did not know what Clojure is - now I am
fairly fluent at basic level.

A.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Murtaza Husain
Hi,

Just wanted to get pointers on how do you manage the training of recruits. 
It is difficult to find clojure talent, and we are located in India, where 
it is close to impossible. Also the non availability of talent becomes a 
hard sell to management too while introducing clojure projects. How can the 
learning curve, and training time be reduced for new recruits ? Also how do 
you pitch it to the management ? 

Thanks,
Murtaza

 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Chris Ford
When it comes to new graduates, they'll probably latch onto Clojure just as
quickly as to Java or anything else.

At EuroClojure, Jon Pither and Hakan Raberg mentioned that in their mixed
Java/Clojure ecosystem they train new hires on Clojure, which eventually
makes them better Java programmers!

Cheers,

Chris

On 18 June 2012 08:11, Murtaza Husain murtaza.hus...@sevenolives.comwrote:

 Hi,

 Just wanted to get pointers on how do you manage the training of recruits.
 It is difficult to find clojure talent, and we are located in India, where
 it is close to impossible. Also the non availability of talent becomes a
 hard sell to management too while introducing clojure projects. How can the
 learning curve, and training time be reduced for new recruits ? Also how do
 you pitch it to the management ?

 Thanks,
 Murtaza



 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Bill Caputo

On Jun 18, 2012, at 2:11 AM, Murtaza Husain wrote:

 Hi,
 
 Just wanted to get pointers on how do you manage the training of recruits. It 
 is difficult to find clojure talent,

I don't hire based on knowledge, I hire based on ability/desire to *learn*. For 
senior people I also want the same ability/desire to share what they've learned 
with others.

 How can the learning curve, and training time be reduced for new recruits ?

Put them on teams full of people who like to learn and to teach and tell them 
their 1st job is to learn, not to ship code so get cracking. Oh, and I also 
believe training is mostly a waste of resources. Training is pushing 
information. Learning is a self-directed activity. I look for people who would 
be bored stiff in training (a good sign is if they work ahead of the trainer 
and otherwise break the class).

 Also how do you pitch it to the management ? 

Point out how well the other ways have been working out for the industry.

bill

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Murtaza Husain

Bill that is very interesting. So how do you make them learn. Do you pair 
them up with someone who knows on some task? I mean how do you structure 
learning ? Bcoz as you mentioned that put them into a team where everyone 
likes to share, however everyone may be working on things above them, and 
they may not be able to grasp, and they may also not have time.


On Monday, June 18, 2012 5:01:45 PM UTC+5:30, Bill Caputo wrote:


 On Jun 18, 2012, at 2:11 AM, Murtaza Husain wrote: 

  Hi, 
  
  Just wanted to get pointers on how do you manage the training of 
 recruits. It is difficult to find clojure talent, 

 I don't hire based on knowledge, I hire based on ability/desire to 
 *learn*. For senior people I also want the same ability/desire to share 
 what they've learned with others. 

  How can the learning curve, and training time be reduced for new 
 recruits ? 

 Put them on teams full of people who like to learn and to teach and tell 
 them their 1st job is to learn, not to ship code so get cracking. Oh, and I 
 also believe training is mostly a waste of resources. Training is pushing 
 information. Learning is a self-directed activity. I look for people who 
 would be bored stiff in training (a good sign is if they work ahead of the 
 trainer and otherwise break the class). 

  Also how do you pitch it to the management ? 

 Point out how well the other ways have been working out for the industry. 

 bill

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Bill Caputo

On Jun 18, 2012, at 6:37 AM, Murtaza Husain wrote:

 Bill that is very interesting. So how do you make them learn.

Haha, I don't make anyone do *anything* on my team (I'm not exaggerating). My 
first (and more or less last) directive as team-lead is to declare it a team of 
peers. We ask people to join us who want to do what's needed for us to succeed. 
At most we will explain that the team uses clojure (and javascript and ruby, 
and something new when we need it) and if they aren't *eager* to learn new 
things to solve problems (and that's obvious in about 30 seconds of 
interviewing), there's no point in wasting our time.

 Do you pair them up with someone who knows on some task? I mean how do you 
 structure learning ?

If this stuff was reducible to rules, you wouldn't need learners, you could do 
the whole training bit - maybe even write a program to write code for you. Hire 
people who like to learn, put them on the team. That's it. The team figures it 
out from there (i.e. different in each case, based on personalities, languages, 
tasks, goals, current deadlines, etc.)

 Bcoz as you mentioned that put them into a team where everyone likes to 
 share, however everyone may be working on things above them,

If getting this person up to speed is important for team's success, there is 
nothing above them... there is only velocity. If velocity is more important 
than learning, the ramp-up time will be longer... if the wider organization 
values speed over competence, you'll get shitty code (that's not a learning 
clojure issue).

 and they may not be able to grasp, and they may also not have time.

If either of these are true - and we made the mistake of asking them to join 
our team - they wouldn't be around long enough for it to matter.

bill


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Murtaza Husain


Thanks Bill !!

On Monday, June 18, 2012 5:19:06 PM UTC+5:30, Bill Caputo wrote:


 On Jun 18, 2012, at 6:37 AM, Murtaza Husain wrote: 

  Bill that is very interesting. So how do you make them learn. 

 Haha, I don't make anyone do *anything* on my team (I'm not exaggerating). 
 My first (and more or less last) directive as team-lead is to declare it a 
 team of peers. We ask people to join us who want to do what's needed for us 
 to succeed. At most we will explain that the team uses clojure (and 
 javascript and ruby, and something new when we need it) and if they aren't 
 *eager* to learn new things to solve problems (and that's obvious in about 
 30 seconds of interviewing), there's no point in wasting our time. 

  Do you pair them up with someone who knows on some task? I mean how do 
 you structure learning ? 

 If this stuff was reducible to rules, you wouldn't need learners, you 
 could do the whole training bit - maybe even write a program to write code 
 for you. Hire people who like to learn, put them on the team. That's it. 
 The team figures it out from there (i.e. different in each case, based on 
 personalities, languages, tasks, goals, current deadlines, etc.) 

  Bcoz as you mentioned that put them into a team where everyone likes to 
 share, however everyone may be working on things above them, 

 If getting this person up to speed is important for team's success, there 
 is nothing above them... there is only velocity. If velocity is more 
 important than learning, the ramp-up time will be longer... if the wider 
 organization values speed over competence, you'll get shitty code (that's 
 not a learning clojure issue). 

  and they may not be able to grasp, and they may also not have time. 

 If either of these are true - and we made the mistake of asking them to 
 join our team - they wouldn't be around long enough for it to matter. 

 bill 




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Jay Fields
On Mon, Jun 18, 2012 at 3:11 AM, Murtaza Husain 
murtaza.hus...@sevenolives.com wrote:

 Hi,

 Just wanted to get pointers on how do you manage the training of recruits.
 It is difficult to find clojure talent, and we are located in India, where
 it is close to impossible. Also the non availability of talent becomes a
 hard sell to management too while introducing clojure projects. How can the
 learning curve, and training time be reduced for new recruits ? Also how do
 you pitch it to the management ?


I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even
suggest they read it. http://www.paulgraham.com/avg.html
Related: http://www.paulgraham.com/icad.html

As far as actually finding people, I'd look in the Ruby community. Many of
those people are fine with functional style and not too attached to a
specific language. And, do what Bill recommended.

Cheers, Jay

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to speed up Clojure Training for New Recruitment

2012-06-18 Thread Devin Walters
Start a meetup group. The people who show up more than a few times with no up 
front promise of a job opportunity will likely be the kind of people you want 
to hire. (Don't tell recruiters that though, please.) In addition, it gives you 
an opportunity to talk to potential hires in a relaxed setting without a lot of 
the BS that normally goes along with a formal recruiting process. 

Cheers,
'(Devin Walters)


On Monday, June 18, 2012 at 10:22 AM, Jay Fields wrote:

 
 
 On Mon, Jun 18, 2012 at 3:11 AM, Murtaza Husain 
 murtaza.hus...@sevenolives.com (mailto:murtaza.hus...@sevenolives.com) 
 wrote:
  Hi,
  
  Just wanted to get pointers on how do you manage the training of recruits. 
  It is difficult to find clojure talent, and we are located in India, where 
  it is close to impossible. Also the non availability of talent becomes a 
  hard sell to management too while introducing clojure projects. How can the 
  learning curve, and training time be reduced for new recruits ? Also how do 
  you pitch it to the management ? 
  
 I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even 
 suggest they read it. http://www.paulgraham.com/avg.html 
 Related: http://www.paulgraham.com/icad.html
 
 As far as actually finding people, I'd look in the Ruby community. Many of 
 those people are fine with functional style and not too attached to a 
 specific language. And, do what Bill recommended. 
 
 Cheers, Jay 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com 
 (mailto:clojure@googlegroups.com)
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com 
 (mailto:clojure+unsubscr...@googlegroups.com)
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en