Tag Archives: Proving It

Rocking your skills in February

02 Monday Feb 2015

Posted by in Development, Programming

≈ Leave a comment

Tags

, , , ,

Microsoft have set out a challenge for February through the Microsoft Virtual Academy to Rock your skills over the month through a series of Challenges based on 8 different tracks:

  • Cloud Development
  • Game Development
  • Mobile Development
  • Web Development
  • Hybrid Cloud
  • Identity & Access Management
  • Office 365
  • Sharepoint

I have decided to opt for the Identity & Access Management stream which is 38 Hours of learning and challenges;

Take the challenge to effectively implement identity and access management solutions across diverse devices and hybrid environments that require a strong foundation of skills from enabling single sign-on to extending your domain with Azure AD

This is a good initiative from Microsoft showing how you can group the training available in MVA to a set of identifiable skills in the industry instead of the single courses.

A balance of Verifiable and Non-Verifiable CPD

23 Friday Jan 2015

Posted by in Development

≈ 1 Comment

Tags

, , ,

The next comment I want to analyse from the CPD and Learning Survey is:

Given the speed of change in IT, I think an average of 2 to 3 hours per week in a mix of verifiable ( e.g. courses (on-line or physical)) and unverifiable- Blogs, papers, news sources, hands on etc.should be a minimum to aim for.

This is a great comment that supports CPD (Continuing Professional Development) in general.

2 to 3 hours a week is a great way of splitting development and learning over a calendar year.  Minus a 4 week holiday, this would give anywhere between 96 and 144 hours of training which is almost double what the CPD and Learning Survey came up with as a recommendation for the amount of time spent on CDP Development. This is not a bad thing at all as spreading training out allows you to learn, digest and try out the things you have learnt.

As the world of technology is developing and moving at a very fast pace, spreading the learning out allows you to change direction if needed to a new area that you need to focus on.

Identifying your training into two main categories of Verifiable and Non-Verifiable is a normal requirement of most CPD recording systems and industries.

Verifiable is where you can prove that the training has been completed such as:

  • Attendance on a Course (Course Certificate)
  • Online Course – Certificates of completion
  • Online Course – Test results
  • Vendor Certifications
  • Research with a resultant paper published
  • Brown Bag training (Lunch and Learns) where attendance is recorded

Non-Verifiable is where you cannot prove the learning but have carried out self learning. This includes:

  • Reading of industry magazine articles / technical reading
  • Reading blogs
  • Courses not offering any certificates of completion or test results
  • Learning as part of meetings and on job training
  • Learning as part of an assigned Project (unless any of the Verifiable results can be achieved)

These lists are by no means exhaustive or may alter depending on which governing body the CPD is for, but show examples of what could be classed in each category.

There is no hard an fast rule on how much Verifiable vs Non-Verifiable should be achieved as part of any CPD, however it is always better to have a Verifiable as it is easier to prove the learning. I would suggest a 60/40 or 70/30 split in favor of Verifiable.

“If it’s obvious prove it. If you can’t prove it, it’s not obvious.”

05 Friday Dec 2014

Posted by in Governance

≈ 1 Comment

Tags

,

This is a phrase that I use a lot and I first came across many years ago from someone I previously worked with. Since then it has stuck with me.

When writing documents how often do we assume that the reader will know what we mean or understand that just because we know something is there that they do. I have seen many occasions and have fallen into the trap occasionally myself where you write about something in the manner that you know all the facts but don’t convey them.

An example of this could be a proposal or technical document;

The device has two power supplies;

  • To a technical mind the instant reaction might be that this will probably be connected to two separate power supplies and backed up by generators and UPS.
  • To a financial mind the instant reaction might be that this is extra cost not justified.
  • To the engineer who checks the proposal – I wonder how thats going to be configured?

Where in fact the writer forgot to mention that the device was a chassis that needed two power supplies to provide enough power to all the devices placed into that chassis and is fed from one power supply.

OK – in reality you should always look for redundancy and in this example that could equal four power supplies, but this example shows how easy one statement can be misinterpreted because it was obvious to the writer and not the reader.

Just food for thought… Try running that phrase against the next document, email, etc that you write and put yourself in the readers place.