1. New graduate.

   Will use the tools, procedures and methods prevailing within the shop they join.

   This includes all the classical tools of development; editors, IDEs, build tools, source control, test tools, design tools, documentation tools, etc.

   They may have acquired an editor preference, and if they see another developer using that editor, or some other "non-standard" editor, they may be bold enough to enquire if they can use their preference.

   They would be somewhat out of their depth, and generally won't be asked, to set up an new project from scratch, or to specify a complete project or major sub component on their own.

2. 3 to 5 years after graduation.

   They will have acquired a list of grouses that exist with the existing tool sets.

   They may have looked around and possibly tried, either at home or in some small corner of their work, a few alternatives to the prevailing setup.

   Will have probably been responsible for setting a new (sub)project from scratch, though they will have a tendency to stick fairly closely to what they know works, which in turn will tend to be what prevails locally.

   Will probably have done the data gathering, and possibly drafted specifications for substantial sub components. </l>

3. 5 to 10 years experience (not necessarily graduates).

   Will probably have been exposed, through changes of employment or personal experimentation, a reasonably wide range of alternatives for most tools, and will have acquired an, (often strong), opinion on which ones are best.

   Will have setup new projects from scratch, including going to bat to get changes to the status quo authorised and accepted.

   Will have performed the data gathering and produced several draft specifications.

   Will have produced and championed a few full specifications.

   Will generally be comfortable to perform all roles from designer, to analyst, to coder, to maintenance, to tester, for projects within their experience. Some will have acquired enough variety of experience to allow them to see the common elements and will be have the confidence to be able to apply them to new projects outside their specific experience.

   Will probably have acquired some level of Project Leadership skills

4. 10 to 15 years experience (not necessarily graduates).

   Will either have made the transition to Project Leader/Manager roles; or if they really prefer the coding side of life to the management side, they will have become generalists capable of handling most aspects of the job, but will have probably specialised into one particular area: analysis & design, project leadership; testing & deployment; pre- or post sales support. A few that really only enjoy the coding side will have become highly proficient and productive coders, though these often strike out on their own by this stage.

5. 15+ years experience (not necessarily graduates).

   Will usually have acquired a wide range of experience across project types, development methodologies, languages and tool sets.

   Will have

   • experienced the highs and lows of project success;
   • been subject to both good and bad management regimes;
   • been subject to, and seen the effects of untimely and uninformed non-developer, management decisions;
   • be extremely wary and skeptical about the latest, greatest, super-hypebolic development paradigm/language/toolset magic bullets;
   • have acquired a distinct feel for what works and what doesn't;
   • will have a desire to be in control of how things are done;
   • will have formed some strong opinions about most areas of the job;
   • will have developed a desire to not just be a part of a project, nor even just be in control of a given project, but to look at the ways and means of improving the entire project development process.

   They will have a hankering to start a project to look at the entire project management and development process itself. Not just run this project or that project well, but to look at ways of making the entire project development cycle better, from the way the project is run; to the way the tools that are used are chosen, work and interact; to the way the project owner/commissioner and the deveopment team cooperate; to the way project team is setup, it's member are recruited, managed, and evolved.

   Of course, if he ever gets his opus completed and attempts to present it to others, and one of those others happened to be himself, he'd be just as skeptical of this magic bullet as all the others :)

In the end, the biggest difference between the person with knowledge acquired through education, and the guy with the same or similar knowledge acquired or backed by experience, is that the latter will generally be quicker to select between alternatives and have less compunction to stick exactly to the "rules".

They will know better when to apply a particular algorithm or when to eschew "best practice" in favour of the expedient fix, especially when deadlines loom or crises occur.

They will tend to make decisions based upon their own experience rather than needing to consult higher authority for everything.

They will generally be capable of seeing their individual problems in the light of the bigger picture and will choose to react accordingly.

They will have a better feel for which of life's daily annoyances to go to bat over, and which to allow to pass without comment. They will also usually be better at choosing the right time and place to go to bat.

They will generally be prepared to absorb their immediate problems and defer their innings, if those problems are acknowledged with regrets that no immediate fix is available/possible.

Like I said, wide bands and very broad brush strokes. Some acquire experience more readily than others; learn to recognise commonalities and apply knowledge more quickly; and some never do.