What would your programming language look like if the Pointy-Haired Boss had to be able to understand it?

Ruby and Cucumber (at least for your test code)?

Who's going to really whip the Llama's ass now?

I don't really care about being able to fly (As I don't know or want to know how to do that anyway), shrink, go subterranean, or any other ridiculous thing. I'd settle for the following in a perfect vehicle:

• Run on a clean, cheap, limitless (or nearly so) fuel source.
• Be able to carry as much cargo as I need to when I need it, but be compact and maneuverable when I don't.
• Self-repair itself. If I didn't have to go to another mechanic for the rest of my life I would be perfectly happy.
• Actually be safe, with zero chance of injury to passengers.

In my opinion these are way more important than the bunk listed in the options Can you imagine all the idiots on the road today, except that every single one of them can potentially smash your house flat from the sky?

Exactly how many IT workers do you know who will need Social Security when in all likelihood they've been in IT their whole lives making IT money? I don't know about you but by the time I turn 65 I plan to have some kind of nest egg built up. If you're in IT you're not exactly hurting for money (or you're doing it wrong).

It's possible I've used the wrong word here, but when I talk about being passionate about your job I'm not talking about being "emotional" about your job.

What I'm talking about is going above and beyond the minimum required effort. The absolute minimum required effort is usually that the software works, it satisfies the client's requirements, it comes in under or at budget (this is obviously more at the project level and then individual developer level), and that it can be maintained. Above and beyond is about craftsmanship. It is about TDD, refactoring until you have made your best effort to get the code clean, and pushing back on ridiculous requirement to get to the true business need. It's about taking the time to learn new technologies off the clock, it's about giving back to the community that has given you so much (Do you, for even one moment, imagine that you got where you are because you learned and worked in a vaccum?). Whether this giving back mean you contribute to open source project, you maintain a blog, attend or present at user group meetings, etc is up to you, but if you're going to work with me I want to see that you're active and you give a shit.

don't think that I care more about your projects than my family or my personal obligations

As a family man myself I completely understand your sentiment. There is certainly a balance to be held. I spend time with my family and love my children, but I also know that nobody, noboby owes me a free ride and it is up to me to excel and continue to learn and grow as a developer outside of the 9-5. Clients almost never pay me to learn on their dime, and when I talk about being passionate I'm talking about understanding that you need to give enough of a shit to grow on your own and give back. I want to work with developers who are on that wave length and do more than clock in, write their 500 LOC/day, clock out and promptly forget about programming until 9AM the next day.

No problem, it is always nice to have a good conversation, not to mention being pleasantly surprised by a thoughtful and polite AC :-). Good luck in your career!

Not with an attitude like that we're not.

If you're in it purely for the money you're in it for purely the wrong reason. Passion is is not stupid, or a sign of weakness. Passion is caring about the work that you do, and therefore about the work that others do because ultimately their work is what matters. IT is not an end unto itself, it is a means to accomplish other things. Being passionate shows you care about the quality of your work and the quality of others' work. If you come to the table and you can't show passion about your work and your overriding value is money then hit the road. There are thousands of others just like you who would love the chance to show they can do the job, and they may or may not charge your rate.

if my best code I've written is proprietary, how can I show that to you?

This is why I look for recommendations and blog posts. I'm in the same boat that you're in, which is that my best code is proprietary. The solutions is to have others recommend your work and by writing about the things you learn. By this I don't mean that you post specifics about your code as it is the implementation of the concept or technique you have learned (not to mention posting chunks of proprietary code will get you fired or sued). It isn't the specific code that matters, it is showing that you have the skills, knowledge, ability to learn and care enough to share these things for the benefit of others.

Makes me be the question: you want someone who just puts stuff online to show off, or do you want someone with a track record of getting the job done?

So first of all you're looking at this the wrong way. You're not "showing off" per se. You're selling your services in most honest manner you can. You have to get over the idea that you shouldn't talk about yourself. You're in business, and in business no one will sell for you. You have to be your own champion, and that means being willing to put yourself out there, talk about what you've learned and show people why they should hire you.

To answer you question "getting the job done" is obviously the important thing. The trick is showing people who have no idea who you are or what you've done that you can, in fact, get the job done. When they are interviewing you they are trying to determine if it is a "safe bet" to hire you on, and make no mistake it is a bet. Chances are neither they nor you will know if it is a good fit until after the fact, but you can help them make that decision and put them somewhat at ease by talking about yourself and sharing your experience ahead of the conversation.

My job as the technical interviewer is to determine if the things you say you know and have done matches up to reality. You'll make my job easier if you can show me that concretely, and therefore make it more likely that I'll recommend you to continue in the hiring process.

I pay scant attention to resumes, except as a starting point and a way to see if you can string words together in a syntactically correct manner. Not having an online presence won't hurt you necessarily. After the receiving a resume the first thing I'll do is to google you to see if you have:

