Tag: Soft skills

KalamazooX 2016

https://www.instagram.com/p/BE02swOAJ2x/?taken-by=jeff.yates

This weekend, I attended the Kalamazoo X conference in Kalamazoo, MI. KalamazooX, or KalX (as it is more often referred by organizers and attendees alike) is "a one day, single track non-tech conference for techies", or perhaps "it is a soft skills conference", or perhaps not. You see, like a book filled with complex characters, rollercoaster plot twists, and profound revelations, it is hard to describe KalX; each description I hear is somehow right and yet completely wrong, painting KalX as something you have already experienced where speakers talk of project planning, team communication, and time management. But KalX is different. KalX is where you hear about the importance of empathy, the roots of genius, or the virtue of personal reflection. KalX might help with your soft skills, but only through indirect action, through powerful talks on why practice trumps passion or creates genius, how apathy and empathy are both needed to foster better relationships (at work or otherwise), or what it is to simply give a shit (and sometimes, to give a shit too much).

https://www.instagram.com/p/BE1k8QIgJ-Z/?taken-by=jeff.yates

Whether speaker, organizer, or attendee, KalX is catharsis in the shared and personal experience; strong emotions —anger, joy, sorrow— marked by F-bombs and tears; and unexpected moments (some uncomfortable, some reassuring) where attendees might think "me too", "that's bullshit", or "I am not alone"1.  It is in those moments that KalX shines, the moments when we are raw and exposed.

Four years ago I attended my first Kalamazoo X conference. It was then held in a classroom at a local college and there were about 50 people in attendance, including speakers and organizers2. I had no idea what to expect, so when I found myself crying, stuck in the middle of a row of people I barely knew, I felt surprised, uncomfortable, and confused3. I do not recall if I knew at that moment, but I now look back on that day as the start of what would lead to the diagnosis of my anxiety disorder, its treatment, and the continuing changes to my life that followed. That experience pushed me closer to asking for help.

https://www.instagram.com/p/BE1ZVw7AJ7k/?taken-by=jeff.yates

Though it was for me, I would never say KalX is life-changing; each person experiences it differently and each year is different. In the safe space of peers, where the speakers, unfettered by recorded sessions, can open up about their personal experiences and the things that, in other forums, might be hidden from view for fear of judgement or isolation, KalX facilitates personal discovery. This year, I felt anxiety rise from nowhere when one speaker (Ed Finkler) started to tell my story. Ed doesn't even know me and yet there he was talking about General Anxiety Disorder (GAD), fearing entering bars to look for people as though a lion might be waiting to attack, thinking things through to find every possible outcome and worrying about all of them intensely. Though I wanted to hear more about how he coped with it all4, I was amazed to even know that there was someone out there just like me. It was scary and reassuring, and I might have been the only person in the room that thought so.

https://www.instagram.com/p/BE1KXhKAJ-e/?taken-by=jeff.yates

When I first started writing this post, I tried to summarize the whole day, but I couldn't do justice to Christina Aldan, Ed Finkler, Kate Catlin, Jay Harris, Cory House, Leon Gersing, Lauren Scott, and Alan Stevens, or their talks on empathy, apathy, genius, passion, and more besides. It is hard to describe what they said in a way that could convey what it was like to experience it at the time, just as it is hard to describe KalX as a whole. It is even harder to describe these things to convey how someone else might have experienced the day. In realizing this and the inadequacy of phrases like "it's a soft skills conference" or "it's a non-tech conference for techies" I have wondered, how could I describe KalX in a single sentence? I don't think I could, not because KalX is some indescribable experience, but because each person finds value from it in different ways. Sometimes, no matter how hard you try, there is no apt summary, no convincing abstract; sometimes you just have to read the book for yourself.

 

  1. Or briefly, involuntarily emit an inappropriate laugh at that same realisation [↩]
  2. this year had closer to 200 [↩]
  3. KalX can really sneak up on you [↩]
  4. how I could cope with it all [↩]

#kalx15: Back to Basics

This weekend a couple of friends stopped by the house at around 5:45 on Saturday morning. Normally, this would not be welcomed, but it was time for our annual road trip out to attend the Kalamazoo X conference. This year marked my third year of attending this fantastic one-day, single-track, soft-skills conference. Though often referred to as a non-tech conference for techies, Kalamazoo X is a really accessible event and as such, this was the second year that my wife, Chrissy, also joined us.

