This practice doesn't really have a name.  Which is crazy when you consider how many people actually participate in the activity.  I myself call it "the courtesy call".

The idea behind the courtesy call is simple.  You make a friend or colleague aware of some impending issue/action which might lead to a negative outcome for them or someone who works for them.  Normally, the call warns of unrest on a team or of rumors impacting them or their company, but can be of a more severe nature as well.  The intentions here are normally good ones and most who engage in the philosophy do so because they genuinely believe good will come out of it.  The hope then is that down the road, they'll do the same for you.

Until here recently, I happened to believe in this practice as well.  And if I made a courtesy call, it was based on fact, not rumor.  I've been fortunate to work with so many great people/companies through the years, and what I've learned is that EVERY organization has it's challenges.  As a software engineer, the work is always hard, and even when management tries, the death march can not always be avoided.  Having served as management/architect in the past, there's no more painful experience than losing key, and good, people while in the death march.  Actually, the only thing worse, is surviving the death march, as a team, THEN losing them to other opportunities.  I have always viewed the courtesy call as a first warning in situations like this, and one that should be heeded.  If someone has the stones to give you a courtesy call, you should handle it with care.

So, how does a courtesy call happen?

Work in a market long enough, regardless of your profession, and you've probably experienced a version of "the reference check".  You're a developer/engineer who's worked with one or more staffing companies to help you get your current gig, and within days/weeks/months, your recruiter is calling to ask about a friend or colleague.  Most of the time, they only want a simple reference, but your curiosity gets the better of you.  Turns out, that colleague works for another friend or colleague.  Holy crap, I had no idea they were looking, what happened?  Really, things are that bad??  Many, many times, your colleague has no idea that you were asked to give a reference.  And yes, this happens way more than you might think.  

Now, what do you do with this information?  You know both people and know them to be good individuals.  If things are really as bad as they appear (and there's always an element of truth to what you're hearing), this could make a signifcant impact on both.  You've got a colleague looking for work because things are not good for them.  Could be work related, or worse, and normally the case, the work culture is creating way too much personal cost for them.  If you've ever been in a similar situation, you know how bad things can get at home.  It's my experience that many people would rather seek new employement than try and resolve an issue at work.  On the other hand, your other colleague (the manager in this scenario) is generaly the type who cares about their people.  Losing a truly valuable developer has a cost that can NOT be properly quantified, however, it goes far beyond the cost of placement.

Historically, I've chosen to make the courtesy call in this situation and provide a heads up to my colleagues.  The most amazing thing is that it's never really a surprise.  Managers almost always know there are issues on the team, and in many cases, even have the specifics.  Thanks to tools like Bullhorn managers are often in the know way before anyone else.  When I make this call, it's with the hope that concrete feedback, confirming their fears, is enough to help make change.  The kind of change that truly helps the whole team and especially those paying the highest personal cost.  These calls are always difficult.  No one wants to hear from a colleague outside their company about issues which may exist on their team(s).  Many times, there's even the demand for names, something I've RARELY complied with.  And by rarely, I mean a few times in the last ten years, and NEVER in a situation where I didn't truly believe a positive outcome was likely.  

Needless to say, there's a real high degree of trust regarding the courtesy call.  They only work if both parties trust one another and respect the anonymity of the information.  Essentially, a person can choose to do good with this information, or evil.  I've always chosen to believe that people opt for good.  I mean c'mon, who pisses in their own pool?  In order for me to make a courtesy call, I must first trust the other person's character.

Sadly though, I've received so much negative feedback on this practice, I'm choosing not to do them any longer.  I've heard too many stories about what "Potts said" having reached the people it was meant to help, and delivered in a way which indicates a violation of trust that was placed in me.  Then there are instances where my information was used to ferret out more information in a way that both violates trust and drags others down with them.  Worse, this information has been used to brow beat folks with some using it simply to demonstrate their omniscience.  In the end, I've seen more bad than good come from the information provided by these calls.  My belief in some has fallen so far in fact, I can no longer trust many I've referred to as a "colleague" in the past.  I refuse to believe evil was done intentionally, however, I also know people in dark places will sometimes make bad choices. 

It's taken me several weeks to come to grips with this issue.  I've always considered the courtesy call to be a vital part of being a good/concerned manager.  If you truly care about your people, and want them to be in a positive work environment, why wouldn't you do something good with this information?  The hardest thing for me to accept, and I'm still in denial on this, is that this behavior may be yet another sign of a real decline in the practice of management/management theory.  This is certainly fodder for another post, however, taken together with the cog/wheel substitution mindset regarding devs, I fear management science is truly in decline regarding our profession.

And while it appears some (very few in fact) have done good with the information provided, there seems to have been far greater done which is not so good. 

For any who've been penalized by one of my courtesy calls, I'd like to apologize.  I never intended for these calls to be used against those individuals they were supposed to help.  I could sit here and justify the calls, or split hairs on what information was really provided, but I'm guessing it won't really matter if you were "outed" as a result.

For those who've called me in the past, providing their own courtesy calls, I'll ask that you stop.  I don't want there to be any, implied or otherwise, expectations I'll return the favor.

