This Week's Music

When I'm in the zone working I tend to like some music to listen to, but the radio stations aren't always playing what I want and auto-generated radio stations on Spotify or Pandora or some other service aren't varied enough for me. So, I build my own playlist on Spotify for each day. Because picking songs for a playlist can be time consuming if you just try to think of songs, I build the playlist by chaining them via the "Related Artists" tab for each song's artist. To start, I usually have a song or two leftover from the previous day, so I use the artists related to that song's artist. I pick a band or singer from the list and then choose one of their songs as the next in the playlist and then use their related artists to pick the next song and so on and so forth until I've built enough songs for the day. I usually avoid repeating an artist or song just to keep things eclectic and I don't always pick songs I know. This is a little more time consuming than just sticking on a radio station, but I think it's worth the effort. I get a varied range of music and artists while having some level of continuity between the songs.

Since I have a playlist for each day I've done this, I thought I'd share them here on my blog¹). I won't post my old ones, you can go to my Spotify profile for those, but here are the playlists for this week².

Monday

Tuesday

Wednesday

Thursday

Friday

I also share these on Twitter each day, although they are subject to change during that day and the next as I tend to add more tracks if I work longer and remove them if I didn't get chance to listen to them that day (I carry them over to the next day's playlist as a starting point [↩]
I'm posting this on Friday, so don't be surprised if that playlist changes [↩]

Lessons from an ever changing career in software development

At the end of last year I came to a terrifying conclusion; it was time to look for a new job. I was terrified because I had not been through the process of proper job hunting in over 12 years and because, though I had a job, I knew I would not be happy if I stayed in it. I had worked in the same organisation for over a decade and though I had worked several different jobs and faced many challenges, this felt like the biggest (yes, even bigger than when I moved to the US).

The story of my career and this move is too long for this post¹, but after transitioning from university to a job, from Motorsport to automotive and now healthcare IT, and from the UK to the US, I have learned a few things along the way and I believe they are universal. Perhaps you feel something is wrong and you can't put your finger on it, or maybe you want to try something new but are frightened of what where that might lead; just knowing others go through similar emotions can be incredibly helpful, so I'm sharing what I've learned so far.

Look for opportunity
It seems strange and I certainly didn't get this for a long time, but you won't recognise an opportunity unless you are already looking for it. I look back on every major change I made in my life and can see how this was true for each and every one, whether it was going to university, farming Ostrich, or moving to the US.
Know what you want
In order for you to recognise that opportunity, you have to know what it looks like and more importantly, what it does not. List the things you want in a job and take note of the things you don't want. Don't just think about the technical side of things, be sure to consider the culture you'd like to work in too. This also helps in recognising when it is time for a change.
Learn the signs that it's time to change
Too often we can ignore the little things that indicate a bigger problem and pass them off as having a bad day or working with annoying people. In reality, these are often signs of a wider dissatisfaction that needs to be addressed. It's easy to ignore the little problems when you're enjoy what you do, but once the enjoyment is gone, those little problems get bigger. Has there been a cultural change within you or the organisation? Are you not getting things from your work that you used to? Take stock of your situation and work out what you do and don't want from your job then see if it matches. If it doesn't, work out what you need to do to fix it. Sometimes all you need to do is make some simple changes to the way you work, sometimes you'll need a whole new workplace, but recognising this before you start burning bridges is really important, for you and your colleagues.
Don't burn bridges
It is tempting when making a change (or in the throes of realising that you need to) to tell people what you really think of them or their job. Resist this urge. Unless you are truly coming from a well-intentioned place and you are certain that the other party is willing to hear what you have to say, it is best to keep it to yourself. Usually, it is best to keep it to yourself. I was once told to be nice to people you meet on your way up in your career because you never know who you'll need when you find yourself on the way back down. I didn't listen. I have one less bridge.
Don't be afraid to ask questions
Whether in an interview or just in your every day work, ask questions. If you don't know something and you want to know it, ask someone. I have learned this the hard way. Knowing when it's time to ask instead of continuing to blunder around in the dark is really important. You may feel like you're stupid or weak somehow for asking, but asking is far better than finding yourself in a job you hate or without a job because you spent too long not knowing what you were doing. Sometimes, this can even help avoid the need to change your job in the first place.
Know your own mind
Learn to recognise when fear is clouding your judgement. When we're afraid to try something, we're great at convincing ourselves that we're right to just not. For example, some people turned down the same opportunity I took when I ended up moving to the US because they "owned houses" or "had a family"². While compelling, these excuses aren't truly impassable obstacles like those who utter them would have us believe. A person who is content and doesn't want an opportunity is surely more likely to just say, "no", but those who are afraid will find excuses instead. If I had let my fear of the unknown take hold, I could have found a hundred reasons why I just couldn't move to the US (it was only for a month or so originally, anyway), but instead I identified what might make the move difficult and I addressed it.

