Working with a recruiter?

I seem to hear the same kinds of questions asked over and over again. I recently replied to a thread on JoelOnSoftware about how/when to work with recruiters. I figured it was worth repeating here.

DISCLAIMER: What follows is my opinion. My experience is in the continental United States, and I assume you are pursuing a full-time, on-site employee role. I suggest working with a recruiter if you can find one of high enough calibre, but that should not be your job search alone. Larger companies tend to work with candidates directly, as will small ones; it's the medium-sized companies that tend to use recruiters - in my experience.

That said ...

My advice is that if you are in one specific geographic area, very carefully pick a single recruiter and work with them. The reason to do this is because if you are working with four recruiters, and each sends your resume to BigCo, BigCo may decline to hire you for legal reasons. (They want to avoid paying four recruiters fees, and they want to avoid a lawsuit - or, more likely, strained relations and a lot of wasted time.)

Recruiters from large, publicly-traded companies (K-Force) tend to be more respectable. Recruiters that show up to user's group meeting s and don't get laughed at or "Called out" can be especially good. Ask who in that user's group, that they know, have they placed. Use that as a reference.

Groups that do permanent placement are usually better than contracting houses.

If you are thinking of moving, sure, work with one recruiter from NYC and one from California and one from Florida.

Conclusion: Get references, shop around, and pick ONE.

Agile Alliance Test Tools Workshop

Elisabeth Hendrickson recently hosted the Agile Alliance Functional Test Tools Workshop in Portland, Oregon. I am impressed by both the idea and the attendees - Ben Simo, Brian Marick, Gerard Mezaros, Jim Shore ... it's am impressive list.

While the stars did not align and I could not attend, the good news is that conversation is continuing over the internet.

First, there is the AA-FTT yahoo discussion group, which is open to the public.

Also, the lightning talks were video recorded that they are available on google video right here.

If you'd like to pick one to start with, Brian Marick's "Let Them Eat Cake" is especially interesting.

There's something going on here with the way we use terms like "Test" and "Requirement" that causes confusion and misunderstanding. Fundamentally, various groups, like the traditional test community, the "Agile" Developer Community, the Scrum People, and so on, are looking for different benefits from testing. Thus, in conversations, we "miss" each other or leave unsatisfied. Brian even did a second lighting talk that touches on this.

Perhaps that's a post for another day.

Technical Debt - V

Overall, I haven't been happy with the Technical Debt Series.

For one thing, it reads like old cliches "Just don't do it" is just like advice to lose weight - eat less, exercise more.

People who are overweight are drawn by an entire system of forces to eat more and exercise less. The advantage to the less-healthy life is an immediate, short-term benefit but an erosion long-term. (Sound familiar?)

Telling someone who is overweight "Eat less, exercise more" doesn't help them. And, I am afraid, that's a lot of what into the series. (That, and brow-beat your manager.)

The sad reality is that when you cut corners, the "good job" and firm handshake of the boss is immediate, certain, and positive. The pain from cutting that corner is negative, delayed, and uncertain. Heck, if you're lucky, next time it might just be Somebody Else's Problem (SEP)!

This system of forces is very strong, yet completely invisible to many managers and executives. Thus, what option are technical folks left with but to browbeat management?

There has got to be a better way.

I gave a lightning talk at GLSEC on technical debt, and discussed it at some length with Steve Poling, who moderated lightning talks. Steve pointed out that the technical debt analogy is one that can resonate with managers and executives - people who understand money. His idea is that we study it further, creating a better explanation of the behavior, perhaps some measurements around it, some prescriptions to fix it, and then try those prescriptions, see if they work, and generate case studies.

That, my friends, is a lot of work. I believe it is worth it, so Steve and I are considering creating a non-profit, non-commercial Workshop On Technical Debt (WOTD). The workshop would be free to attendees, one to two days in length, and probably be located at a West Michigan College, probably around August.

If you are interested, leave a comment or shoot me an email.

More to come.

Overheard at GLSEC ...

Anytime I hear that "Failure is not an option", I think to myself that it's true. Failure is probably not an option ... it is assured.
-- Michael Bolton

See you in San Francisco ...

Well, almost. I will be in San Mateo, California, April 15-17th, for the Software Test&Performance Conference.

My conference talks will be on "Evolution, Revolution and Test Automation", "Reinventing Software Testing(*)", "So you're doomed", and, of course, lightning talks.

If you haven't worked with the folks at BZMedia before (the people behind STPCon and EclipseWorld), you might want to consider it. They are currently seeking authors and speakers on software performance testing topics. This will be my first STPCon, so I will certainly let you know how it goes.

In other news, It's just about time for GLSEC. So, if you'll excuse me, I gotta go prep ...


--heusser
(*) - Thanks to Sheri Valenti for that third title. I can only hope that my talk will be worthy of it.

Software Architecture

Long-Time readers of Creative Chaos know that I am a bit frazzelled by the term "Software Architect." I don't think it means anything.

Or, perhaps, to put it another way: Perhaps it means everything?

The confusion of the word reminds me of the confusion over the term testing, which reminds me of Brett Pettichord's Four Schools of Software Testing.

It occurs to me that there are at least five distinct schools of computer architecture:

CPU Architecture: Highly specialized and different; slim to never confused with the items below
A CPU Architect looks a lot like: An electrical engineer
Exemplar: Multi-Core CPU’s

