Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have a team of 20+ developers, of mixed skills and varying levels of ability in each.

Some are C#/MVC4/.Net 4.5 developers cutting new code, some are VB6-ers maintaining our critical legacy apps.

For each, we have a 'Career Progression Framework' - an internally available list of what you need to do in order to move from Trainee Analyst Programmer Levels 1, 2, 3 and 4, to Analyst Programmer Levels 1, 2, 3 and 4, into Senior Analyst Programmer Levels 1, 2, 3 and 4.

Admittedly, the CPF we use is well out of date and needs reworking, which is a straightforward process itself.

With new technologies coming out in the .Net field all the time, this framework almost needs to be akin to walking up an escalator as in moves downward, as the newer stuff should be known to the top of the 'tree' before the trainee gets to it.

One thing to bear in mind here, is that at each stage, the developer is given a small pay increase, as a reward for their efforts, but in most cases, this is the incentive to 'climb' the ladder in the first place; if they've received an increase for getting the new stage, HR might have issues with it being removed!

I know developers should be keen on keeping their axes sharpened, but in reality, not all developers are like that, unfortunately, and they are what they are.

The problem is I am trying to determine the best way to grade our developers based on their specific skills and framework knowledge and am wondering the flaws with my specified approach. Please keep in mind that answers should be pertinent and exclusive to the unique challenges in grading software developers in the organization.

EDIT: On-site and off-site training is offered to developers.

share|improve this question
2  
Make the requirements for each level public, and give each employee enough time to demonstrate he/she should stay at an equivalent level. Your company should also pay for job-relevant training etc. Then be very lax and have most people stay where they are; if they don't meet their requirements that can be brought up later in a performance evaluation with their manager. I should also add that such a strict CPF feels too inflexible for the real world, it sounds almost like a rank in a military organization: Senior programmer and trainee aren't different ranks, they're different jobs. –  amon Feb 25 at 8:32
    
They are at present, and people are working through the problems on the aging CPF and ticking-off their stages, getting their pay increase, and subsequently getting to the top of Senior but are not what you'd call 'Senior' developers. –  Brett Rigby Feb 25 at 9:02
    
But yes, you're right. They are different JOBS. Maybe that's the different perspective that I think I need on this. A Trainee developer should be expected to contribute code on a project, whereas the Senior developer is managing other aspects of the project, as well as coding, for example. –  Brett Rigby Feb 25 at 9:08
8  
12 levels for 20 or so people sounds far too granular. Let me guess, pay rises are predicated solely on moving from one level to another? If so then this is far too rigid. I would sweep away the distinctions and just have trainee, regular and senior, and pay people according to how much they contribute to the business (both in terms of what they produce now, VB6 included, and how proactive they are in preparing for future development). –  Julia Hayward Feb 25 at 9:17

3 Answers 3

Both systems sound so very very flawed.

the newer stuff should be known to the top of the 'tree' before the trainee gets to it.

In my experience.. this is way off. Juniors are the ones who research this stuff. Almost all Senior developers I have met are very relaxed in their roles and seem to be just waiting out retirement. "Oh I don't have time to learn that sort of thing", "Graph databases? Never heard of it", "Back when we had IBM AS/400's running they were flawless". etc.

Why are they senior then?

They know the business. They have been there for years and can describe every detail of their domain to you. Knowing 30+ libraries doesn't make you a Senior in the eyes of a business. Knowing your domain - inside-out - makes you a Senior in the eyes of a business. The last job I worked at had a single "Senior C# Developer" role. He had been there 9 years. Hardly utilized LINQ because he hadn't really looked into it. He could analyze and implement anything the business threw at him though.

Sure, 30+ libraries on my resume makes me look like a "Senior" developer.. but if I get into the role and have no proper ability to contribute to the business.. I'm a Junior within that business.

I think distributing developers into "ranks" is not a good idea. I also think grading them on how much they know in general rather than how well they contribute to the business is equally bad. Not sure if that helps you at all...

share|improve this answer

Start with management, ask the dev team how they would regrade the management staff. Once they've gone through that process you can apply the same thinking to the dev team without them kicking up a fuss about fairness.

As for the concept that you need to re-skill continually, this is a fallacy. Do those VB6ers still have VB6 code to work on? If the answer is yes, then you better keep them proficient in VB6 or your business will suffer. Or you'll end up in the state where you can only get really expensive VB6 contractors to maintain the critical applications. Said contractors will probably end up being the same guys you let go as not having enough modern skills. Think of all those Cobol programmers who get paid eye-watering amounts.

The same applies to a lot of other technologies - do they know SQL, has that changed significantly in the last few decades? Do they know the architecture and business processes of your applications? You see, telling someone they need to know only the latest, coolest technologies is very short-sighted and far too narrow. Your management is doing a really poor job if you do.

The trick is to ensure that the people you have are doing roles that are beneficial to the business. When you take your eye off this and start thinking of technology as something more important, you've lost it. Make sure those VB6ers on the critical applications are kept happy because its not their knowledge of Microsoft's latest REST toolkit that matters, but the critical application. There will always be another toolkit to learn about next year.

share|improve this answer
    
Thanks for the reply. Your comments regarding management are certainly a thought. I'll possibly reword my original question, as I wasn't intending to imply that we're chasing the new and cool stuff in the tech world. But as our current CPF stops at elements that came out in .Net Framework 2.0, there's a whole lot of stuff that we're forgetting. And this 2.0 list is what we're currently grading our guys on. –  Brett Rigby Feb 25 at 8:53
2  
@BrettRigby I see, ok, but still understand technology isn't what matters - you can put all kinds of modern .net stuff in there and in a year or two it'll be as obsolete as it is today. Focus on business needs instead. –  gbjbaanb Feb 25 at 8:58
3  
Good point well made. I think an alternative viewpoint on this problem is needed. Thanks. –  Brett Rigby Feb 25 at 9:01

Instead of critiquing the finer points of your suggested model I will instead challenge some of the fundamental premises that you are making.

The notion that a developer be graded superior in title and pay that X developer only knows VB6 and mostly supports legacy applications while Y developer knows ASP.NET MVC which is a newer framework is a silly notion. I would argue that both are of equal importance and of less value in a business or organization than the eager developer that wants to learn everything and is happy to contribute anywhere he/she can.

There is more to the measure of a software developer than the frameworks and the age of said frameworks. If that older VB6 gentlemen expresses no interest in expanding upon his/her technical skills to branch into newer technologies or projects then I honestly have no interest in advancing that persons grade. If they become Senior level and are going to be outperformed by kids coming directly out of school starting out with more current knowledge then I view that promotion to that person as an unfortunate (yet commonly made) mistake.

The qualities that really matter are more of the soft skills.

  • The eagerness and ability to learn quickly
  • The ability to own their tasks and not need babysitting from managers
  • The ability to communicate effectively with analysts, business people and clients
  • Leadership and mentoring of less experienced developers on the project or the framework

I would argue these are solid skills to master for the senior developer. Tech leads and architects need additional experience.

  • The ability to envision non-functional requirements and capture these in a technical design
  • The ability to lead a development team
  • The ability to capture POC and document findings effectively for the business and implementation team
  • A wide breadth of knowledge in a variety of areas

As the author Robert Heinlein once said -

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.