Three tips for getting a job through a recruiter In response to a question on the Joel on Software discussion forum:

I have obtained just one job in my career through a recruiter. It worked out well for me. If my experience can help you, great.

This is about what works for me, not the great be-all and end-all of how you can live your life. Especially for this subject: we're talking about making money. I once took a year off work because I didn't think there was a good fit with the companies hiring at the time. I've been told that most people consider this a poor career choice.

I happen to hire through recruiters from time to time, so I can also give you some perspective from the client end.

Update: Just to clarify, these points are about my personal experience working with recruiters on full-time employment.

Double submission

...one staffing company tried to tell me that a second submission would "cancel out" the first and the hiring company would simply reject me as a candidate.

This is 100% true. It's absolutely bad to have two recruiters submit your resume to the same client. Speaking as a client, I round-file any resume received through two recruiters. This is because I do not want to end up fighting with them over who should get paid. And they will fight.

The trouble is, the recruiter thinks that they only have upside to submitting your resume, even if the client already has the resume, or you've worked there in the past, or another recruiter has already submitted it. They will tell you all kinds of stories, such as "if you haven't submitted it in the last ninety days I can resubmit it for you." The recruiter would rather have a slim chance of a fee than no chance, and if your resume gets tossed, well, better luck with the next company.

Never mind what the recruiter wants to do, follow these guidelines:

Always ask for the client name. Recruiters will often stall, claiming the client demands confidentiality. Simply say that you may already have contacts into the company and you wish to save them time and trouble. If they still refuse, ask them what else thay have for you. Never submit your resume blindly. Sadly, some recruiters will screw things up and submit you without permission. It's your loss when this happens. The best you can do is refuse to do any further business with them.

If you have had any contact with that company about getting a job, especially if the company has seen your resume, do not allow the recruiter to submit your resume. Period. You can only lose, you can never gain. For example, I have your resume. Now I see it from a recruiter. I could have hired you without paying a fee. Now your resume has a big fat "+20% in cash" sign on it. It goes to the bottom of the pile. I don't want to argue with the recruiter if there's someone else who is "clean."

Of course, if you're the right person you get the job and I'll tough it out with the recruiter. But it's a lot of bother forwarding emails and stuff to prove I had you before the recruiter sent you in. I'm not going to bother unless you're exceptional. And if you're exceptional, you were already at the top of the pile and you didn't need the recruiter to help you get an interview. Capiche?

The corollary is that you must never go around the recruiter if you first heard of the opportunity through them. If your friend Steve works there and he never mentioned they were hiring, let the recruiter run with the ball and earn their fee. If your friend Steve mentioned that they are always looking for good people but you never gave Steve your resume, let the recruiter run with the ball and earn their fee.

If you gave Steve your resume and for whatever reason you didn't get an interview, but the recruiter tells you they're hiring, politely say that you are already working with the client and ask them what else they have. Then bug Steve to get things rolling.

Keywords

Recruiters are simple keyword-oriented pattern matching machines. J2EE? Check. Eclipse? Check. WebSphere? No? No submit.

Pad your resume with every keyword that might possibly fit. I used to put a keywords section at the bottom for their software programs. If you have a tenuous claim to knowing about something, put it down. For example, I claim J2EE and EJB. But quite honestly, my experience with non-EJB J2EE systems is way bigger than my experience with EJB J2EE systems. But EJB is one of my keywords.

They whole exercise is a waste if the client thinks you've lied, so here's what to do:

First, get a written job description from the recruiter. Don't settle for a verbal description. The recruiter can and will email you something, often exactly what the client emailed them. I've seen forwarded emails with sensitive information such as the client's secret budget objectives. Recruiters are in a hurry, and they love the 'forward' button.

Next, screen yourself out. If you have a scant claim to something and the client doesn't mention it, don't worry. But if it seems central to what they do, you'd better be honest: "Yeah, I put Ruby down because I used it on a student project, but I'm thinking that 37Signals might have high expectations... Let's pass on this one..." The recruiter will understand.

Don't play fast and loose, or you'll wind up coding a Monopoly game in a language and architecture you don't understand. Keywords are fine to get the recruiter to call you, but not fine to get you into an interview where you don't have what the client needs.

