{"id":351,"date":"2010-09-06T18:37:18","date_gmt":"2010-09-06T17:37:18","guid":{"rendered":"http:\/\/fragile.org.uk\/?p=351"},"modified":"2010-09-06T18:37:18","modified_gmt":"2010-09-06T17:37:18","slug":"how-to-appraise-a-developer-resources","status":"publish","type":"post","link":"https:\/\/fragile.org.uk\/index.php\/2010\/09\/06\/how-to-appraise-a-developer-resources\/","title":{"rendered":"How to appraise a developer (resources)"},"content":{"rendered":"<p>This post provides support and resources for the <a title=\"How to appraise a developer | fragile\" href=\"http:\/\/fragile.org.uk\/2010\/09\/how-to-appraise-a-developer-part-1\/\">&#8216;How to appraise a developer&#8217;<\/a> series, If you haven&#8217;t read the series this post will make no sense whatsoever.<\/p>\n<p>There are two main sections<\/p>\n<ul>\n<li><a href=\"#KA\">A description of suggested Knowledge Areas<\/a><\/li>\n<li><a href=\"#CE\">A set of examples to help map real world performance in specific a Knowledge Area to a Capability Level<\/a><\/li>\n<\/ul>\n<h2><a name=\"KA\">Suggested Knowledge Areas<\/a><\/h2>\n<table>\n<tbody>\n<tr>\n<td width=\"140\"><strong>Knowledge Area<\/strong><\/td>\n<td><strong>Description<\/strong><\/td>\n<\/tr>\n<tr>\n<td>Coding<\/td>\n<td>The creation of software according to a specified   design. The primary activity is creating code and configuration data to implement functionality using the selected languages, technologies, and environments.<\/td>\n<\/tr>\n<tr>\n<td>Design<\/td>\n<td>The bridge between requirements and construction,   design defines the structure and dynamic state of the system at many levels of abstraction and through many views.<\/td>\n<\/tr>\n<tr>\n<td>Technology<\/td>\n<td>The use of tools, technology, methodologies, and   techniques for software engineering.<\/td>\n<\/tr>\n<tr>\n<td>Operations<\/td>\n<td>System installation, deployment, migration and investigation.   Working safely with live systems.<\/td>\n<\/tr>\n<tr>\n<td>Requirements<\/td>\n<td>Working with partners\/commercial colleagues on an   ongoing basis to translate their ideas into something that can be tackled in software.<\/td>\n<\/tr>\n<tr>\n<td>Quality<\/td>\n<td>Activities performed associated with providing confidence that a software item conforms or will conform to   technical requirements. Quality is related to testing   but considers broader questions such as what strategies necessary to ensure systems work as expected.<\/td>\n<\/tr>\n<tr>\n<td>Testing<\/td>\n<td>Practical means to verify behaviour of a component   through unit testing, system\/functional testing or manually. Testing is related   to Quality but focusses on the practical aspects.<\/td>\n<\/tr>\n<tr>\n<td>Documentation<\/td>\n<td>Activities associated with recording or expressing   information about a how a system works.<\/td>\n<\/tr>\n<tr>\n<td>User Interface Design<\/td>\n<td>Designing clear, discoverable user interfaces so that   Partners are able to make full use of our systems.<\/td>\n<\/tr>\n<tr>\n<td>Internal Relations<\/td>\n<td>Ability to communicate with and relate to those within the company.<\/td>\n<\/tr>\n<tr>\n<td>Client Relations<\/td>\n<td>Ability to communicate with and relate to clients.<\/td>\n<\/tr>\n<tr>\n<td>Supplier Relations<\/td>\n<td>Ability to communicate with and relate to technical suppliers.<\/td>\n<\/tr>\n<tr>\n<td>Project Management<\/td>\n<td>Resource,task and process management, essentially   making sure the right things get done.<\/td>\n<\/tr>\n<tr>\n<td>Line Management<\/td>\n<td>Pastoral care, support and development &#8211; most commonly   relating to direct reports.<\/td>\n<\/tr>\n<tr>\n<td>Recruitment<\/td>\n<td>Includes CV assessment, interviewing, strategic direct   recruitment.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2><a name=\"CE\">Capability Examples<\/a><\/h2>\n<p>Below follows some examples to help with assessing a individual&#8217;s Capability level for a given Knowledge Area.<\/p>\n<p>The examples are not exhaustive and should be added to over time, what&#8217;s more it is not necessary for the employee to satisfy all examples. The examples aim to answers questions like &#8220;What does a Practitioner in Design look like?&#8221;<\/p>\n<p>Before diving into Knowledge Areas specific examples it&#8217;s worth considering the following broad guidelines that can be applied across all Knowledge Areas.<\/p>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Rarely coaches others.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Looks to the team for support and guidance.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Occasionally coaches others, usually those at Introductory   level<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Occasionally introduces new ideas and practices to the   team.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Regularly coaches others, their own skills and expertise   are amplified through the help that they provide.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Regularly introduces new ideas into the team with examples   of where these ideas have been adopted.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Coding<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can complete simple 1 week (ish) well spec&#8217;d tasks\/stories   alone with some guidance from outside.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can complete a medium complexity series of tasks\/stories   spanning a few weeks starting with a fairly loose spec, working along side a   more experienced developer.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Can complete a medium complexity series of tasks\/stories   spanning a few weeks starting with a fairly loose spec.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Proposes alternate and superior approaches to problems.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Takes the lead for large and complicated projects.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Takes the lead on high profile or time critical projects.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Design<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Suggests sensible designs for small stand alone pieces of   work.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Can be relied upon to reliably produce sensible designs   for loosely spec&#8217;d medium size projects.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Is sensitive to trades offs between flexibility at the   cost of complexity.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Understands the need for maintainable extensible design   work.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Takes the lead for the team&#8217;s most difficult design work.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Their work often has system wide architectural   implications.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can point to a number of projects where their design has stood the test of time.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Technology<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Is aware of the technologies used by the team and has some idea   of the reasons why one might be more appropriate than another.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Is not expected to make technology decisions, but should   have opinions on what technologies they might use for their own tasks.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Has some experience of the technologies used by their   immediate team.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Has a good level of experience of all technologies that   the immediate team make use of.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Has had exposure to technologies not actively used by the   immediate team<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can reach decisions about library choice for some   supporting technology, should we use JMock, EasyMock or Moquito as a Mocking   framework?<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Can make broad reaching project level technolgy decisions   &#8211; what are the implications of upgrading to MySQL 5, is it sensible to do so?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Operations<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can spot obvious problems and make sensible first stabs at   resolution.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Knows when to escalate a problem within the team.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can provide basic support to those outside of the team   e.g. A first line support team<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can perform system redeploys, noticing obvious problems,   however needs the support of team to fall back on.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Confident in the use of investigative tools, events logs   also Wireshark or Jprofiler to diagnose and fix problems.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Is capable of deploying systems in isolation.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Handles the teams&#8217;s most complex operational issues,   potentially diagnosing bugs in libraries that the team relies upon.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>The person turned to for the &#8216;oh bugger&#8217; moment.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Quality<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Understands the rationale behind dedicating time to quality be this unit testing, pair programming, integration testing or otherwise.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Regularly suggests ways in which improve the overall   quality of the team&#8217;s work.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Encourages all members of the team to adopt practices to improve quality.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Considers the team&#8217;s long term strategy.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can point to series of effective changes that they have instigated to improve quality.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Testing<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Understands the importance of unit and integration testing.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Adheres to the team&#8217;s testing expectations<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Is capable of writing tests where the code lends itself to testing, struggles in more complicated scenarios.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Is capable of writing unit tests in all cases where it is sane to do so, making use of additional libraries over and above JUnit where appropriate.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Has a good understanding over what to test for, and writes tests in away that reduces maintenance load over refactoring.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Through system level testing can build a trusted series   regression tests.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Where appropriate can devise manual test to reliable   verify the behaviour of the system<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Handles or advises on the team&#8217;s most complicated testing   challenges, suggesting edge cases and reviewing testing strategies.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Requirements<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can spot subtle ambiguities in projects on which they are   working and asks for clarification.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Can work with parties outside of the team to nail down   exactly what is wanted, offering advice where the requester is unsure or   unclear.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Is trusted with requirements capture for the team&#8217;s   largest projects.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Is able to identify alternate approaches to delivering   large blocks of functionality.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Documentation<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Where prompted can write clear descriptions of system   behaviour.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>With guidance can pitch documentation for the intended   audience.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Uses code comments to explain how the code works<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Understands when and where to document<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Does not over document<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Code comments    often explains why rather than what the code does<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Notices where documentation is missing in a structural   sense, creating new wiki\/web pages as appropriate<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Through good doc design, encourages continual maintenance   since doc is often used.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Looks for ways to doc in an automated fashion<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>UI Design<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Adheres to the team UI style<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Considers the impact of their UI decisions<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can propose sensible ideas for simple UIs<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Proposes sane workable designs for complicated UIs<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Takes the lead for the most complex UI challenges   faced by the team.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Supplier Relations<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can raise well bounded faults.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can express themselves clearly to suppliers<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Typically chooses to communicate asynchronously over email (or similar)<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Chooses a suitable communication means though is confident to use a real time method.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can follow up and present a clear argument where the   supplier does not agree with our assessment of a fault.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Draws upon a network of contacts to circumvent bottle necks to   achieve their goal quickly.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Through excellent interactions improves our   relationships.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Understands when and how to raise matter through   commercial channels<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Internal Relations<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can express themselves clearly at a team level.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Pitches their communication to a suitable level taking   into account their audience and the context.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Has dealings with multiple departments within the   company<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Talk confidently to senior members of the company in   different departments\/countries.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Handles difficult or sensitive issues on behalf of   their team.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Client Relations<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Typically chooses to communicate asynchronously<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Understand the difference between internal discussion and client facing communication.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Understands that some information is sensitive and should not always be given to clients.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can get to bottom of what clients are *really* asking for.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can say &#8216;no&#8217; in a constructive way<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Chooses a suitable communication means though is confident to use a real time method.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Handles sensitive issues with large clients.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Line Management<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Mentors junior members of the team<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Assigned to help new members of the team to get up to   speed<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Has formalised Line Management responsibilities<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Line manages other managers.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Introduces new ideas to other line managers<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Track record of handling sensitive or difficult line   management issues<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Project Management<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Can keep track of non trivial lumps of functionality,   perhaps they are not the only person working on the project.<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can provide sensible estimates and commitments for non   trivial blocks of functionality.<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Has formalised project management responsibilities.   Manages team projects on behalf of the team.<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Manages multiple teams, provides advice and guidance for   other PMs<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>A track record of successfully delivered blocks of functionality.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Recruitment<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"140\">Introductory<\/td>\n<td>Assesses CVs<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Can interview along side a more experienced recruiter<\/td>\n<\/tr>\n<tr>\n<td>Practitioner<\/td>\n<td>Able to interview 1st rounds solo<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Provides advice on CV review<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Implements and develops direct recruitment projects<\/td>\n<\/tr>\n<tr>\n<td>Leadership<\/td>\n<td>Develops interview\/ CV assessment system<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Instigates new direct recruitment initiatives<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Meets with agents<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Experienced final round interviewer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"<a href=\"https:\/\/fragile.org.uk\/index.php\/2010\/09\/06\/how-to-appraise-a-developer-resources\/\" rel=\"bookmark\" title=\"Permalink to How to appraise a developer (resources)\"><p>This post provides support and resources for the &#8216;How to appraise a developer&#8217; series, If you haven&#8217;t read the series this post will make no sense whatsoever. There are two main sections A description of suggested Knowledge Areas A set of examples to help map real world performance in specific a Knowledge Area to a [&hellip;]<\/p>\n<\/a>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[8,29],"class_list":{"0":"post-351","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-management","7":"tag-appraisals","8":"tag-motivation","9":"h-entry","10":"hentry"},"_links":{"self":[{"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/posts\/351","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/comments?post=351"}],"version-history":[{"count":0,"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/posts\/351\/revisions"}],"wp:attachment":[{"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/media?parent=351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/categories?post=351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fragile.org.uk\/index.php\/wp-json\/wp\/v2\/tags?post=351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}