This year's conference was held at Loft 310. I found the new venue — with attendees sat around tables similar to how people would be seated at a wedding or party — to be an improvement over last year. Though fantastic, last year's academic venue, larger attendance, and expanded speaker schedule lost much of the intimacy and community that made my first year at KalX a memorable and somewhat life adjusting event. This year was a return to that more intimate experience of two years ago, feeling much more like a gathering of friends and family than a conference of professionals.

The speaker schedule was also condensed this year and all the better for it. The roster included a welcome return of some KalX veterans like Jeff Blankenburg (@jeffblankenburg), H. Alan Stevens (@alanstevens), Jim Holmes (@aJimHolmes), and Elizabeth Naramore (@ElizabethN), as well as some newcomers like Jay Harris (@jayharris), Cori Drew (@coridrew), and Dawn Kuczwara (@digitaldawn). Though each topic was different, they were bound by the common year-on-year KalX themes of learning, mentoring, and growing.

Upon reflection, the talks that I remember most vividly were those where the speaker opened up, let down barriers, and gave honestly to the audience. Alan Stevens was, as always, a joyous speaker to experience — his command of space and time when delivering a talk is really exemplary, yet it was his candidness in discussing his struggle with depression with which I connected. While Cory House (@housecor) spoke on breaking the monotony in life and stepping outside of our comfort zones, it was when he opened up about his social anxieties and personal journey to overcome them that I took notice. And though Jay Harris delivered as polished a presentation as he ever has, it was his willingness to share his broken dreams of baseball and airplanes, open up about personal challenges, and be as raw with the attendees as he is with his friends that took his talk from good to great.

Though I enjoyed all the talks, it was Jay's talk, #conviction, that stood out most for me. Jay's message felt like the third part to a trilogy that started with Jeff Blankenburg's talk, "Be A Beginner", and was fleshed out by Alan Stevens' talk on "Values Driven Development". Jay judiciously spent every second of his time with a well thought out rebuttal to the too often repeated adages "follow your passion" and "hard work pays off". It is easy to ignore the privileges we have that we more commonly refer to as "talents", to let humility lessen their importance, but it is talent coupled with conviction that leads to success1.

Of course, it was not just about the guys. There was not only a more diverse audience than one might expect, but three of the eight speakers were women2. A favourite talk of the day for me was "Give Up!" from KalX newcomer, Dawn Kuczwara. Through personal anecdotes and a wonderful, personable delivery, Dawn explained the importance of letting go of control, of allowing people the opportunity to fail and learn, and of making sure not to stifle the growth of yourself or your team by micromanaging and "helping". To me, this talk was the second part to another trilogy that was started by Cori Drew and her impassioned (though perhaps a tad too long) talk that related her experiences mentoring her daughter from curious kid to seasoned speaker (at age 11), and closed with Elizabeth Naramore explaining why it is always OK to follow your passions in your leisure time, regardless of talent.

Though it was a long, tiring day (I drove, drank far too much caffeine, and stayed up way too late), Kalamazoo X was a day well spent. I am grateful to Michael Eaton (@mjeaton), Matt Davis (@mattsonlyattack), and all their minions, speakers, and tolerant friends and family for the time and patience spent in organising and delivering a terrific conference. Once more, after CodeMash had refreshed my curiosity, Kalamazoo X reset my spirit.

 

  1. having a passion for singing does not mean you can sing and no amount of hard work will change that [↩]
  2. This shouldn't be a point of note, but in an industry traditionally dominated by men, it is [↩]

Change Requests

Much like my previous post on Meeting Etiquette, this is a topic I feel strongly about. I am sure there are good reasons that people will hate some of my suggestions and I'd love to hear them, but here are my views on change requests1 based on my personal experiences.

All work is a change

I loathe projects that differentiate new work from changes to existing work. It creates two different process flows for little gain, creating points for confusion and mistakes. If all work items, whether new features, bug fixes or enhancements to existing features are raised as change requests, the work flow is the same. Everything should be tied back to requirements, regardless of the type of work, so arguments that claim there is a difference just don't wash with me. Consider a new feature as a change from not having it to having it, after all, that's exactly what it is.

