My CodeMash Sessions

UPDATE: I had the days wrong. Leadership workshop is Tuesday starting at 8am in Salon H. My Web UI Automation workshop is Wednesday from 8-5 in Guava/Tamarind.
I’m flattered to have been picked up for two workshops and one regular session at CodeMash! It’s going to be great being able to focus on just giving great sessions and not worrying about herding various cats around.
Tuesday I’m giving an all-day workshop on web UI test automation. We’ll dive deep into working with Selenium WebDriver, but the concepts will cover plenty of other toolsets. I’ll likely spend a bit of time showing how a commercial tool like Telerik Test Studio fits in to things.
Wednesday I’ve been asked to do a half-day workshop on leadership. That’s incredibly flattering! I’m basing the content for that off my Leadership 101 series, plus the book I’ve just started The Leadership Journey. This brand-new workshop will be very interactive with a good number of exercises meant to help you really dig deep and figure out how to evolve your own leadership style. I’m pulling this workshop’s content together very quickly, and I’m both excited and terrified.
Thursday I’m in an opening slot at 8am talking again about web UI automation: Ten tricks to help you get the most out of your UI testing. The talk centers on web automation, but it really will help you regardless of what UI tech you’re working with.
Interested? Check the CodeMash schedule for details, or go grab the EventBoard app and get your schedule built up.
Got questions on testing, process, leadership, or something else? Look me up at the conference! I’d love to chat!

You Broke My Code? It's My Fault

I was having a conversation with a few smart folks a couple weeks ago and one of them mentioned a great mindset their organization has: “You broke my code? It’s my fault–I didn’t have the right tests in place.”

Step back and think about for a minute.

This quip really set me back on my heels. If you’ve read anything of mine over the years, you know how I feel about taking responsibility for one’s code and one’s tests. This organization’s mindset of owning the responsibility for bullet-proofing your own code with great tests is terrific.

It’s one thing (a great thing!) to step up to the plate and be serious about getting testing ingrained in your delivery process. It’s a serious elevation to get a mindset where every developer takes it personally when someone else breaks their code.

“You broke my code? I needed more tests.” What a great mindset.

Book In The Works: The Leadership Journey

I swore I’d never write another book after finishing 1300 pages of Windows Developer Power Tools with my co-author James Avery.

Famous last words.

When the kind folks at CodeMash asked if I could put together a four hour workshop on Leadership, I figured I’d better get some solid content laid out to make sure the class wasn’t just boring anecdotes of mine. I needed something more focused, and something with some practical put-this-to-use-tomorrow kind of ideas.

Apropos, let me introduce to you The Leadership Journey. This book contains the original Leadership 101 blogposts and will end up with a lot of new content. There will also be practical exercises to help you focus in on a few key things.

What’s the books goal? To help you answer a few key questions:

• Do I want to be a leader?
• What are my strengths and how can I make the best of them?
• What are my weaknesses, and how can I best mitigate them?
• How can I make my team be awesome?

I’m publishing the book on LeanPub with a recommended price of $9.49. I hope you’ll have a look at it.

What would you find helpful in your own leadership journey? Leave me feedback here in the comments, or over on the book’s LeanPub page.

Choose Wisely AND Back Out Easily

Alan Cooper (Yes, that Alan Cooper) had a great-sounding Tweet yesterday that made me stop and think:

Instead of choosing the correct path in advance, develop better tools to incorrect paths soonest and without rancor.

I get the point I think Mr. Cooper was trying to make: we need to be able to recover more easily from our mistakes in software. I especially love his point of “without rancor” because we need to be more accepting of the fact that the path to success is littered with unsuccessful tangents.
However, I’ve got a subtle iteration of his phrase I like better:

Do your best to choose the correct path at the start, but know how to figure out it’s an incorrect path, and figure out how to reverse soonest and without rancor.

I completely agree that we need to get in the business and cultural mindset of being OK with failure/mistakes, getting out of them as quickly as possible, and doing it without rancor.
That said, I’d prefer the subtle difference of emphasizing avoiding those mistakes where possible. We should not, repeat NOT get wrapped up in fear or analysis paralysis blocking us from decisions that might lead to mistakes or failures, but we should be doing enough sanity checking to ensure the choice meets business value requirements, fits the teams’ ability to deliver, etc.
In my Leadership 101 talk I make the differentiation between smart mistakes and dumb mistakes. Smart mistakes are ones made when you’ve been thoughtful about your approach. Dumb mistakes are when you dive in to dig a 14’x8’x18” rain garden pit, then realize you’ve dug it right next to your house’s foundation–not the place you want a lot of water sitting for extended periods. (Ask me how I know about this…)
Backing out from unsuccessful choices is critical. First spend a little time planning to ensure you can avoid as many of those choices as possible.

Rethink Your Hiring Critieria

This article on how Google's changing their hiring practices really hit home with me.

I've long viewed learning ability and problem skills as far outweighing where someone graduated from or what their resume history looked like. I've previously blogged about my thoughts on hiring, and  my position descriptions have tended to drive HR departments crazy because they weren't checklist oriented.

I've always been more interested in how well someone's going to approach working as part of a team over what classes on compilers they took, or what certifications they've passed.

Technology changes too fast to focus on criteria like "3.6 years working with .NET 4.5" or "Must have graduate degree in artificial intelligence." I'd rather have people on my team who have made some big mistakes, learned from them, and want to share that knowledge with the rest of their team.

Do your hiring criteria look like shopping lists in the technology buffet? Perhaps you might reconsider reworking those around criteria that focus on your organization's real needs: candidates who can help you quickly and effectively solve problems core to your business needs.

Hire me!

I'm open for work!

Last week I parted ways with Falafel Software. They’re a great bunch of folks, but we weren’t a good match culturally or philosophically. That’s absolutely OK, and we parted on good terms. I’m happy to continue recommending them and calling them friends.

That means, however, that I’m open and available for new opportunities! I’m actively looking for work as an independent consultant, or for any full-time spots where organizations think I might be helpful.

What sort of things can I help you with? I’m passionate about helping organizations deliver great value to their customers, regardless of whether those customers are external or internal. I’ve helped teams build out their testing skills (not just test automation, but overall testing), smooth out quality issues impacting their organizations, and cut out waste throughout their delivery cycle.

That may sound a bit hand-wavy to you, so for more details check out my LinkedIn profile, visual resume, or more “traditional” (eg ‘non-gonzo’)resume.

Want to chat about things in more detail? I’d love to talk with you! Drop me an email at my new Indie digs: jim@GuidepostSystems.com.