Monday, December 29, 2014
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!
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.
Tuesday, December 23, 2014
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.
Friday, December 19, 2014
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.