Systems Architecture: Interested in the technology stack used by the business – for example – HP/UX servers running Oracle as DB servers, linux web servers, desktop PC's with windows
A systems architect looks a lot like: A director of IT services
Exemplar: Service Level Agreements, Redundancy, Failover, Backups

Software Architecture: Interested in implementing various strategies to solve problems, such as Session, State, Domain Logic, Polymorphism, MVC, and so on
A Software Architect looks like: A highly-abstracted programmer
Exemplar: UML Diagrams

Organization Architect: Interested in how to seamlessly integrate people, processes and tools while speaking a common business language
A Organization Architect Looks a Lot Like: Some guy asking a bunch of questions and making your job harder
Exemplar: The Zachman Framework, “Enterprise” Architecture, The City Planning Analogy

Consulting Architecture: Interested in helping the customer and technical staff reach a shared understanding of the work, breaking the work up into manageable chunks, helping the customer understand the solution, and sticking around to see the solution implemented.
A Consulting Architect looks a lot like: What we used to call a 'systems analyst' in the 1980's
Exemplar: Story-Cards and a release schedule

This is really just a conceptual framework. Thus, when I get into arguments about the meanings of the word "Architecture", I can say "Oh, wait, you're coming from the consulting school" and do translation.

What do you think? Does this warrant further writing?

Technical Debt - IV

Last Time I talked about how to avoid technical debt as a contributor. I am convinced that by un-training management you can both restore a sane life and decrease the debt.

So your manager, Timmy, doesn't come to you anymore. The problem is, he's got two other people who are (very) willing to take unprofessional shortcuts, so he goes to them instead.

How can you influence that behavior?

So, you overheard the conversation from yesterday – Timmy is hinting to a dev that he needs to take some shorts. The dev, John, hasn't given up yet, but you know he will.

Let's play this conversation:

You: Hey, John, how's it going?
John: Not good. Tim needs this function by Friday.
You: Really? Or what?
John: Oh. Wow. You know – I don't know. He just said we need it.
You: Will we go out of business?
John: Well, no, but we promised it to the customer.
You: Oh, you promised it the customer? Yeah, I understand. You've got to meet that commitment.
John: Uh, no. I never promised anything. I think the sales guy promised it or something.
You: Still, if Tim gave a qualified estimate to sales ...
John: No, dude. Tim didn't promise anything. They threw a date at us.
You: So ... what's the problem?
John: I've got to work every evening and do a crappy job to meet this unreasonable deadline, that's what!
You: Why?
John: Because TIM SAID SO!
You: Oh. Okay. What if you just don't?

(Silence
...
Crickets Chirp)

John: Well, Tim asked me to.
You: Okay. But the important thing is that it is your choice. You are talking like it is not your choice – like you are the victim of fate or something.
John: Well, I don't have a choice.
You: Sure you do. Go home at five. Do it right. That's what I did about the foo feature last month.
John: Yeah, I heard about that. Tim was pi-iised.
You: Yes, but I still have a job, don't I?
John: True, true. But you're not the go-to guy anymore, are you?
You: You mean the clever hack guy that gets more stress injected to his life in trade for being a 'team player'? No, that's not me anymore. Now it's you. Congratulations.

(Silence
...
More Crickets)

John: Well, I get a certain pride in being the go-to guy. Besides, I want to get promoted.
You: Oh. Oh. Okay. Promotions. Right. Does being the go to guy get you promoted? Who was the last go to guy that got promoted for that?

Silence.

John: Hey, nobody.

You: Riiight. So being the hero gets you more work, more stress, and keeps you pigeonholed in one specific sweet spot. So ...
John: But I LIKE being the go to guy!
You: Ok. That's fine. The important thing is to recongize that you are making a choice, and it's yours to make. I can respect that - just don't complain about it later.

(Later that day ... )

John:So, I'm going to tell Tim it'll take two weeks.
You: Make sure you give him options. He could assign me or Bob to help.
John: No way. You're working on that multi-million dollar bank thing. And Bob is working on that memory corruption thing.
You: So ' everyone else on the team is working on something more important and can't be spared?
John: Yes, I asked.
You: In that case, than the project is the LEAST important project in the department. That's not worth losing any sleep over.

Summary: There are three keys here.

A) You have to be successful personally in eliminating technical debt. You must have street cred; you've said no, kept your job, and restored sanity to your life.

B) You have to make it clear to the other person that adding technical debt, like working overtime, is a conscious choice. Don't let them play the victim "I have no choice" card. That is absconding responsibility. Making compromises happens every day - and it is a conscious choice we need to take responsibility for.

C) Don't let it turn into a Us Vs. Them conflict. The key is to have the contributor present an entire series of options to management. Perhaps one of them is to cut quality – in which case the manager is assuming debt, and, likely, risk. In that case, just ask for a statement of assent by email.

Your colleague might just get that email, and you might too – but overall, if you just follow my quick plan, you can vastly decrease the cruft and drag on your codebase, thus increasing your overall velocity.

That's not stealing from the company – it's investing in the company. And it's certainly not rude or insulting to management. Instead, it is honor management by asking them to, well, you know ... manage.

In the past posts, I've been tough on management. I'll close by turning the tip of the spear the other way – what enlightened management can do to prevent and pay off technical debt. (Those darn contributors with their clever hacks! That's right folks – no one is coming out of this unscathed ...)