While I've focused on career change here, many of these things apply to life in general. I hope that you find them useful. Perhaps you have some tips of your own. Please feel free to comment and share them with the rest of us.

perhaps another as I did just write it while prepping this one [↩]
As if I'm some mutant who just appeared one day, parentless and alone. Apparently, this phrase "have a family" only has true meaning if you're married with kids…please… [↩]

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 requests¹ 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 Scale²). 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.

Raised
Assigned
In progress
Ready for review
Passed review
Merged to trunk
Rejected
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 closing³.

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

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.

I made that up [↩]
You may also know them as issues, bugs, defects or some other moniker that ultimately means "a repository of things to do". [↩]
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. [↩]

Meeting Etiquette

If you have any kind of interaction with others during your working day, you have no doubt encountered terrible, time wasting meetings. Meetings where no one seems to know what's going on, the topic meanders here and there and very little is accomplished. Badly run meetings like that are a bug bear of mine. Though I have been caught behaving badly in meetings myself (talking too much, not listening enough, etc.), I have learned to be better because a meeting is one of the most expensive, least productive parts of the day, so it's better for everyone if the meeting is effective.

What makes a meeting effective? Well, for me, an effective meeting is one where all the attendees are relevant to the discussion, there is a clear goal in mind and someone chairs the meeting to ensure that goal is achieved. To that end, each meeting should meet four basic requirements:

1. Must have a realistic agenda stating meeting structure and goals
2. Must have only relevant attendees
3. Must have proper equipment prepared and ready
4. Must have a chairperson

Agenda

Contrary to the belief of a few individuals I've worked with, the agenda does not have to take up the better part of a novel. In fact, it should be short and concise so that there's a high chance everyone has read and understood it before attending the meeting. If you make the agenda too long, everyone will show up without having read it. Of course, there's still no guarantee that even with an easy-to-read agenda those who show up for your meeting will have read it. Therefore, the first thing to do in the meeting is read the agenda aloud so that everyone present is aware of why you're all there. Also, make sure to let everyone know who is present, especially if some people have never met or there are remote attendees via phone conference.

The agenda should also be realistic. Don't schedule a half hour meeting and then cram in an hour's worth of agenda. The goals of the meeting should be achievable in the allotted time. In addition, make sure that appropriate time is set aside for starting up and closing down the meeting. You'll need time to set up equipment, introduce the agenda and attendees and review actions; there is no magic clock at the start and end of meetings so make sure you account for these activities.

Relevant attendees

We've all been sat in a meeting wondering why in the world we're there. The right thing to do in those situations is leave, but that's a bit of a gutsy move 30 minutes into your boss' presentation. The point is, if you're not adding value to or getting value from the meeting, you shouldn't be there running the risk of taking value away from everyone else. If you receive a meeting invitation with an agenda that looks decidedly outside your bailiwick, ask the organizer why you're included and consider suggesting someone more relevant to attend. It is perfectly fine to not show up to a meeting from which you won't gain anything and that won't gain anything from you. However, it is not fine to accept a meeting invitation and then not show up. Show courtesy for the organizer and other attendees by either not accepting in the first place or by giving plenty of notice that you won't be able to make it (in some situations, this may not be possible, but those situations are exceedingly rare).