Disclosing your compensation

Now about disclosure. Google around. You will find that it is always a bad move to discuss your current or past compensation details with an employer. Guess what? That goes 2^n for recruiters. Do not discuss past or present compensation details with a recruiter. Ever.

As a client, I bug the recruiter to get that info so that I am armed with the power to underpay you when we negotiate. The recruiter gets to play the hard ass while I pretend to be Uncle Reg fighting to get you every dollar.

Ok, I'm not really that bad. But you know what? I'm human, I have a budget, and within a certain range of 'reasonable' for what you can do, it's my job to pay you closer to the bottom of the range and let you earn a raise. It's your job to get me to pay the top of the range and earn a raise anyways.

There're books written on the subject of negotiating salary. They all say the same damn thing. If you want the Coles Notes, when the recruiter says "no details, no submit," you say "You win, no submit." If the recruiter wants to take themselves out of the picture, that's their business. Don't believe them when they say the client insists. I prefer to have the details, but if Peter Norvig wants to meet me and won't tell me what Google is paying him, I'm not arguing.

Now I said you don't disclose details. I think you want to mention a range. Here's exactly what I say when people ask me:

Over the past five years, my compensation has ranged from X to Y dollars.

And when they press for more details, I ask them whether this is in the client's budget. If the answer is yes, let's submit the resume. And they will ask for more details. How much is base? How much bonus? How much last year? Does that include stock options? I blow off all additional details. If they can't submit my resume without additional details, that's their problem.

What the client needs is to know that you are neither too cheap (you must suck, or be ignorant, or both), nor too dear (motivated by money, or ignorant, or both). The range answers the question while giving very little away for the negotiation.

Here's how to calculate X and Y. Over the last five years, take the smallest base salary you've earned in any one year or at any one job. Include only the cash portion. This is X.

Now take the most you've earned in any one of the five years. Include the cash equivalent of perquisites like travel to trade shows or conferences, meals, drinks, everything (I drink two free cups of coffee a day. If I'm calculating Y for this year, I'm adding $2.20 a working day to Y).

That's your range. Notice how it works even if you've been at the same job for five years? Nice. And don't discuss this calculation with a recruiter, ever. Their job is to get you an interview. X and Y are all they need to get you the interview.

Speaking as a client, this is enough. I may want more before I make an offer, but this is enough to know whether I'm wasting your time bringing you in for an interview.

Okay, three tips. That's enough for now. Good luck with your search.

p.s. Why is it so much worse to tell a recruiter your compensation details? Because recruiters will tell everyone. If you tell one prospective employer exactly what you made last year, they do not tell every other employer. They probably consider it advantageous to keep that information to themselves. You've damaged your ability to negotiate with them, but if things don't work out, you can start again with a fresh slate at the next interview.

But if you tell a recruiter, they put it on your file and every time they send your resume out they will send that information with it. Really nasty recruiters will use you to sell other candidates (Ok, you like Kate but you want to see a few more people? Well, I can send you Reg, but he's asking 20% more. If I were you, I'd make an offer to Kate before someone else gets her). If the recruiter has no idea about your compensation history, or only has a broad range, the recruiter will probably send your resume in.

But if they know your exact details, the shortest line between this situation and their fee is pushing Kate instead of you. Not only are you screwed with clients that want to make you an offer, you're screwed with clients that haven't even interviewed you yet! Speaking as a client, I might have liked you so much more that I would happily pay more. But it's hard to know that if I haven't met you, and it's hard for me to have the optimism that somehow you're going to be worth the extra 20% when I haven't seen you juggle.

Don't tell recruiters anything more than X and Y. And even then, skip X and Y if you can.

p.p.s. An interesting link, via lifehack.org: How to Answer the Toughest Interview Questions.

Update: Welcome, Recruiters. Seriously.

Please continue to post whatever you like in the comments on my blog. I'm not going to debate you here, but I won't delete your posts either.

Please keep a few things in mind. First, I'm almost always the client when working with people like you, so I'm only seeing half of the story, the half where you work very hard to convince me that everything you do is in the interest of me, the paying client and not in the interest of the candidate. It gives me a warped perspective, you know?