Whatever the work is that is being conducted must still be implemented, reviewed and tested against requirements. Why make it harder than it needs to be?

Specify requirements, not solutions

There are many times I've been assigned a requirement that tells me how to fix something, not what needs fixing. Let's face it, everyone has an opinion but change requests are not the place to express them (except perhaps as a suggestion in the comments somewhere). A change request should clearly state the requirements that drive the change (i.e. the things that can be used to identify when the change request has been resolved) and any other information that may help (for example, steps to reproduce a bug or some rationale behind the change required).

Be descriptive

If I see one more change request with a summary or title like "Change to menu dropdown" or "Display control update", I will be rather miffed and may hurt someone (I'm British, "miffed" is just above "peeved" on the British Standards Anger Scale2). The title of a change request is very important and should give a clear indication of what the change request actually requires. Think of it a bit like twitter; it's much nicer reading some useful information in a tweet than it is to learn that someone just had a coffee. If the title is not clear, time is wasted in going to look at the description every time someone sees that change request. Every status meeting, every discussion, click click click. Save everyone the effort and get it right first time, and if you spot a title that isn't clear enough, fix it right away.

Add value

Finally, when adding comments, additional description, attachments or anything else to a change request, make sure it adds value. Leave an trail for those who follow in your footsteps so that they can discover what changed and why. Document important discussions and decisions. If you don't, you are destined to go around in circles.

Manage releases by managing change

Target changes at releases and review new changes regularly. This way, new requests raised during that release cycle can be considered for inclusion and deferred changes can be ignored until after the release. Each time a new release is started, review all the open requests and determine if they should be rejected, deferred or included in that release. Justify and document rejections in case a duplicate is raised and make sure to link duplicate issues as they can add value to one another.

Have meaningful states

I feel that there are the following possible states for a change request in any sane process to manage them.

  1. Raised
  2. Assigned
  3. In progress
  4. Ready for review
  5. Passed review
  6. Merged to trunk
  7. Rejected
  8. Closed

These are clear, unambiguous states.

  • If something is marked as "Raised", it hasn't been assigned to any release and no work should be happening on it.
  • If it's "Assigned", it should be targetted at a release (even if it's only intended for investigation at first – it can always be removed from the release back to "Raised" or rejected and closed).
  • If someone is working on something, that something should be marked as "In progress" as this helps to track progress at a glance and can also be useful if resources become available and things need reassigning.
  • If something passes testing, close it, unless you really don't trust the test team, in which case have a "Passed test" state and then review the results before closing3.

Considering these basic states, the workflow looks something like this:

State flow diagram
State flow diagram

You could add additional states if you so desired but I feel that these cover the bases well enough and provide an easy to follow work flow.

Closed means closed

Change request management gets messy when the process allows for closed requests to be re-opened. If a closed request seems like it really is now needed, raise a new request. Don't close change requests just because they aren't being done right away; if it's a real issue, then it should remain open until it is resolved.

Not always, but mostly

The guiding principle for me when it comes to change requests is simplicity. Don't make your process more complicated than it needs to be. Make it easy to follow and hard to get wrong. While I'm yet to encounter a project that required anything different to what I've suggested, I am certain there are exceptions, so if you have any, let me know. This is often a contentious, polarising topic, so I expect someone, somewhere to emphatically insist I am wrong. I can accept that, so I look forward to finding out even better ways to manage change.

  1. I made that up [↩]
  2. You may also know them as issues, bugs, defects or some other moniker that ultimately means "a repository of things to do". [↩]
  3. Flippant remarks aside, this may be valuable if you need to perform a round of customer acceptance testing after internal testing before closing out change requests. [↩]

Ann Arbor Day of .NET