On the flip-side, if you're organizing the meeting, write the agenda first and then decide who should be present. Consider what value they will add to or gain from the meeting. Consider personalities and what might work for or against the agenda (that doesn't mean you shouldn't invite people who's personalities might clash, but it does mean that you should consider it and how it may impact the discussion). Make sure that everyone on the list is on it for a valuable reason (I personally dislike the optional attendee; if someone is optional, they aren't needed by definition and shouldn't be included).

When you do attend a meeting, try to be respectful of the others in the meeting. Be assertive but avoid talking over people, shouting and other overly aggressive conduct as it can stifle discussion. Try to give opportunities for everyone to have their say. This is something that I personally have had to work hard on in my career as I tend to talk a lot and repeat myself to get my point across. I can also be quite stubborn if backed into a corner. Being aware of your own personal flaws in meetings is important, so if you don't know what they are, ask your colleagues. You may not like what you hear, but you can use it to your advantage. If you're a talker, try to talk less. If you're naturally quiet, look for opportunities to assert yourself.

Proper equipment

In my office, it is not unusual for back-to-back meetings to be organized. This is quite frankly ridiculous. Before any meeting can begin, the organizer or their appointed lackey must have opportunity to check the relevant equipment is in place and working, but usually we don't allow time for this activity. Instead, the attendees sit and wait for this activity to be completed. This is the side-effect of our Outlook-driven, half-hour block meeting organisation habits. In a perfect world, I would like the first five minutes of every meeting to be set aside for the organizer to check that all the meeting equipment is ready – that includes the room, projector, telecommunications and anything else you might need. If you need more than 5 minutes, consider booking a bit of time before the meeting for just you and the room so that you can set up. No one likes watching someone else flail with technology and it can quickly derail any meeting, so get it done privately beforehand.

Chairperson

You've invited the right people, given them a clear agenda with achievable goals and made sure all the required equipment is set up, but without an appropriate chairperson, the meeting is likely to go nowhere. Every meeting needs someone that will keep everyone else on topic and on track. The chairperson should be someone that grasps the concepts being discussed in the meeting but isn't necessarily involved. This way they can have an objective view of the discussion and spot rambling, off topic discussions and other destructive behaviours before they get out of hand. If something comes up that was not on the agenda, the chairperson can note it as an action for another time, avoiding a costly sidetrack.

You'll spot any meeting where there is an ineffective or total lack of a chairperson (they're the meetings where long pauses occur as people decide who should speak next or what topic should be discussed), whereas a meeting with an effective chairperson will often end early. By being outside of the main discussion, the chairperson is free to focus on the goals and keep track of what actions and decisions have been made. This has the wonderful side-effect of saving time; when the goals are met, the meeting is done, even if it's done early. This avoids the common situation in meetings where someone says, "Well, we've finished early, so does anyone have anything else." This phrase is a sure fire way to run over time and get nowhere.

If you've never been a chairperson, find an opportunity to give it a try. It's a great learning experience as it gives a very different perspective on a meeting

One size fits all

There is no doubt that there are other things you can do to have more effective meetings (apparently, stand-up meetings are quicker at reaching the same conclusions as sit down meetings), I am certainly no expert, so tailor your meetings to suit your specific domain. However, these four basic requirements should fit pretty much any meeting so give them a try and let me know what works for you. Perhaps you've got some tips or tricks yourself.

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 Internet¹) 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 SMART² 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 efforts³. 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 injection⁴. 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 eat⁵. 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 TDD⁶ 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 ISE⁷
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 CMMI⁸. 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.

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