Second, this is my experience, what I think works for me, right or wrong. You're right that there are other ways. There are thousands of people who have worked with recruiters, broke all of my so-called rules, and nevertheless they seem very happy with the results. Am I calling them on the phone and telling them they were wrong? Of course not.

Third, you really ought to have your own blog where you run the voodoo down for us. Tell us who you are, how you work, and what you think candidates ought to do. Be specific: tell us why it's in the candidate's best interests to allow you to submit their resume to companies without you disclosing the company to them. Tell us why it's in the candidate's best interests to disclose their compensation details to you.

I look forward to reading what you have to say. I'm not young enough to know everything, and I may pick up a tip that will be useful to me. Speaking as a client, I look forward to hearing how your advice for candidates also happens to be in my best interests as an employer. Whether on contingency or retainer, you almost always work for me, the client. Isn't your obligation to act in the employer's best interests? Or am I wrong about that?

Your blog is sure to be an interesting read. C'mon back when you've got something to say and put a link in the comments here. I look forward to hearing from you.

Labels: jobs

  ¶ 2:33 PM

  Quote of the Day: Assaf

People who do not read The Daily WTF are destined to repeat the WTF’s of their predecessors. I never saw a programming language that can cure stupidity, only languages that add safety caps so they look safe, while slowing you down.

  ¶ 10:15 AM

  Causality? Or Correlation? There's an interesting thread on Ward's Wiki: Could Extreme Programming Have Arisen Without SmallTalk? (for those who didn't know this, the earliest use of Extreme Programming was on a commercial SmallTalk project.)

Looking over the discusion, I notice that is heavily weighted towards arguing cause-and-effect. The abridged version is: SmallTalk has these properties, which lead you to these practices, which are codified as XP. The implication is that if everyone had been using SmallTalk (perhaps because it had "won the war with VB"), XP would have been independently discovered/invented dozens or hundreds of times.


I am unconvinced. Instead, I suggest that both SmallTalk and XP are common effects of a hidden variable. They are correlated.

The kind of people that chose SmallTalk for an enterprise application at a time when OOP was considered an unproven language paradigm, and at a time when running "serious" applications on a virtual machine was considered "unprofessional," are the kind of people that will discover or invent new ways to do things.

Paul Graham said similar thing in his Python Paradox essay: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.

What I like about this quote is that it says nothing about whether the "esoteric language" is more productive. It simply says something about the kind of person who learns an esoteric language. And likewise, you can infer something about the kind of project that is implemented in a comparatively esoteric language.

I conclude that the relationship between SmallTalk and XP is one of correlation, not causality. In my opinion, radically different practices like XP are most likely to be discovered/invented by people who are willing to bet on radically different tools like (at the time) SmallTalk.  ¶ 9:57 AM

  Anything "Ridiculously Easy" is going to attract some Ridicule Recently, Lucas Carlson announced Starfish, an ultra-lightweight distributed processing framework, and map_reduce, his own implementation of distributed mapping and reducing based loosely on Google's famous MapReduce.

Almost immediately, people pointed out that what he had created looked to them like a toy. Some people pointed out that although its map is fully distributed, its reduce is centralized in the supervisor process. Others pointed out that fault tolerance was not built-in. Some even pointed out that it looked like a thin wrapper around other services (as if free software is sold by the pound).



I agree that map_reduce is not MapReduce. That's a good thing. After all, the world already has MapReduce. If you want to use MapReduce just the way it is, go work for Google. Don't wait.

You know, all the comparison to MapReduce has a strangely familiar ring. What do the following systems have in common?

Minicomputers, microcomputers, personal computers, laptop computers, 5 1/4" disc drives, 3 1/2" disc drives, 1.8" disc drives, client-server computing, PC databases, Unix, C, Ruby, Java, television, colour television, automatic transmissions, iPods, ...

Must I go on? History is replete with inventions that are simplified, scaled-down versions of things that have come before (I know, Java-haters will find it hard to remember a time when Java was the new kid on the block that represented a simplified, scaled-down language compared to C++). It seems that every time some such thing comes out, somebody points out that it is a toy, not suitable for serious use.

My personal favourite example of dismissing advancement is the television. When it came out, old time radio people dismissed it as a toy. Nice call. But wait, we aren't done. When colour television came out, the black and white television people dismissed it as unneeded. Somebody, as they say, wasn't dancing with the innovation they brought to the ball.

And what happens? Come on, you know where this is going, it's practically a cliché: first the new, simpler, less powerful thing lives in a weird niche where people have a special need that overrides the bountiful impracticalities of the new thing. Then whole new markets are discovered where the new thing offers the perfect balance of features and before long, the new thing takes over the old markets.

It's pretty obvious to me that when a lot of people dismiss something as being too simple, too underpowered, and lacking the wide variety of features and options of its predecessors, the right thing to do is to take a closer look and suspend final judgment. Right now there's a world market for maybe five full-text web search engines. If you are one of those five people trying to index the entire web, you can dismiss map_reduce immediately.

Everyone else might want to look at map_reduce (and everything else considered too wimpy for serious work) and instead of listing all the ways it falls short of the status quo, ask yourself in what ways does the status quo falls short of mass-market appeal.

At first glance, map_reduce looks like it makes it really easy to distribute analysis, especially of things living in your database. Hmmm. Thousands of Rails users put things in one database. Will it scale to 2,000 systems? How many of you have 2,000 systems? Next question.

Now how many Rails programmers just ordered a shiny new Mac Pro with four cores? Nice to see a sea of hands. Guess what? You are all people who could benefit from map_reduce right now. Do you have a few spare Macs or PCs in your office? All the better, put them to work while you're at it.

I'm not in a position to recommend using map_reduce until I've tried it myself. But I can say without hesitation that there is a need for ridiculously easy distributed processing on Ruby, and it doesn't need to scale to 2,000 machines to be useful.

Update: Lucas posted a working example from a production system: How I sent emails 10x faster than before. Updated again to link to his explanation for how reduce works in map_reduce.

Hot news!

"How many of you have 2,000 systems?" The answer is: all of you. Amazon's Elastic Compute Cloud lets you run applications on thousands of machines and pay only for compute time and bandwidth outside of the cloud. Note to my sharp-witted readers (again, all of you): this is not a license to write and say "because I might run an application on 2,000 servers, I'm dismissing Starfish without another thought." The correct thing to write is "I have written an application that runs on 2,000 servers, and..."

Labels: ruby

  ¶ 1:04 PM

  Words to blog by (off topic) Jason Fried, writing on the 37Signals blog:

I wasn’t suggesting to you how to run your business, I was answering a question about how we run ours.

From here on in, this is the unofficial motto of my weblog. I am not telling you how to live your life, write your software, run your business, or conduct your career. I am telling you how I live my life, write my software, run my business, and conduct my career.

I hope you continue to find it entertaining and informative.  ¶ 2:16 PM

  Dynamic is the opposite of Static, not of Explicit I recently read a post where the author said he does not care for Ruby's dynamic typing.

When people start talking about types in programming languages, the terms fly around in a rather fast and loose manner. Here's a rather extensive and balanced discussion: the article on Type Systems in Wikipedia.

Notice that Ruby is dynamically typed (it's types are determined at run time and can change at run time), strongly typed (it does not allow an operation to succeed on arguments which have the wrong type), and type-safe (it does not allow operations or conversions which lead to erronous conditions).



(There's another school of thought about how to name the properties of type systems. More on that at the bottom.)

Proponents of explicit types may say that Ruby is not type safe because it is possible to compile programs that contain errors which will not be detected until the program is run and the erroneous condition is detected.

Statically typed languages such as C# can detect a class of such errors at compile time. Some Ruby enthusiasts argue that they do not like the boilerplate associated with explicit typing and feel that the extra error checking does not outweigh the additional overhead.

Both arguments are mistaken. Sorry about that. If Explicit and Implicit were the issues, we could add Type Inference to Ruby and it would have the low overhead of implicit types as well as some extra error-checking (work on Soft Typing for languages like Scheme and Erlang aims to provide compile-time checking for implicitly typed languages). However, type inference is a feature of statically typed languages.

The trouble is that Ruby is dynamically typed. Specifically, Ruby contains extensive dynamic meta-programming constructs. Type inference works with statically typed languages. The compiler must be able to infer the type or set of types possible for any variable.

Consider a Ruby application that modifies classes and objects at run time. The simplest example is Ruby's built-in accessor methods: attr_accessor :foo is a class method that actually creates two instance methods at run time, foo and foo=. What happens when attr_accessor is called with a variable as its argument, like attr_accessor my_attribute?

If the type inference engine later looks at a call such as bar.blitz = 'bash', how does it know whether attribute_accessor was ever called with 'blitz' or :blitz as an argument? Dynamic meta-programming makes the type inference problem undecidable.

A lucid argument is that Ruby's dynamic typing makes it difficult to detect type errors statically. The correct counter-argument is that Ruby's style of dynamic typing makes it possible to use dynamic meta-programming, such as Ruby on Rails' ActiveRecord, not that Ruby's implicit typing is more productive.

Once you've made these arguments, you can decide for yourself whether the benefits of dynamic meta-programming do or do not outweigh the advantages of static type checking.

(Updated to use the expression "dynamic meta-programming" to distinguish features like define_method from static meta-programming features like macro systems, courtesy of the well-informed Lambda the Ultimate).


p.s. Ward's Wiki seems to use the term static typing to mean the same thing as explicit and strong typing. I prefer that the term static means that it doesn't change. The same wiki seems to use the term dynamic typing to mean the same thing as implicit and strong typing. It includes the possibility that a program is what I would call strongly, statically and implicitly typed: the checking is done at run time but the types of variables never change. The commentary suggests the phrase semantic dynamic typing for the quality of dynamic typing that encompasses dynamic meta-programming. If you like these terms, please substitute "semantic dynamic typing" for "dynamic typing" above.

p.p.s. And there's another argument that dynamic meta-programming, like macros, should be considered harmful. I'm saving my reply for a rainy day.

Labels: lispy, ruby

  ¶ 11:11 AM

  And another thing, you Software As A Service gadfly... I already ticked you off for your agile metaprogramming posts. But it seems I need to write to you again.



I've just finished reading How to make a corporate butt pucker, and you've crossed the line this time. I read about it on one of those collaborative filtering aggregators. Why can't you guys stick to that kind of Web 2.0 mish-mashup-community-portal-culture-hub-stuff and leave the business business to us?

It seems that your VC friends aren't content to merely fund two guys in a living room, but they have the audacity, the unmitigated gall to show up in our offices here at BigCo and question why it takes us "six months just to get a change in screen layouts and another 2 months to line up the application to get ready for distribution to our customers."

This is beyond annoying, it is undermining our credibility as the authority on IT. You can't simply show up with your laptop and hack together some database-backed web application that does 90% of what our corporate systems do in front of our CEO. She doesn't understand all of the complexity behind our process and we don't have time to explain it to her.

Where are your requirements studies? Which consultant vetted your architecture? How can anyone calculate the ROI on your, what, one hour's worth of time? Where's the freakin' PowerPoint deck?!?

Worst of all, your new best friend did it with Microsoft technology. It would be soooo much easier to explain away if he'd used something business-unfriendly like Ruby on Rails, or better still, Lisp. Why do you think we encourage you kids to play with those toys? So that no-one will take your ideas seriously, that's why! Nobody will pay attention to your business ideas if they can't get past the "which database are you using" question.

Now if the CEO thought there was something wrong with our technology, we could blow her off with studies and reports. We delayed adopting Linux for years by saying it wouldn't scale. And it's easy to show that nobody uses Lisp for commercial applications. But what can we say about SQL Server, IIS, and professional hosting companies?

Thanks to this lone crank showing what can be done with our technology platform, she thinks there's something wrong with us.

And that's unforgivable.  ¶ 12:41 PM

  Dear Agile Metaprogrammer I read and enjoy your weblog. You are fairly witty and your stories about attending Woodstock-like love-ins are always amusing. And although I have no intention of even trying Ruby on Rails, Lisp, Python, Haskell, Lua, or whatever else you are fawning over at the moment, there are some snippets of interesting technical knowledge to be gleaned from your experiences.



For example, just the other week I realized that with fewer than 500 lines of intricate code and a few pages of boilerplate interfaces (I was going to have to define all those Java types and methods anyway, so it's free, right?), I could use an InvocationHandler to remove some duplication from my code. I would never have thought of that if I hadn't read about how Ruby lets you make delegates with one line of code.

Philip would be proud of me. But let's get to why I'm writing, ok?

Your posts are getting tiresome.

Blah, blah, blah the indexing takes about 20 lines of code and took less than 10 minutes to get working. Blah, blah, blah magic models. Blah, blah, blah rewrite reddit in Lisp in one hundred lines and twenty minutes. Worst of all, blah, blah, blah $800,000 contract. That's real money!

I don't mind fanboys, lusers that brag about these 'metaprogramming' languages but never actually do any work with them.

But how irritating to hear yet another Rubyist, Pythonista, or Lisper brag about getting actual work done in half the time, with half the effort, then taking the rest of the day off to enjoy the Real World.

Some of us are busy doing Enterprise work, you know, and we're man enough to put in seventy hour weeks debugging our XML parsers, Front Controllers, and verbosely typed languages (VTLs). We don't want to hear about your Euro-style three hour lunch breaks and incremental delivery schedules.

We do the heavy lifting and we have the GANTT charts to prove it.

So just cut it out, ok?

p.s. I'm sorry I'm so testy, but I've been up all night trying to talk to our QA team located in Bangalore. It's bad enough that I don't speak any of their five mother tongues, but it looks like their QA plan is based on a different version of the specs than we got in our supposedly locked down briefing package from the consultants that were hired to gather requirements.

p.p.s. And another thing, you Software As A Service gadfly...

Labels: agile, popular

  ¶ 9:46 AM

  The Difference Between Values and Strategies Put simply, a value is something you are willing to pay for. A strategy is something you hope will pay off for you.

A LISP programmer knows the value of everything, but the cost of nothing.

People mix these things up all the time, especially in business. Have you ever been to a corporate retreat where a select group of the annointed gathers to write a company's "Mission Statement"? Everything is couched in terms of values: "We shall strive for the highest standard of customer service..." "Employees are our greatest asset..." and so forth.



It's a lot of wind. But let's assume that everyone is sincere. Are these things values? You can tell by asking the CEO why you need a mission statement. Here is an answer you might receive:

Companies with Service-Oriented Mission Statements (SOMS) have a P/E ratio 14% higher than their peers as ranked by Booz, Alchie & Weide. Furthermore, customer service has proven to be a competitive advantage: a recent survey showed that 63% of our new accounts selected us because of our reputation for service.

That's a strategy. The CEO believes that she will make more money if they say these things. She may also believe that they will make more money if they actually try to do these things. But either way, it's about the money.

Salient question: if one day they woke up and discovered that they could make even more money by outsourcing their customer service to the third world and driving their customers crazy with frustration, would the 'de-hiring' be done by middle managers or by Bob and Bob?

I'm not saying this is right or wrong, mind you. I'm just saying that if you'd drop service to pursue money, money is your value and service is your strategy for making money. (It might help to think of values as ends and strategies as means).

Something isn't a value unless you... value it. That means you are willing to pay for it. You are willing to give something up to enjoy it. For example, if you absolutely flat-out refuse to work for tobacco companies and you make 20% less money working elsewhere, you have a value.

Or if you insist on top-notch customer service even though it means you have to price your product higher to pay for it, which means you have less market share, and you end up being a niche company in your market instead of vying to be come the next Wal-mart, customer service is actually one of your values.

Now quite frankly, I don't give a hoot about public companies, not even Apple Computer. So let's talk about building great software. What about this quality software thing?

Obviously, quality software can be a value as well as a strategy. We can pretty much take it as given that you can make more money selling oats that have already been through the horse than quality feed. So when you decide that you will make a personal commitment to write the very best software possible, you are acting on your values.

People often have trouble understanding each other when one of them is thinking about their values while the other is thinking about their strategies. Just look at all of the crap people have written about why Apple should license or should have licensed the Mac OS to clone makers.

Could it simply be a values issue? Maybe Apple values the whole user experience and doesn't care if licensing is a decent strategy for gaining market share. (I said if. Allegations that large herds of me-too clone buyers would prefer OS X to stolen copies of Windows are, as they say, unproven in court.)

And so it goes for personal productivity and expression, otherwise known to me as developing software. There are certain aspects of development that incite fractious debate: the people, the processes, and the tools (especially the languages and frameworks).

Honestly,we can have a debate, but let's make sure we're talking about the same thing: are you talking about the best strategies for achieving a certain value? Or are the people, process, and tools part of your values?

It may not work for you, but some people value working on certain kinds of teams. Some people value working in a certain kind of way, be it Agile or BDUF. It's part of their nature. And most especially, some people value expressing their ideas in a certain style, using certain idioms that closely match the way they think of the solution. It's a very deep value.

Constructive Debating

The crazy thing is, a lot of people are resistant to coming clean and saying "Hey, it's important to me personally to do it that way." Perhaps they fear being labelled some sort of difficult prima donna. Yet elsewhere in business, we value people that care about their work enough to set high standards for themselves.

But whether they confess or not, a lot of people have values in this area and choose to couch them in strategic terms. The result is a lot of confusion. The next time you see a flame war going on over REST-ful web service architecture, meta-programming, or whether/how to hire great programmers, step back and try to deduce which participants are defending their values and which are defending their strategies.

You know what? You can go a long, long way towards mutual respect and understanding if you come clean about your own values. Are you constantly defending Java against the Dynamic Typing Visigoths? Try this. Simply say (or write):

You know, this thing I'm using is good enough for my purposes. I enjoy using Eclipse. I like EJB 2.0/Hibernate/Spring. Working with the de-facto standard for Enterprise is one of my values. What you're saying is interesting, and I don't doubt it works for you, but nothing I've heard suggests switching to Rails would be aligned with my values. So it isn't for me.

That would shut me up, right quick. Because I value people actualizing their values.

Practices are values, too

What about practices? For example, are Agile practices values or a strategies?

People get into all sorts of debates as to whether pair programming or project spaces, for example, are more productive than giving programmers private offices. I'm not coming down on either side of the debate here, but I will point something out: there's an implicit assumption that pair programming is a strategy. And that productivity is the value.

That seems obvious. Isn't productivity the goal? Why value anything else?

Well, isn't it just possible that some software developers like the camaraderie of a project space? That some software developers enjoy real-time, high-bandwidth communciation with their customers?

I'll get personal. I get a thrill out of shipping software. Incremental development is one of my values. Even if you could prove it is slower than BDUF, I wouldn't switch. I love the feeling of delivering functionality over and over and over again.

For some people, Agile is a value. Luckily, there's a strong case that it's a good strategy. So a developer that values Agile can work with a customer that chooses an Agile strategy. Click.

Sometimes a value is also a good strategy.

Integrating Values and Strategies

Unless you are a philanthropist, you cannot pay for your values over and over and over again. You have to find strategies that pay for your values. Life is very, very good when you find a way to turn a value into a strategy.

For example. I like working on interesting problems. It's a value of mine. But a career (or a company) can only be built out of solving profitable problems. If I want to integrate my values with my strategies, I have to find interesting problems that are also profitable to solve. Obvious, no?

But before I close on this happy thought, a reminder: even though a value might be a good strategy today, times change and one day the value may no longer be a good strategy in its own right. That's when the real test of commitment will arise: will you have the courage to seek new strategies that still preserve your values, or will both value and strategy be cast aside? It's up to you, and quite honestly nobody knows how they will react until faced with the posibility of making a real sacrifice to preserve their values.

This has been said so many times, in so many different forms, it must be very, very true and simultaneously very, very elusive:

To be successful and happy, seek out opportunities where the strategies for success are tightly aligned with the things you personally value.

Labels: passion

  ¶ 1:20 PM