Preview of my "Refactor Your Software Career" talk

On Oct 24, 2012, I will be presenting a talk, "Refactor Your Software Career" to the Agile Groupies meeting in Ann Arbor at the Forge. I'll be sharing my journey from stagnant software developer to my current position at Pillar as a software craftsman and agile consultant, along with specific actions I took to get there, and strategies that anyone can apply to improve their career path. I'll also touch on barriers to taking this kind of action and what helps to get past those barriers.

But a key component to my talk will be what I'm calling "Transformative Networking". My idea is that you can simultaneously improve your marketability (raise your skills and experience) and increase the number of people who might want to hire you even while you continue to work at a job that doesn't offer growth or networking.

Transformative Networking involves engaging in activities that share as many of the following attributes as possible:

• creating real value (like volunteering or teaching)
• in your desired field (volunteering is good, volunteer coding is better)
• with others (solo coding a website for a charity isn't as good as being on a team doing it)
• in person (there's no better way to present yourself than by working with someone in person)
• with people in your target companies (if you want to work at a company, let their employees get to know you)

If you engage in activities like this (and my talk will include specific examples of ones I participated in), you can not help but increase your skill sets and get noticed.
 

What is "The Forge, By Pillar"?

If you weren't at Agile and Beyond 2012, you may have missed the announcement by Pillar Technology (my employer) that we will be leasing a large space in Ann Arbor's Tech Brewery, a 1850's era building that started life as a brewery and is now a tech startup community with over 30 member companies. The space, and the activities there will be known as "The Forge, By Pillar".

My understanding of this new sub-brand its that it will a place where Pillar can:

• bring client teams to to a space "away from home" to help them create software in ways radically different than what they are used to, while we provide coaching on principles and practices of Agile, Lean, Speed to Value, and others
• bring clients to show them the exciting way our teams create software to generate business value and, if clients desire, quickly assemble team a of skilled software development practitioners to rapidly build valuable software for them
• offer training courses on topics like: Writing User Stories, TDD, BDD/ATDD, enterprise transformation
• host user groups, CodeRetreats, coding dojos, givecamps, etc

I've found that people often want to start writing software differently but feel held back by various forms of inertia in their company. I imagine The Forge being a place where people can come, individually or as part of a company team, for an afternoon visit, a training course or workshop, or for weeks of on-site coaching and development.

Please join us for an open house on May 17th (note the updated date:) Thursday, June 21from 6-9 pm at Tech Brewery and see for yourself what The Forge is about! (map)

Trying to get .Net Metrics Computed and Displayed with Jenkins

I'm helping a .Net team stand up Jenkins as their CI server. The build steps we have so far are building a solution and running fxCop against the debug build. Using the Jenkins Violations Plugin, which supports fxCop, we can display a nice trend chart and have hot links to drill down and see the violations in context.


My next goal was to run metrics that my team agreed on, specifically Cyclomatic Complexity and Coupling. I was hopeful because Visual Studio 2010 can already compute them. But I found out that Visual Studio's code metrics can't be called on the command line. 


Fortunately, I found Visual Studio Code Metrics PowerTool 10.0 for that purpose. There's lots of information already out about using it: Jeff Bramwell has a blog post about the PowerTool and Cameron Skinner wrote one about it.


Unfortunately, the Violations Plugin doesn't support the xml output, and the PowerTool doesn't have an option to output to HTML. Fortunately, though, Skinner also wrote a post that provides an xslt and a .css file that will turn the results into HTML.

So my next step was to make a build step that runs a command-line tool to apply the transform. I couldn’t figure out or find enough documentation on msxsl.exe, but I found this CodeProject project and it works. (Anyhow, it would only take a few lines to write your own in C# because you can use calls from MSXML.)

Now I need to figure out how to use the HTML report in Jenkins. I'll investigate the Jenkins HTML Publisher Plugin.

Advice for someone wanting to get (back) into software development

I was talking to a friend today who was doing software development several years ago but has been unemployed for a while. He asked if I had any ideas about what he might to to get back into software.

(An an aside,  Patrick Welsh already wrote a great piece about why people should consider a career in software)

Here are some of the thoughts I gave my friend on how to get (re)started in the industry:

- If you don't have work experience to show on your resume, create relevant non-work experiences and structure your resume to show them.

- If you're not already on Twitter, set up an account and use the search function to find experts in the areas you are interested in. Follow them.

- Attend groups/events where people who do what you want to do gather. Ask people questions about what they do. Ask what blogs they read and who they follow on Twitter.

- Start learning web programming, throw up a website, publish the code on someplace like github, and keep updating it. One place to start might be: http://railsforzombies.org/

- Expose yourself to new languages and technologies: ruby, scala, functional languages, automated testing, continuous iteration ...

- If you're not currently working, ask about an internship someplace you'd like to work at, even if it has to be unpaid.

- Be helpful - volunteer for anything related to your targeted field. People remember/like you better if you've helped them. Less cynically, it gives people a chance to see who you are and what your attitude and skills are.

- Don't get hung up on getting/finishing a degree if you don't already have one, especially if it would take away from getting real life experience.

- Read this book about managing your software career:
"The Passionate Programmer: Creating a Remarkable Career in Software Development" by Chad Fowler

- Consider reading this book about agile software development:
"The Art of Agile Development" by James Shore


Finally: Don't follow my advice without deciding for yourself if it makes sense for you. Ask other people about it as well.

On Giving Useful Feedback

Successful agile teams do well, in part, because of the types and amount of communication they use. One place where communication is most important and comes with significant risk is giving "constructive criticism" or "corrective" feedback. I've noticed two patterns of feedback that don't work well: indirect or soft feedback, focused on not hurting the recipient's feelings and unnecessarily frank, or even blunt feedback given with little regard for the recipient's feelings. The first pattern tends to communicate insufficient information and the second pattern, while containing full information, is not presented in a manner that that is often met with defensiveness.

A friend told me about a pattern of giving feedback that I think does a good job of avoiding the pitfalls of the first two patterns. I didn't ask him where he learned it, and I could only find one reference to it: http://bit.ly/dEwGw4 The pattern is called "what-what-why" and it works like this:

• Tell what you didn't/don't like or what you think didn't/doesn't work well
• Tell what you would like instead
• Tell why you think your suggestion would be more effective

For example:

• I don't like how our team is spread out and in individual cubicles
• I'd like it if we moved into one room and sat at a cluster of tables
• We'd "overhear" important information and there would be fewer barriers to asking each other questions.

Or:

• One thing that didn't work for me in the retrospective was when you would say something before someone else was finished speaking
• I'd like it if you allow other people to finish their point and then add yours
• I think the meeting would flow more smoothly and everyone would that they would get their chance to be fully heard.

There are a couple things I really like about giving feedback this way. First, it makes it clear that this is what I don't like and what I want instead. If I were to instead say: "You know, it might be better if you let people finish their point..." or "Don't interrupt people...", I'm not really owning that this feedback is coming from me. Second, it focuses on the desired benefit instead of focusing on anything about the person, making it less likely that they will take what I am saying personally and become defensive. And finally, I don't have to spend a lot of time thinking about how I am going to give feedback or worry much about how the person might take it. As soon as I see something that I'd like to be different, I can give the what-what-why and address the issue right away. This is great because communication is most effective when it happens early.

I recognize, however, that not all feedback is intended to cause a different outcome. Sometimes someone is doing something that I like or that I think is working well and I want to let that person know. In that situation, I use a "what-why" pattern:

• Tell what you like/liked or what you think works/worked well
• Tell why you like it or think it works well

For instance:

• On the story wall, I like how you've given each team member a tag that they can put on the story that they are working on.
• Not only does it let everyone know what everyone else is working on, but it's a good way of reminding people to only work on one story at a time.

Like what-what-why, this pattern lets me own that this is my viewpoint, it focuses on the process and outcome rather than the person, and it's a template that lets me communicate as soon as I recognize that I want to.

If you try what-what-why or what-why, I'd be interested to hear your results. Do you have similar feedback patterns that you find useful?

Another Thought on Certification

Yesterday at 1DevDayDetroit, Virender Ajmani gave a very interesting talk about Google Map mashups. (If you missed his talk, check out his blog or download his slides.

Besides his very interesting content, he mentioned something that else that caught my attention - the Google Qualified Developer program. It's a different approach to the question of developer certification (which I know is a hot topic in the Agile world in general and at the Agile Skills Project in particular). Google's program is free, and it focuses on accomplishments, references, community participation, and knowledge. If you become certified, you get a badge for your blog.

To be certified in a particular Google API (Chrome extensions, Maps, etc.), a developer must earn at least 3000 of the available 5000 points towards that API in any. She/he can earn points in the following ways:
- showing proof of their work (working code) - up to 1000 points
- providing references (from paying clients) - up to 1000 points
- demonstrate community participation - up to 1000 points
- take the online exam - up to 2000 points

What I like about this approach is that no one type of mastery is enough to earn certification. For instance, a developer who aces the exam can not be certified without other evidence of their competence.

I wonder what an Agile badge in this style would be like.

There are already Scrum exams. Perhaps taking one of them would earn some points. There would be a cap on how many points could be earned through exams, and exam points might expire after a certain time.

I'm not sure how working code is necessarily any indication of someone's skill in Agile, so I think we'd have to come up with something else.

Attending certain classes might be worth points. I know there's been a lot of talk about how taking a class doesn't necessarily mean a person learned anything, and I agree. So perhaps any given class would be only worth a small amount, say 200-300 points, and it would only count if you had taken the course in the past year, and only 1000 points could be earned by attending classes.

Certainly some Agile developers could provide references from customers, and capping the number of points from references would reduce the chance and affect of quid pro quo referrals. Developers who don't have professional references could earn their points in some of the other ways.

And maybe book quests or webinar quests could provide a few points, perhaps with a fairly low cap.

I know there's a non-trivial amount of administration that would be required to manage a program like this. Please join the discussion on the Agile Skills Project Google Group.