• Public code contributions (Github, BitBucket, SourceForge, Launchpad, etc). This is probably the most important bullet on this list. I want to see that you're passionate about software development, and that you're taking the time to grow and learn outside of your day job.
• Any kind of technical blog. I don't care about your blog about your love of spaghetti, I want to see if you are capable of communicating technical ideas, and more importantly that you see the value of sharing your knowledge with others. I'm not interested in working with introverts or knowledge hoarders, I want to work with people who are interested in building others up, making an impact on the lives of others, and helping other developers to grow.
• Recommendations on LinkedIn. I don't care about endorsements; they're essentially worthless as the endorser doesn't need to put any thought into the skill being endorsed and how well the individual actually performed that skill. They simply click the endorse button and move on. Recommendations are different as they require some thought on the part of the recommender and show that the work that you did actually mattered to someone. It also also fairly easy to weed out the true recommendations from the "cookie-cutter" recommendations.
• A low profile on Facebook, or failing that a "clean" public profile. Twitter is fine, with the same caveat that the profile is clean. Technologists who don't know how to manage their public interactions make me wonder how they manage their professional interactions.

I use this information to prepare for the technical interview, and make notes to call you out on your experience and listed skills. If you walk the walk it will show through in your online presence, face-to-face and pairing interview.

Not having these things is not necessarily a bad thing, especially if you're fresh out of college, but having them lets you tell your story. Not to mention that if you have any length of experience I'd be suspicious if you didn't engage in at least some of these activities.

Non-critical doesn't mean trivial or unimportant. Simply because he doesn't see the changes at the same level of criticality (is that a word?) doesn't mean that they're not important to someone. The message he sent out on the mailing list goes on to say:

Anyway, the rc5 changes are pretty much all over: pretty much exactly half are drivers (networking, usb, gpu, mmc, sound..), with the other half being various other subsystems. Some arch updates: MIPS, arm, smattering of ia64, microblaze, s390 and some x86. And networking (non-driver), xfs, fuse, gfs2, jfs..

I don't know about you, but none of those things sound unimportant to me. How long have people been bitching about driver and network support in the kernel? And he's complaining that that stuff is getting fixed? Please. The fact of the matter is that he's annoyed because he refuses the let got of the reins and let someone else help out. If he is the gatekeeper than this is what he should expect.

So, the great thing about an Open Source project is that developers have the ability to say "Hey, I think we can do this better." and then go off and actually fix it. They are not beholden to a corporate IT overlord that says "Thou shalt not commit code that is directly related with the task in front of you!" Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.

As far as Torvalds getting pissed off (as a feint or not) and talking smack about how when a developer's mother sat round the house she sat around the house he's brought this on himself as the gatekeeper for the project. This is simply the nature of an Open Source project. Furthermore there is nothing that says he can't simply reject a pull request and declare the RC closed for anything but direct bug fixes (which is what he is actually doing I suppose).

FWIW I don't disagree with you exactly, I just think it is important to keep in mind what kind of project and what kind of developers we're talking about.

Everyone has to have a hobby, right?

Seriously though, who the hell cares if the RC is bigger than the one before it, or whether the changes are scattered everywhere? If there were any number of concerns that needed to be addressed before the next release then it wasn't ready to go in the first place. Just test the hell out of everything, make sure nothing is broken, and make sure that each change was necessary and correct. In short calm your tits and keep coding.

Yes, Ken Schwaber basically said this at Path to Agility on Thursday. I think his exact words were "it was just a word that we thought was clever, but it probably has more of an impact than if we had used 'rigid', or some other word."

At the end of the day the Manifesto really says they support collaboration and getting things done over planning and following a process. It doesn't say a thing about any of the practices that have been implemented in Agile's name.

There's also a lot of gaps in Agile and IMO while Stories are great they are not a substitute for fully defined requirements analysis.

I hate to break it to you but "fully defined requirements analysis" is a pipe dream filled with rainbows and unicorns. I have never, not once, seen a requirements document that accurately captures exactly what the system will do. Even if it did it would be true for all of 5 minutes before the product owner/user changed their mind and redefined what they want. The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want. I know what you're going to say next: "If they keep changing their minds then how does it ever get done?" Simple, you make it extremely clear that continuously changing their mind directly equates to more time and money spent and prevent other functionality from being implemented.

The key stakeholders either don't pay attention or louder voices who have really no relative bearing to the project somehow get suddenly important. These are often folks with something to gain by holding things up or creating confusion. That is always the problem in all projects but it seems more acute in Agile because "hey, we have a process that can allow for these changes."

You're right, this is true on all projects. Stakeholder involvement has to be managed just like any other aspect of a project. As for "we have a process..."; if you think Agile is about processes then you really don't get it. Agile isn't about processes, it really is about adapting to change and doing what works. If what works is having a daily stand-up and holding team members accountable for for their work then so be it. If it means not pair-programming, then do that too. There are no hard and fast rules.

You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.