From this point on, I will no longer make, or receive, courtesy calls.  Further, all reference checks must come from the candidate, not the recruiter.

I'll start by addressing an element of the profession that's building into a fascinating conversation, and that is the current "learn to code" craze on the internet.  I had planned to write this post last week, and in preparing the book list (more later), I put it off.  Fortunately, that delay allowed an interesting 'discussion' to develop between Jeff Atwood and Zed Shaw.  (Even better, their twitter conversation:))  At the heart of this conversation, I believe, are the feelings many have regarding barrier to entry in our field, and/or, what it means to "learn how to code".  Fundamentally, access to information has made it far easier to lean how to code, and this CAN BE a good thing.  Some, however, don't agree.  You can clearly see Jeff and Zed have polarized viewpoints on the topic.  Personally, I feel they're both right, to an extent.  

For me, the real issue isn't whether you learn to code or not, but what you do with that knowledge, and your reasons for learning.

I think it's great if you learn how to code.  I think it's great if you learn how to code because you're truly fascinated with the craft, the mindset or maybe even the sometimes severe nature of those in the craft (please refer to above disagreement:)).  I truly believe having more who understand the craft/process/profession/{choose dogmatic association} is a good thing.  A little uncomfortable sometimes? Yes, maybe.  I know I don't want someone creating churn on a project because they deployed their first ruby gem last weekend.  However, I've also seen relatively intelligent people finally make intuitive leaps in their jobs simply from understanding the difference between good data and bad.

Now, the flip side (and original reason I wrote MY post).  As a practicing software engineer, business owner and professional, I've worked with too many who believe it's okay to seek a life in the craft after deploying said ruby gem.  I'll immediately say, there's nothing wrong with that if, and a very BIG if, you also seek out the necessary guidance to help you progress in your shiny new life as a developer/programmer/engineer/{yep - another dogmatic association}.  I think it's fair also to point out, many organizations fail new professionals in exactly this manner.  Whether it's out of ignorance or neglect, it doesn't really matter, there are many underqualified people in our business today, going nowhere slow, holding keys to someone's version control repository.  

Maybe management should learn how to code.:)

I had an interesting first reaction to both articles.  And while I tend to fall victim to Zed's approach myself:), I must confess to a sudden pang of guilt for agreeing with Jeff.  As the resident old guy, I walked up plenty of "uphill both ways" coding exercises, white board conversations and book lists to get where I am today.  Who the hell does this kid think he is just downloading Eclipse, jQuery and Ruby??  Did he REALLY just skip 20 years of coding history???

And then, so what???

There are two points in Jeff's post which still ring true for me.  First, there is more to professional coding than code.  Second, there are many, many skills which make you a better professional, one of which is, when not to code.  My guys and I refer to this as an ethical issue.  Don't spend you're clients money just cause you "write the codez" (nod to Danan:)).  Something I say often, probably too often, 90% of our ability to succeed in this business occurs OFF the keyboard.

In reference to Zed's post, and as a professional, I'd like to think I'm ALREADY well read, working on being a better writer and currently building a software engineering company.  On top of which, I'm a husband, father of three and mentor to a few people, all of which I'm working hard to improve on.  If I want to learn Python, even the hard way, shouldn't it be easy to consume?  Personally, I'm grateful for the work done by many to reduce the friction that I AND my guys experience in learning language level material.  Given this is only 10% of the challenge, I want it to be an efficient 10%.

A distinction worth noting maybe, I see programming and software engineering as different things.  You may be a really good programmer in fact, but that does not qualify you as someone who can solve problems for others using your coding skills.

I can tell you, my personal reaction to the whole "just learn to code" craze has led me to ASSUME many feel this also means, "and you too can make 100K a year!!".  Yeah, that makes me angry.

And if those learning to code begin taking money from people for their new found skills, then I've got a problem with it.  To me, this leads back into an ethically grey area.  Too many out there don't understand the depths of our field (maybe they should learn to code:)) and are easily taken advantage of.  I've seen this happen way too often and it pisses me off everytime.

Interestlingly enough, two web pages keeping popping into my head as I write this.  First, the ACM's Code of Ethics.  This covers much of what I feel is our responsiblity as a profession.  Second, Norvig's post on being and expert (referenced by Atwood).

Now, to wrap this up, I've decided to throw my own opinion on the table.  As a professional, I believe that learning to code is step zero.  It certainly gets you into the conversation and opens the door in a meritocracy, however, I also believe there's a 'foundation' for professionals.  This is the book list I use for mentoring software engineers in the craft, and yes, I consider a large part of this list to be a 'bare minimum' for software engineers.  Please note, I have ONE language related book on this list.  Again, language competence is step zero as a professional.

And as a professional, please make no mistake about it, I believe you own this, with or without a mentor.  The only thing I hate more than unethical behvior is someone who blames the boss for their inadequicies.

Saying you can be a professional just because you learned to code, is like saying you can win the Daytona 500 because you drive to work everyday.  And to balance that point, just because I buy a sports car for the daily commute does not mean I WANT to win the Daytona 500.  Just means I like to drive.

I gotta say thank you to Jeff and Zed for sharing their passion on the topic, sure made me get off my ass and post:)