none
Creating a skill/concept achievement chart for Powershell (warning: kind of long, over the top and geeky) RRS feed

  • General discussion

  • I recently was reading a book on music about perfect pitch.  The author talks about different levels of ability, and, he graded skills according to the different ways of thinking about music, composition, and, the mindset required to do each.  This idea/discussion got me thinking and was spawned, in part, by this thread:

    http://dev9.channel9.msdn.com/blogs/c9team/Coming-Soon-Visual-Studio-Achievements

    and, a little more tongue in cheek, on this one:

    http://blog.whiletrue.com/2011/01/what-if-visual-studio-had-achievements/

    Those things being said, what/how would you categorize things for someone starting from scratch through that of an expert?  This is, in many ways, completely arbitrary.  But, to mock myself, I am always trying to level up and sometimes don't even know where to jump next.  This may help me see the next few points of interest...as well as help others out when they try to share Powershell.  I figure this can give you a general progression as you help someone to know where to go next.  Honestly, I am trying to be exhaustive (or, as close as possible) and I'm using several books table of contents as the basis for this.  Writing helps me organize my thoughts/concepts. I put a Mindset: comment at the end of each "level" to make it easy to recognize the various shades and Aha! moments for each.

    Level 1: (lost and doesn't know it) ABC's

    • cmdlets 
    • hello world
    • Get-Help
    • tab completion
    • variables: user created/built-in
    • there are versions
    • aliases: using/creating
    • Mindset: I just need to know what to type to get something I can recognize.

    Level 2: (deer in headlights) Words are made from letters

    • New-Object
    • .NET objects/assemblies/reflection
    • common parameters
    • members
    • properties
    • methods
    • pipelining
    • one-lining
    • versions: there's a v1 versus v2 (and will be a v3)
    • types
    • extended type system (ETS)
    • Mindset:  Oh, wait! These isn't text, but, objects I'm playing with.

    Level 3: (the sophomore) Paragraphs are made from words (when used correctly)

    • operators 
    • formatting
    • grouping
    • providers
    • profiles
    • scope
    • type accelerators
    • syntactical structures: dot sourcing, scripts (.ps1)
    • security (configuration/execution policies)
    • code signing
    • Mindset:  I see data like legos, and, am starting to realize I've got a pretty big toy chest

    Level 4: (script writer) Chapters are made from paragraphs

    • customizing output
    • exploring modules
    • functions
    • filters
    • logic
    • scriptblocks
    • regular expressions
    • splatting
    • debugging
    • Mindset:  I think in terms of data types

    Level 5: (developer) Write your own book -- There's always another way to say it

    • v3 starts looking very interesting because they know enough of the difficulties in the current incarnation
    • Add-Type
    • creating modules: script, complied, etc
    • Powershell SDK
    • Advanced functions/parameters
    • input validation
    • extending get-help
    • other technologies (AD, WMI, SQL, file system, registry, ADO.NET, XML, COM, IIS)
    • third-party Powershell tools/Open Source code
    • remoting/WinRM
    • jobs
    • VBScript to Powershell
    • Windows forms, XAML, WPF
    • Mindset:  I know a couple of languages, but, primarily speak .NET and ETS if I get lost and have to find my way back home.

    Level 6: (architect/serious Powershell user) You can pretty much do anything and do it well so think about the larger community

    • best practices 
    • optimization
    • uses engineering to validate various code choices
    • hosts
    • cmdlet development (C#/Visual Studio)
    • dynamic compilation
    • unit testing
    • Internationalization
    • other .NET compliant languages to Powershell
    • serialization/web services
    • PInvoke and unmanaged code
    • recognizing limitations of Powershell and alternative solutions: i.e., pro's cons of the Powershell way
    • design patterns
    • Mindset:  everything is an object. I just went from Newtonian mechanics to Quantum physics.

    Level 7: ("There is no spoon.") Ok, that's just freaky. Is that even possible? (I start getting fuzzy with this area as it's the way out there ideas and I'm not)

    • script fu
    • Powershell as a tool...not an end in an of itself
    • writing new GUI/subsystem extensions/MMC development
    • writing desktop hosts (think the PSShell.ps1 example from Windows Powershell Unleashed, 2nd Edition)
    • reverse engineering
    • Reflector with code to generate .NET from .dll's
    • assembly manipulation/code-injection/rootkits
    • live memory analysis for forensics (or more nefarious intents)
    • Powershell outside of Windows (I hear it's on Linux now...in theory)
    • Objects are just pretty stickers.  Who needs them when I've got YmFzZTY0, x68x65x78x69x64x65x63x69x6Dx61x6C, and, 
      110001011010011101110110000111100101111001. Be one with the data.  Zen of scripting.

    • Edited by Will Steele Thursday, January 5, 2012 2:42 PM additional comments
    Thursday, January 5, 2012 6:43 AM

All replies

  • I think, to some extent being an expert at powershell is like being a
    windows expert... does a windows expert know how to program and support the
    system as well as architect it? nope...
     
    it would be like any course setup, as you get deeper in to it, you
    specialize... in PowerShell there are a few 'paths', the "end user" who just
    knows the basics (helpdesk to run scripts), the "admin" who is good at
    simple functions, and creating quick onliners and knows the shortcuts to get
    things done quickly... the dev admin, who knows how to create more advanced
    functions to simplify tasks that are really difficult.. the "engineer" who
    is a step above the "dev admin" because they are using PInvoke and such to
    really dig deep in to the system... and then there is the "dev" guy who
    writes cmdlets and knows the PS SDK...
     now, go clean up that list and break it up that way and give it course
    numbers and hand it over to MS so that they can get some certs for it!
     
     

    Justin Rich
    http://jrich523.wordpress.com
    PowerShell V3 Guide (Technet)
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Thursday, January 5, 2012 1:02 PM
  • I know this is somewhat arbitrary, but, I used to have a system (which I have since quit using) where I would categorize things based on the number of times I used them.  (I realized frequency is a poor indicator of actual mastery.)  Nonetheless, I would say if I did something x times it got me to y level where:

    • 1 times means I have some raw experience.  This would be like level 1 from above (loosely).
    • 10 times means I have done it enough to see a pattern or two.  This would be like level 2.
    • 100 times means I have started to get enough practice to know the ins and outs of a particular thing. Level 3.
    • 1000 times means I not know how how a thing works but some of the warts, weaknesses, and, limits of a given thing. Level 4.
    • 10000 times means I not only know the limits but when I may want to consider alternatives, why and where to make these tradeoffs. Level 5.
    • 100000 times means I can accurately, and, more often than not, nail things the first time, with 10% of my attempts needing a little tweaking.  Level 6.
    • 1000000 times means I can intuit the applicable approaches (and some unseen ways) to utilize the technology that may not even be possible. Level 7.  Not only are you not wrong at this level, the things you do say are so deep/insightful, most people don't even realize what you're talking about.

    As I said, a pretty arbitrary thing since some can get to level 6 in 5000 operations of a given task...but, this goes to the main concept of that book Outliers where a basic level of practice generally corresponds with a certain level of ability.  It may not be 10,000 hours, but, if you look at that, 10,000 would, using the unit of 8 hour days, 5 days a week, translate into about 3.5 years.  I would say, if someone really studies/uses Powershell every day and really attempts to maximize their understanding, 3.5 years seems about right to get to level 6.  Level 7 is something that I don't think everyone can achieve.  There are some people who will never "get it", but, chances are if you get to level 6, level 7 is just a matter of time, experience and persevering.  

    Last time I checked, I saw that the certification committee was still not even considering a Powershell certificate.

    http://www.windowsitpro.com/blog/powershell-with-a-purpose-blog-36/scripting-languages/why-no-powershell-certification-from-microsoft-137457

    I would say things like MVP awards are clear recognition, but, that goes above and beyond just knowing Powershell.  Perhaps rankings in the scripting games would be an indirect indicator.  I like your scale: end user, admin, dev admin, engineer, and, dev.  At this point, I would say that I could see two certs: 1) the power user/small enterprise admin and 2) the enterprise admin/developer.  #1 would be a basic proficiency. #2 would be the true experts.  Ah, here's to pipe dreams.

    Thursday, January 5, 2012 3:00 PM
  • Hello Will

     

    I am really appreciate your thoughts here.  It's a great article and I think you can add it to the Windows PowerShell Survival Guide later after the discussion.

     

    http://social.technet.microsoft.com/wiki/contents/articles/windows-powershell-survival-guide.aspx

     

    Best Regards,

    Greg Gu


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, January 6, 2012 1:34 AM
    Moderator
  • Some time ago I put together the list below.
     
    There's no definite order to it, but it might fit a bit with what you
    are thinking about.  Not anything "Zen" here, just brainstorming when
    PowerShell was new to me.
     
    "Top 25" PowerShell concepts to understand
     
    - PowerShell executionpolicy
    - PowerShell as command language
    - PowerShell as scripting language
    - PowerShell parsing modes
    - PowerShell data types
    - PowerShell comments
    - PowerShell literals
    - PowerShell providers
    - PowerShell drives
    - PowerShell cmdlets
    - PowerShell functions
    - PowerShell filters
    - PowerShell scripts, including the PATH environment variable
    - PowerShell profile scripts
    - PowerShell interfacing with other script engines
    - PowerShell aliases
    - PowerShell abbreviations
    - PowerShell scriptblocks
    - PowerShell operators
    - PowerShell variables
    - PowerShell control flow
    - PowerShell pipelines
    - PowerShell file input and output
    - PowerShell console output
    - PowerShell is object oriented and leverages the .NET object model
     
     
    Wednesday, January 11, 2012 12:10 AM
  • Wednesday, January 11, 2012 12:25 AM
    Moderator
  • Don Jones is a busy guy!  I hope to meet him some day.
     
    Wednesday, January 11, 2012 12:27 AM
  • On a similar note:

    http://powershellverified.com/

    Hadn't seen that one yet. Have to check it out.  Thanks for the link.
    Wednesday, January 11, 2012 12:34 AM
  • Thanks Larry. Good collection. I have been rediscovering Select-Object hidden nuggets: -ExpandProperty and Expressions.  Little gems for me.
    Wednesday, January 11, 2012 3:37 PM
  • just ran across the description for the five-day MS Powershell course, and was not sure if you had seen it:

        http://www.microsoft.com/learning/en/us/Course.aspx?ID=10325a#tab2

    it seems to cover more areas than your list (i.e. background jobs). But it does not seek to clarify what "level" one might attain according to how much of the course one has covered.

     

    Monday, January 16, 2012 8:41 PM
  • I'm not sure that a strict geometric pattern is applicable to something like this. In any case, which is likely why you have stopped using this system. Anyway, if there is something you have done a million times, that would more likely imply an inability to find an easier way to do it.

    I can only think offhand of a few things I have done a million times (blink, breathe, heartbeat), and am not concerned about not having found simpler alternatives. If you are 30 years old can you think of anything you have done 88 times a day since your birth?

     

    Monday, January 16, 2012 8:49 PM
  • I have run about 60,000 miles in my life.  So, I've put a few steps in. : )

    Point taken.

    Friday, January 20, 2012 4:45 PM
  • just ran across the description for the five-day MS Powershell course, and was not sure if you had seen it:

        http://www.microsoft.com/learning/en/us/Course.aspx?ID=10325a#tab2

    it seems to cover more areas than your list (i.e. background jobs). But it does not seek to clarify what "level" one might attain according to how much of the course one has covered.

     

    Thanks Al.  I appreciate the link.  That whole idea of "level" is arbitrary in regards to real world applications.  It steers more in the direction of conceptual limits.  For instance, I know folks who were great in math as high school students, did pretty well through undergrad, but, hit a wall in graduate school.  In this respect, I think there are conceptual levels some of us may simply not be able to reach.  At the same time, I suspect this limit correlates with exposure to different aspects of Powershell.  Someone coming from the sysadmin side may balk at things like Add-Type because they lack the requisite development experience.  Likewise, and, conversely, someone who is purely dev-oriented may not fully see the implications of some of the AD, Sharepoint, Exchange or IIS cmdlets.  That's one of the things that makes Powershell an even more interesting creature for me: you have to know both sides of the fence to fully harness the power of Powershell.  That is not to say that you can't still get an amazing amount by being skilling on one side of the fence (sysadmin) or the other (dev).  Reminds me of the right brain/left brain debate.
    Friday, January 20, 2012 5:05 PM
  • I'm definitely on only the "dev" side of that fence, and am having fun at least picking up some
    vocabulary of the "sysadmin" side by eavesdropping.
     
     
    Friday, January 20, 2012 6:17 PM
  • I think there's at least one more "hat" being worn in the Powershell audience - Integrator. 

     I'm mostly a sysadmin, and I occasionally go visiting on the "developer" side of the fence, but I also get called on to find ways to make disparate systems from different vendors work and play together, sometimes in ways neither vendor anticipated their product being used. That work doesn't quite fit into either the sysadmin or the developer pigeon hole.

    In that environment, Powershell is Swiss Army knives, duct tape, and zip ties all rolled into one.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Friday, January 20, 2012 6:36 PM
  • Ah, you busted me with my false dichotomy: dev or sysadmin. : ) I would say I fall more into the niche you mentioned mjolinor.  I often jokingly ask if people need duct tape or WD-40 when I offer to script.  I'll have to remember zip ties for my analogy.  Those come in handy too.
    Friday, January 20, 2012 6:38 PM
  • I do that a lot, but I wouldn’t consider that another role. I am a sysadmin
    and its my job to make the systems work together and automate everything I
    can.
     
    I think that is more a combo of the two roles rather than a different role.
    That would be like saying the person who handles storage and servers is a
    special role. I feel it has more to do with the company/environment size as
    well as skill level.
     
    In order to integrate systems you need to fully understand how the system
    works and how to get data out of it as well as be able to code the
    transforms, which as you've hinted at is more than the typical admin coding
    ability.
     
    so as far as "course" paths that type of person would want to head down both
    paths.
     
     

    Justin Rich
    http://jrich523.wordpress.com
    PowerShell V3 Guide (Technet)
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, January 20, 2012 6:49 PM
  • Hmmm...  I see integrator as being a valid role, at least for me, because puts a label on what I do quite nicely.  I am not a developer by nature (although I can go there) and I am not a sysadmin (but it can be done if necessary).  For me, it really is more about using whatever tools I can to get the integration done.  Getting off topic now, but, I see sysadmins as key to keeping things up and running (stability is the focus).  Developers create the tools for end users and sysadmins to work (tools are the focus).  But, integrators are not expected to focus on stability or tools.  Both are important, but, their job is targeted elsewhere.  For instance, if we have a major SQL configuration change on our system, I'm going to let a SQL DBA or dev deal with that.  However, if I am working with a customer, some of the contorted hacks I come up with to combine data into viable business solutions make no sense to either the dev or the admin.  For me (the person for whom the business/integrations are key) my main focus is the project, not the environment or tools used to build/maintain it.  Hence, my non-technical title: warehouse manager. : )  Sorry, logistics analysis specialist.
    Friday, January 20, 2012 7:01 PM
  • I think you can argue it's neither or both, but either way it doesn't always come down to being an either/or situation.
    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Friday, January 20, 2012 7:02 PM
  • Do your solutions have a long "run" (in the theatrical sense of being performed again and again
    over a long span of time), or are they one-time performances?
     On 1/20/2012 1:01 PM, Will Steele wrote:
    > ,,,  However, if I am working
    > with a customer, some of the contorted hacks I come up with to combine data into viable business
    > solutions make no sense to either the dev or the admin. For me (the person for whom the
    > business/integrations are key) my main focus is the project, not the environment or tools used to
    > build/maintain it. Hence, my non-technical title: warehouse manager. : ) Sorry, logistics analysis
    > specialist.
     
     
    Friday, January 20, 2012 7:08 PM
  • Do your solutions have a long "run" (in the theatrical sense of being performed again and again
    over a long span of time), or are they one-time performances?
    Um... Both, actually.  We deal with customers whose data is processed once.  But, since I work in a niche industry (document imaging) many of the same vendors work with our customer base.  When we get new customers it is common to see data from a new customer that is retrieved from a system we have worked with before.  So, while the data is new, the formats, tables, structures, and, techniques used to process it are not.  In this sense, I often just modify variables in my scripts, and, things run smoothly without having to be reinvented each time around.  Plus, I do a lot of cookbook and templating since the processing is very repetitive, even though minor aspects of the data storage structure change.
    Friday, January 20, 2012 7:17 PM
  • Hence, my non-technical title: warehouse manager. : )

    Mine is Tactical Logician. :)


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Friday, January 20, 2012 7:34 PM
  • mine is Sr Systems Magician
     
    who comes up with these things?!
     

    Justin Rich
    http://jrich523.wordpress.com
    PowerShell V3 Guide (Technet)
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, January 20, 2012 8:28 PM
  • I think you are actually just proving my point.. there are two different
    items here...
     
    Skills
    Job Role
     
    you are talking about the job role and what it takes to complete it where as
    im talking about skills sets. and as I point out, for you rob and myself we
    play both sides of the fence and our skill set must be fairly heavy on both
    sides.
     
    maybe im looking at this wrong but for the idea of achievements/skills we'd
    want to be able to say we are very knowledgeable in both areas.. which, is
    what makes us good integrators...
     
    maybe we've gone too far off topic and are talking about two very different
    things.
     
     

    Justin Rich
    http://jrich523.wordpress.com
    PowerShell V3 Guide (Technet)
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, January 20, 2012 8:32 PM
  • Good differentiation between skills and roles.

    I think I felt a bump back there a few posts ago. Seems like I hit a shark and went airborne.

    Friday, January 20, 2012 8:37 PM