On Saturday (29th Oct), I attended the Ann Arbor Day of .NET. I thought it would be nice to summarise what I heard. I doubt these notes on their own will be greatly useful, but I hope they act as a launch pad into deeper dives on the topics covered as well as a review of what topics were covered. There were five different tracks for the day: Cloud, Framewords & Platforms, Soft Skills, Tools and Mobile. I chose talks from the first four of these based on the talk itself, rather than the track to which it belonged (I ruled out presentations that I had seen a variation of before such as David Giard's (@DavidGiard) Introduction to Microsoft Windows Workflow and Jay R. Wren's (@jayrwren) Let's Go to C# On The iPhone, though they were excellent when I saw them).

Be A Better Developer

I started out the with Mike Wood (@mikewo) and his session, Being A Better Developer. This was a soft skills talk, meaning it was not there to show off some cool .NET feature or technology, or teach me all about C#. Instead, the focus was on what makes a great developer and what we can do to attain that status.

Mike explored the various roles that developers have to take on, the hats we have to wear. From the student learning new things everyday, to teacher imparting knowledge to those around them. From janitor—maintaining what already exists, to researcher—investigating and choosing frameworks, languages, platforms, etc. Using these roles as a foundation, we then moved on to some tips such as setting up time blocks in which to work. If the time limit is reached and the problem isn't solved, turn to someone else for help (or somewhere else, like the Internet1) to avoid thrashing and time wasting. This seems somewhat obvious and yet I'm betting that many of us don't do it as often as we should. The other tips were equally useful, obvious and often compromised in our daily development lives:

  • organize
  • prioritize
  • know your tools
  • set SMART2 goals
  • be a catalyst for change
  • be lazy…

Right, that last one is maybe a little less obvious, but the point wasn't: don't do more than you have to.

One of the best pieces of advice from this talk was to choose a good mentor. I was very fortunate when I started out my career to have several excellent mentors and I miss working with them almost every day. Even now, I imagine what they might have said in order to guide my efforts3. For an hour, Mike filled that role.

There was much more to this talk than what I've written here. This session was an excellent way to spend an hour. While much of what Mike presented could be considered commonsense, it was reassuring and also provided some new tricks for my arsenal to be deployed in any situation, not just day-to-day software development.

Things to check out after this talk

How I Learned To Love Dependency Injection

Next, on to James Bender (@jamesbender) and his presentation on how he much loves dependency injection4. This talk started out looking at the way things were and the ideas behind a loosely-coupled system; a system where each component knows as little as possible about the other components in its parent system, whether it uses the services those components provide or not. Tightly-coupled systems don't promote reuse, create brittle systems and are inherently difficult to test.

James told a compelling story, starting out with familiar concepts—a constructor that takes various interfaces through which the created object can obtain various services, the factory pattern, etc., but soon we were looking at an overview of dependency injection frameworks, what they do and how they do it.

And then, code. Code about cooking bagels. The only bad part about this was the lack of bagels to eat5. The talk moved quickly on to the various features of Ninject, an open source dependency injection framework. I would've preferred it if there was more emphasis on dependency injection, using Ninject to provide examples, rather than the "how to use Ninject" approach that was given. However, this was still very informative and laid a path towards the next part of the talk which showed how dependency injection and TDD6 go hand in hand. This in turn led to an introduction of mocking (the mock framework of choice in these examples was Rhino Mocks, but James recommended Moq for new work).

Things to check out after this talk

A Field Guide for Moving to the Cloud

We're back with Mike Wood (@mikewo) for this one. I've never done any Cloud development but I'm really interested in it and what it may do for me and the work I do, so I'm hanging a lot on this introduction (no pressure, Mike).

Mike started off with a Batman reference, tying the reason why I'm so tired (Batman: Arkham City) with the reason why I'm here. He then fired off some acronyms: IaaS, SaaS, PaaS. This is a great starting point for me as terminology is often the last refuge of miscommunication and I hate not understanding what all those acronyms and terms mean. One participant immediately asked, "What's the difference between IaaS and PaaS?" and most of us nodded, realising we didn't know either. To paraphrase, IaaS gives the most control as you're responsible for patching your OS, upgrading the frameworks, etc. PaaS manages all that for you. Mike did a great job explaining this (unlike my paraphrasing—Mike used a whiteboard and everything) and we moved on, that bit more informed and ready to learn more.

At this point, Mike gave us a run through of the Windows Azure platform, again making sure we're all talking the same language as the presentation progresses. Mike's presentation style is nice and fluid, taking questions and interruptions in his stride, and he clearly knows his topic well (Mike is an Azure MVP, after all). He walked us through the various parts of Windows Azure, Microsoft SQL Azure and Windows Azure AppFabric before we moved on to planning for our move to the Cloud.

Mike discussed identifying suitable applications for moving to the Cloud, scale of the application and the independence of scale, the services used and tight integration with loose coupling (not the first time we've heard this today but I would hope, not the first time in our careers either, otherwise, you're doing it wrong), usage patterns, latency, security and many other facets to be considered when moving to the Cloud.

The final point related to whether the move would save money or not and the importance of answering that question before making the move. This kind of information was great to see and may prove very useful when talking with project managers or business development types. Mike also pointed out using techniques like multipurpose worker roles and disposable compute instances to save as much as 50% in costs.

And then it was lunch.

Things to check out after this talk

Develop IT: Intro to PowerShell

I admit it, I have only ever used PowerShell for things that I could've done from a regular command prompt, so this talk was one I didn't want to miss. I want to know more so I can do more. I feel like PowerShell is an exclusive club for productive individuals and I'd at least like to take a look inside, so this was my opportunity. Sarah Dutkiewicz (@sadukie) was the presenter for this session, a C# MVP and co-author of Automating Microsoft Windows Server 2008 R2 with Windows PowerShell 2.0. This talk was entirely presented using PowerShell, which certainly made it stand apart from other presentations given so far today.

The initial examples given by Sarah quickly demonstrated how PowerShell provides similar behaviour to the traditional command prompt but also how it is different, providing .NET objects (dir w* | Get-Member demonstrated how dir provides an object—very cool). We then learned all about the standard PowerShell syntax that provides an easily dicoverable set of commands (known as Cmdlets in the PowerShell world) and some useful Cmdlets like Get-Help and Out-GridView (which outputs things to its own filterable grid in a window).

Sarah continued introducing us to a variety of PowerShell concepts and features including but not limited to:

  • functions
  • modules
  • manifests
  • PowerShell ISE7
  • providers
  • aliases
  • registry interaction

My biggest takeaway is how easy it can be to work with the registry from within PowerShell (just open PowerShell and enter cd hkcu: then dir to see what I mean). Overall, a great introduction that has given me a starting point for exploring PowerShell and becoming more efficient.

Things to check out after this talk

Stone Soup or Creating a Culture of Change

For the final session of the day, I rejoined James Bender (@jamesbender). I was really looking forward to this having faced many challenges in changing culture as part of my efforts for meeting the requirements of CMMI8. This was expected by event organisers to be a popular talk and I still feel that it should have been; however, the turnout was disappointingly low. This made for a more intimate session and certainly did not detract from the informative content. James expressed that this was probably the last time he would present this talk, which is a shame as I found the anecdotes and the lessons that were drawn from them to be very insightful.

The things I've learned will definitely help me in my work and elsewhere. Things like:

  • Go for low hanging fruit
  • Don't change too much at once
  • Support the change and let it simmer
  • Don't judge
  • Know your tools
  • Only introduce changes you believe in
  • Understand the business
  • Know when to say when
  • Evangelize
  • Build a network of like-minded people
  • Be a politician
  • Be a therapist
  • Realise that it might be difficult to reach everyone
  • When all else fails, buy doughnuts
  • Be patient

There's not much more I could say about this talk that would do it justice (not that my notes have really given justice to the earlier talks), but suffice to say this presentation was very relevant to me and I am very grateful to have been able to see it.

Things to check out after this talk

To conclude, I had a great day. The organisers, sponsors and speakers deserve a huge "thank you" for setting up and supporting this event. Wandering the hallways of Washtenaw Community College, attending talks in rooms and lecture halls reminded me a little of being back at university, but the speed at which the day flew by certainly did not. It was a very informative and enjoyable way to spend the day and among the best $10 I've spent this year.

  1. Use Internet search before you ask someone. [↩]
  2. Specific, Measurable, Achievable, Realistic/Relevant, Trackable [↩]
  3. Besides, "Shut up, Jeff!" [↩]
  4. An appropriate amount as allowed by law. [↩]
  5. Mmm, bagels. [↩]
  6. Test Driven Development [↩]
  7. Integrated Scripting Environment [↩]
  8. Capability-Maturity Model Integration [↩]