Over the weekend Microsoft's Scott Guthrie, Coporate VP of the .NET developer division, announced that the open source jQuery Javascript library will be integrated into Visual Studio, the main Windows development tool. Further, Microsoft will treat jQuery as a supported product within technical support contracts, and will use jQuery to build new controls for ASP.NET, its web platform.

This is a breakthrough both for Microsoft and for open source. In the past, Microsoft has preferred to reinvent the wheel rather than adopting existing open source code. For example, when the company delivered Visual Studio Team System, it did not use existing open source products like NUnit for unit testing, or Subversion for source code management, or Nant and CruiseControl for build management, but shipped all-new equivalents. That strategy may have backfired. At the recent Remix08 conference in Brighton, I noticed that when a developer asked about Team System during a panel discussion, he was immediately advised by several other delegates to stick with the open source products.

I don't mean to suggest that Microsoft has only just discovered open source. After all, the company has its own open source community focused on interoperability, and publishes source code to some of this products under various shared source licenses. On the developer side, Microsoft sponsors significant open-source products like IronPython and IronRuby. But the jQuery case is particularly interesting, because Microsoft already has its own Javascript library called ASP.NET AJAX.
 
Is Microsoft now abandoning its own library? At Remix08, I asked Guthrie this very question. "We are definitely still investing in ASP.NET AJAX, there's lots of features coming out," he told me. "But there's a proportion of developers coming from other platforms where having support for other AJAX frameworks makes it more likely they'll use Visual Studio, which is good for us, and there's some proportion of developers on .NET that would prefer to use other frameworks in addition. People tend to be pragmatic. jQuery is great for CSS selectors and for the animation engine, but doesn't have a type system like Prototype or ASP.NET AJAX. We see a lot of developers wanting to use the ASP.NET AJAX class and type system, and then use CSS selectors and animation from jQuery."

In his announcement, Guthrie explains how jQuery support came about. Developers were asking for features to be added to ASP.NET AJAX, when they were already in jQuery. "As the team started to investigate building it, though, they quickly realized that the jQuery support for these scenarios is already excellent, and that there is a huge ecosystem and community built up around it." That sounds like common sense to most of us, but getting to this point has been a considerable journey for Microsoft.

The move is not without risks. If jQuery is good enough, then what about PHP, an open source alternative to ASP.NET? What about using Linux instead of Windows, or OpenOffice instead of Microsoft Office? The company can hardly suggest that open source stuff is never any good, when it is integrating open source code into its own products. Instead, Microsoft has to compete on real-world issues like quality, productivity, reliability and support, which can only be good for its customers.

The UK economy is facing a tough time at the minute, and the job market in many sectors is reflecting this turbulence. Certain sectors are more affected than others - businesses dealing in luxury consumer goods will be hit harder than those catering for more stable markets.

Thankfully, the IT skills shortage means that the situation for skilled workers isn't as bad as it could be - but there is always a risk in more turbulent economic times.

If you have a good thing going, there's no real reason to rock the boat. That is, it is probably best to ride out any rough weather from within the confines of a relatively secure position than to risk any trouble. If you're in stable employment and you're happy to remain there, it may well benefit you to stay until any uncertainty has passed.

Of course, opportunity is an unpredictable thing - should you be the lucky sort you may find yourself presented with a great job offer that you can't refuse. Such opportunities are usually worth taking, regardless of the general direction of the jobs market.

If you are eager for a change, it might be best to bide your time (at least for a short while). Economic depressions, large or small, all share a common characteristic - they eventually end. While it may be difficult to make progress in the current climate, patience will pay dividends.

Once the worst is over, a greater optimism will emerge across the face of business in the UK, and there could be some great opportunities to progress for the savvy career-minded individual. It is hard to say when exactly the best time for a change will be, but as confidence grows so too will the options for those looking for a new career.

Consider voluntary redundancy if it is offered. In some cases, companies wishing to downsize their long-term expenses may offer a voluntary redundancy package. This could be for a not-inconsiderable sum, and if your skills are in sufficient demand elsewhere you could take advantage. Voluntary redundancy is often the first step made by a company wishing to minimise any mandatory job cuts.

If the worst comes to the worst and you get made redundant, don't panic. There are still opportunities out there, but depending on your specific skills you may walk into another position straight away. In the interim between leaving your job and finding another one, it is prudent to be cautious and to cut expenses - but remain optimistic in your search for a new position.

Take solace from the fact that the job market isn't all bad; Indeed, certain skills are highly prized at the moment - whilst there may be a high turnover rate for positions, there seems to be ample opportunity for skilled developers in .NET, Java and other key enterprise languages. For the skilled professional with a modicum of experience, there is still an ample amount of prospect and no real reason to worry.

"Developers, Developers, Developers" is the famous rant of Microsoft's Steve Ballmer. Maybe he picked the wrong word. I'm just back from the Remix 08 conference in Brighton, where the company's Principal Researcher Bill Buxton spoke on software design. He made a big impression, especially when he suggested in an interview that unless Microsoft changes its culture in a way that put design at the core of its software, the company would die.

Underlying this is the ascendancy of Apple, widely admired for its design, and the mixed fortunes of Windows Vista, which was meant to have great design but in practice has plenty of irritations many of which are design issues. There is a tendency to think of design as primarily about graphics and layout, but this view is too narrow. Design is about the user's experience, and encompasses all kinds of user interaction.

Few companies have the resources of Apple or Microsoft; but raised expectations of what constitutes good or even acceptable design affect the whole industry, including developers of internal applications as well as web site authors. Design failures are frustrating for users; and the consequence is that software is used less, and satisfaction is lower.

An example which comes to mind has no graphics at all. A certain telecom company with a colourful name has a telephone menu system which is unavoidable if you need to call support. Whenever I have to use it, I feel my blood pressure rising before dialling the number. I know I will have to go through numerous layers before being allowed to speak to a human. I know I will be given mandatory choices, none of which apply to me, forcing me to lie. I know each step will be ponderous, with a recorded messages I have heard before, and invitations to use the web site instead - if I thought that would do, why would I call? If you call outside working hours, you are taken through all the steps and told right at the end that the office is closed, goodbye. When I do eventually speak to someone, I am already in a bad temper.

This is the consequence of poor design. I could reel off countless further examples, such as Microsoft Outlook 2007, with its obscure dialogs - click Message Options to show email headers, very clear NOT - its habit of blaming the user for its own shortcomings, "The data file was not closed properly," and its slow performance with large mailboxes. Some of these are technical issues, but because they directly damage the user experience, they are also design problems.

Enough ranting. The interesting question is how developers and designers can work together to improve software design at every level. Buxton talks about continuous design, where designers participate in the development process throughout, rather than only at the beginning of a project, or even worse, only at the end. It is a good thought; but as the panel discussions at Remix demonstrated, there is no consensus about how the developer/designer relationship should work.

There are signs of change. Tools are appearing which have both developers and designers in mind, such as Microsoft's Expression Blend which can open Visual Studio solutions, or Adobe's product codename Thermo, which converts artwork into application code. That said, it is people rather than tools that hold the key. It is about developers ceding some of their power to designers; and about designers learning more about the constraints under which developers work; and about learning to treat poor user experience as a defect. It is not easy; but teams that get this right will gain a substantial commercial advantage.

I just heard about jobvent.com. It looks fairly US-centric right now, but it has the potential for providing another perspective about the organization.

The real issue is: how do you evaluate the comments?

I refer, of course, to the metaphorical carrot held aloft by a stick - the carrot being an incentive for whatever beast of burden happens to be saddled by someone wielding said stick. More specifically, what are the best incentives for those working within IT?

Salary and benefits

Perhaps the most obvious incentive for employees is the most measurable - salary, bonuses and other benefits. It is quite true that paying under market rates is a good way to de-motivate staff and increase staff turnover as a result - but there is a point at which salary benefits do little.

Indeed, once the baseline market rate for a position is reached, there will be little productivity benefit received beyond this - it is at this point that working conditions become more important than monetary concerns.

Some benefits can help improve the environment, though - the option to have flexible working hours, for instance, can help boost morale - as can the option to telecommute. Perhaps the most important aspects of keeping a team productive is the way that team is managed - from the goals set, through communication and general understanding of processes and procedures.

Realistic goals and deadlines

Managers, take note: asking the impossible is not only futile, it's also a great drain on the morale of your team. Tackling the insurmountable may be some people's idea of a challenge, but to be asked to continually push harder and harder to meet targets - and then ultimately fail anyway - is a sure-fire way to diminish morale.

A little deadline pressure can work to spur on a developer - but if it's continuous the effect will quickly fade. It's best to keep a mix of attainable, moderate goals with the occasional push for a deadline - too little or too much workload will otherwise have a detrimental effect.

Open communication channels

Good communication is also the key to keeping your team in check - without regular updates and the occasional meeting, it's easy to lose synchronisation - this is especially true in environments where telecommuting is commonplace.

Ensuring that the whole team is aware of the current state of affairs and primary goals will eliminate any potentially morale-breaking instances in which effort expended by a member of the team could be wasted, misguided or otherwise for naught.

Having each team member understand what the principal goals are for any given collaboration or project will also help in terms of improving overall productivity, as any potential issues can be distributed and solved collectively before it becomes a critical point of action.

Stress-busting working practices

As I mentioned in my last post, there are an array of tools and methodologies that can help a development team. You can eliminate a lot of stress from a development-deployment cycle by undertaking more rigorous practices which might otherwise not be used.

A reliable deployment cycle will rely heavily on testing - particularly in scenarios where there is a lot of stake (such as a major reversioning of a critical application or launch of a primary web application). Allowing time before launch to test the capabilities of a new system (and to eke out the bugs) will shield the development team from the necessity to fix such bugs discovered after the launch.

Taking the time to document the development and testing procedures can also help in hedging against future catastrophe - while developers may not relish having to document their work, most will be aware of the headaches it may save should it ever be needed.

Technical understanding from management roles

One key irk many technically-minded people face is that of the technically inept manager - parodied in Dilbert on a regular basis, but sadly with a strong grounding in regular situation.

Managers of a technical team do tend to have a degree of technical ability themselves - indeed, those promoted to the position from a development role will likely have a very good understanding. There are exceptions, however, and the inept management style is seldom good for the team as a whole.

Without some semblance of understanding of the challenges developers face, the managerial aspect of such a team becomes more difficult - and estimates on deadlines, system requirements et cetera can become more lax. This, of course - can exacerbate the issues I've covered above.

Understanding your technical employees is critical in terms of getting them to work effectively - if you understand the work, the process and procedures that should be followed, you can better manage expectations outside the team and preserve an environment conducive to the best possible output.

I just can't stand it. I was talking with someone recently who was thrilled about the developers in his organisation. I asked about the testers and writers. "Oh, you mean the tester monkeys?"

I gave this guy my best cold stare and said, "Product development requires many more people than just coding monkeys. And, I don't know any code-monkeys or test-monkeys or writer-monkeys or any other monkeys in organisations. Do you?"

Look, if you want to develop systems, you need all kinds of people, from developers to testers to writers to release engineers to business analysts, to whomever else you need. The larger and more complex the product, the more roles you need.

Don't make the mistake of being developer-centric, test-centric or particular-role-centric. Producing a product (or system if you prefer) requires many people to do their jobs well.

No monkeys need apply.

So your resume has attracted some attention, and a hiring manager wants to talk to you by phone. Now what?

When you agree on a time for a phone screen, make sure that time really is good for you. If it's only a so-so time, and the dog needs a walk, the baby is crying, dinner needs to be finished, or the goldfish needs attention, don't agree to that time. Look for another day and time. Or, if you're now talking about a week or two out, acknowledge you're potential boss' schedule ("Wow, you are really busy!") and ask if someone else can interview you. Now, keep that time inviolate. Never cancel a phone screen unless you are dead, dying, or really don't care about the job.

BTW, If something does happen, and you do have to walk the dog, pet the goldfish, explain that at the beginning of the phone screen. "I thought this time would be good, but my significant other is still in traffic, and can't be here to take care of his responsibilities, so I am. I'm still willing to talk (if you are), but I have to talk while I walk the dog. Is this going to work for you, or would you rather reschedule?"  Be honest.

Now, between the time you've made the phone screen interview and the actual time, research the company and the person you'll be speaking with. Aside from the company's web site, search their product lines. You not only want to have a little understanding of their products, you also want to see if anyone has anything interesting to say. Use social networking sites (I prefer LinkedIn) to see if you're connected to anyone at the company. If you know someone working there, ask about working there.

Look at your resume and see if there's something you can see that relates well to this company. Think of successes you've had that you think will translate to that environment. I'm not saying you should practice a canned speech, just spend 5-10 minutes in advance thinking.

Now you're ready for the interview. When the person calls, answer the phone with a smile on your face. (Please make sure your phone is charged if you're using a wireless or cordless phone!) People can actually hear the smile in your voice. As the interviewer asks questions, answer with a story describing your experience (not a made-up story, a real story from your background).

With any luck, at the end of the phone screen, the interviewer will ask you about your availability for an interview, or will explain how the company will follow up. If the interviewer doesn't follow up, ask.

That's it. Be ready, be friendly, and be yourself. Not so hard, is it?

Every company has its own culture - a unique blend of methodologies and people that form the working environment. The world of IT perhaps boasts some of the most diverse conditions - partly due to the diverse range of skills within, and partly due to misconceptions around the requirements of technical workers.

Good Practices, Best Practices and the Worst

There are generally two ways to get something done: There's the quick way, and then there's the right way. The right way isn't always the cheapest, nor is it feasible in some cases, but it generally pays greater dividends than the shortcuts in the long run.

For programmers, there are a number of indicators of a given environment's preferred approach. Source control, testing and documentation are all part of a good programmer's vocabulary, and are key indicators of how the programmer (and the department/team they are a part of) will work.

Such things as source control, testing and documentation are not always required - indeed, quite often they are overkill - but the lack of such procedure within core projects is a sign that the environment within the organisation in question may tend towards the 'quick and dirty' school of development.

For critical business development, safeguards such as source control and testing act not as impediments but as a hedge against potential failures - failures that can (and frequently do) cost more than the relatively minor time invested in such safeguards.

Documentation, in the same way, is a pre-emptive investment in a developer's time made with the intent of saving effort in the future - for improved ease of redevelopment, or for training purposes. A little time spent doing things in the correct way can pay greater dividends in the future.

The use of such tools and methods will heavily influence a working environment - for instance, in a situation without documentation or testing, a developer might find themselves bogged down with an endless stream of bug reports, whilst struggling to get to grips with an existing system. This cycle can be exacerbated by pressure to enhance or release new features - and such pressure usually comes from above.

Management Styles

The way an organisation is managed will have a direct effect on the working environment for IT staff. A better working environment will stem from more technically-aware management, with less focus on continually churning releases and new features and with at least some investment on some of the methods and tools mentioned above.

Those organisations that choose to ignore such needs will inevitably waste time dealing with the problems that arise, and inevitably it is the developers that have to deal with these problems. It is usually far better for an organisation to invest at least some time in defensive measures against future problems.

Of course, some places do - indeed, some places will adhere to protocols to their own detriment - but in my experience there are a great many that do not adhere to any sort of routine, and suffer as a result.

Improving Working Environment Factors

In some cases, bad practice is endemic- and as such it's not always easy to rally against deep-set problems with department work flow or with management interference, but being aware of the issues involved with a particular environment is the first step to making improvements.

An effort to improve the safeguards in place in the development work cycle (such as proper source control, testing and documentation) should be a priority, as in the long term they can save time from bug fixing premature releases. In addition, a good IT manager will also be aware of the best practices for developers, and will serve as a go-between from the developers to the exterior management.

The world's biggest software company is gearing up to tell you how its new modelling platform will transform developer productivity. Modelling is meant to make programming easier, by expressing the design of an application in easily understood diagrams rather than in a bunch of complicated C++, C# or Java files.

The snag is that while models are a great way to design, describe and communicate how an application works, in the end someone still has to write the code. Smart people have made immense efforts over the years to fix this by integrating the code with the model: generating code from models, generating models from code, or even devising ways to execute the model itself.

While these efforts have not failed completely, model-driven development has never taken off in a big way. Developers figure that they have enough trouble writing and debugging code, without taking on the burden of keeping a complex model in synch, or learning the mysteries of Model-Driven Architecture (MDA), with its PIM, PSM, MOF, OCL, ODM, SPEM and so on - have a look at the Object Management Group (OMG) if you want to know more.

Now Microsoft is having another go. Code-named "Oslo", the project includes a store, a language and various tools; and it's going to figure in a big way at the company's Professional Developer Conference next month. Some details are already trickling out. Posts from Don Box and Doug Purdy explain it in simple terms, and this eWeek article has a bit more. The modelling language is code-named D, and I suspect it is another role for XAML - see my post on 10 things you might not have known about XAML if you thought it was just for building GUIs and Silverlight applications.

It would make sense for Microsoft to use XAML, since it is a flexible textual language that is designed to play nicely with visual tools. I'm guessing that you will be able to create the model visually and then run it, just as MDA promises. In a video, Senior Vice President Bob Muglia says:

When a model is created, it's possible for the business process to run directly with very minimal procedures being created around that. The model is the centre of the universe.

There are also hints that Oslo will tie in with Microsoft's cloud computing initiatives - maybe Live Mesh or some more business-focused variant.

Will it work? Microsoft is certainly serious about it. It has even joined the OMG, despite years of antipathy, though I hope this does not mean Oslo will be as complex and unsatisfactory as MDA. I see it as model believers getting together, and a way for Microsoft to get more academic and enterprise credibility for its initiative.

There are however plenty of reasons to be sceptical. Microsoft has had numerous modelling initiatives over the years. In Visual Studio 2003 it was Visio and UML. In Visual Studio 2005 it was class diagrams, Domain Specific Languages (DSL) and Design for Deployment, a way of taking deployment constraints into account before and during development. This article explains the strategy, and enthuses about software factories as the way forward. Now there is Oslo, which looks like a brand new approach. Why think this will succeed any better than what has gone before? Why think that Microsoft will achieve what the fine minds at the OMG and its industry partners have failed to do?

There is also little evidence that this is driven by customer demand. When I talk to Microsoft developers, I don't hear many asking for better modelling tools; and if the subject does come up, it is usually a request for more standards-compliant and up-to-date UML diagramming, not full-on model-driven development. This is a top-down initiative.

Count me a sceptic then; but I also want to give Oslo a fair assessment when it is unveiled next month. It is quite simple. If Microsoft can deliver a modelling platform that really does simplify rather than complicate software development, and one that does not impose a heavy performance burden, then developers will love it. The big question: what is the chance of that?

The first week of September brought the most interesting tech news for ages. The reason is Google's launch of a new web browser, called Chrome, which has stolen the thunder from Microsoft's beta release of Internet Explorer 8. The browser wars are back, and with Firefox, Safari, IE, Opera and now Chrome, users have more choice than ever.

That's all very well for consumers, but will this make any difference in the Enterprise world where IE still reigns supreme? It is hard to see this changing soon. Web designers hate IE for its poor standards support (though this is much improved in IE8), but it has plenty of attractions for system administrators, integrating with Microsoft's system management tools, controllable through group policy, and easily kept patched with system update services.

All this is true; but having played extensively with Chrome over the last few days I think it will have a wide impact. For a start, like Google search and Google mail it will leak into enterprises simply by user choice. A remarkable feature of the Chrome install is that it does not trigger Vista's UAC (User Account Control), because it writes only to areas within the user's profile. Put another way, it does not require administrator rights to install, so machines will need to be tightly locked-down to prevent it. A web site might say, "best viewed with Chrome", and the user could have it installed and running a couple of minutes later.

What is more significant is that Chrome has the potential to change expectations over what a browser application can be like. Chrome includes Google's Gears extensions, which means browser applications can save files locally, run a local database, or even run off a local web server when offline. Another interesting feature is that Chrome can install a desktop shortcut to a web site, and that sites opened from one of these shortcuts appear in a full window without any browser controls at all - without any "chrome", in fact. This is by design. If you put the offline capabilities of Gears together with desktop shortcuts and a window that does not look like a browser, then you get something that users will not easily distinguish from ordinary Windows software.

 
Spot the difference: this page was opened from a Chrome shortcut and has no browser furniture.

With skilled coding, such applications can look good and perform well. The V8 JavaScript engine compiles to native code, and is designed to handle applications larger than today's AJAX sites. The Canvas element in WebKit, the rendering engine used by Chrome, enables flexible 2D graphics without the need of a plug-in. What Google has done is to raise the bar for web applications, letting them compete more effectively with old-guard software like Microsoft Outlook.
 
Personally I won't be ditching Microsoft Office just yet. Still, I respect what Google has achieved with Chrome even in this first beta, and I like the fact that the code is open source; anyone can download it and compile their own build in Visual Studio 2005. It is early days: but my guess is that we will see a lot more of Chrome in the coming months and years. 

When you're looking for a job, it's a good idea to have an answer to this question: What have you learned lately? It doesn't matter what you've learned, as long as you've learned something. Stop learning, and what good are you?

If you're not currently employed, read something. Work on an open-source project. Manage a project in your social network (kid's school, your church, your ham radio buddies). You have no excuse not to learn something--preferably something that excites you, that you can use at work.

Don't be a lump of yesterday's or last year's or last decade's knowledge. No one wants to hire a lump.

You are a technical person. If you are like me, you might be pretty geeky. I don't think there's anything wrong with that (!), but you might need to think about your social skills so you can build rapport with your interviewer.

Building rapport with your interviewer is an intangible thing, but it leads to a great conversation and a way to showcase your skills. Make sure you make contact with the interviewer as a human being.

Here's how:

1. Stand up when you meet the other person, extend your hand to shake, and look at their eyes. Yes, looking directly at someone else's eyes is a Western approach to making contact, but I am. If your culture is different, and you're interviewing with someone else from that culture, do what is appropriate. Standing up is almost always appropriate. In some cultures, women don't shake with men, nor do people look each other in the eyes. But if you're in the West, make sure you do.
2. Give a brief but firm handshake. No limp fish handshakes. Yes, you can practice shaking hands with a friend or family member.
3. Now you're into the small talk part of building rapport. Say, "Hello, it's nice to meet you" or something like that. Now, you can start into the real small talk. "When we spoke on the phone, I was intrigued by something-or-other." Mention the project, or the organization, or the position. That's usually enough to get the interviewer started. But if not, be ready with an open-ended question. "It seems like a really complex project. How is it organized?" 

As you speak through the interview, continue to make eye contact every so often with your interviewer.  Keep your interviewing skills in mind, and you'll do well.

At the end of the interview, ask the hiring manager for a business card so you can write a thank you note. I'm old fashioned and prefer a handwritten note, but an email might be good enough. Learn enough about the hiring manager so you know!

Being geeky doesn't mean you have zero social skills. It just means that you (and I) have to work on them a little. A little practice will go a long way.

There are a multitude of different web-related roles out there, each with a particular composition of skills requirements - from the basic web editing roles through to senior development positions, and beyond.

Salaries listed are based on my own estimation, and of course can vary greatly depending on region, particular job role - and luck.

Core web skills based (HTML, CSS)

Web Content Editor

Required skills: Basic HTML, Some graphics editing

Typical salary: £12-20k

As far as core web skills are concerned, the entry level consists of a combination of a little HTML with some basic graphical ability - web content editing, principally. This extends from managing a corporate website's content, through blogging, and a variety of marketing and PR-related positions (that, depending on the role, may scale to a higher level).

Web Designer

Required skills: Moderate HTML, Graphic design, Photoshop, Dreamweaver

Typical salary: £15-25k

The general-purpose web designer role tends to focus more on the design aspect of the job, rather than the altogether-more-lucrative programming roles, and tends to involve working as part of a design-led team or agency, often as a design counterpart to a developer role.

Knowledge of development languages in addition to the basics of web design can greatly enhance your career opportunities, not to mention your salary. Of course, there are a number of languages and routes to choose from, each with accordingly different remuneration.

Web scripting languages (PHP):

I'm listing PHP here separately, as the composition of skills tends to differ slightly from the more enterprise-focused roles. PHP tends to be used in situations where the support and frameworks otherwise relied upon by larger businesses.

Junior PHP Developer

Required skills: Moderate HTML, Moderate PHP, Minimal graphics experience

Typical salary: £17-26k

At the junior level of PHP development, there is an expectation for a moderate level of general purpose web skills, covering HTML, CSS etc. PHP tends to be a first port of call as far as development is concerned, as it is commonly taught in university and is quite ubiquitous in nature. It is also amongst the easier of web languages to pick up.

Perhaps it is due to this ubiquity and ease of learning which inhibits the salary potential of PHP work, but there is at least some room for career progression and the benefit of a healthy job market for skills in PHP.

Middleweight PHP Developer

Required skills: Good HTML, Good PHP, Minimal-moderate graphics experience, some server administration experience, Minimal-moderate DB experience

Typical salary: £20-30k

As a PHP developer matures, they will need to pick up some supporting skills - most notably the introduction of the ability to manage a database and web server should the need arise.

Senior PHP Developer

Required skills: Expert HTML, Expert PHP, Moderate graphics experience, good server admin ability, moderate DB experience.

Typical salary: £28-35k+

At the higher level of PHP development, you can expect a healthy salary as long as you can back up your PHP knowledge with a good level of database and server admin experience.

Enterprise-oriented languages (NET/Java)

Junior .NET/Java Developer

Required skills: Moderate HTML, Moderate .NET/Java, Minimal-moderate DB experience

Typical salary: £20-30k

Enterprise-type languages such as Java and .NET have a number of benefits over PHP, in that they tend to be suited to larger production environments and boast better vendor support.

As far as salary is concerned, both Java and .NET have significant advantages over most other development languages; Because of the environment they are used in, and the applications they tend to be used for, these 'enterprise' level languages tend to pay a lot better from the outset.

Middleweight .NET/Java Developer

Required skills: Good HTML, Good .NET, Moderate DB experience

Typical salary: £28-40k

As a typical .NET career progresses, it is primarily knowledge of the language and frameworks that matters, although subsidiary skills such as a strong grasp of HTML, CSS etc will help employability. As such roles tend to focus on the development aspect of the web (rather than design), skills with database systems will prove to be useful as well.

Senior .NET/Java Developer

Required skills: Good HTML, Expert .NET, Good DB experience

Typical salary: £40-60k+

For a top level enterprise developer there is ample opportunity. It's hard to specify an exact range of salary or experience, but for the developer in a leading role the salary can be very attractive.

By this time, the developer will have a broad knowledge of the language, as well as supporting hardware and database systems.

Beyond

Of course, beyond development roles there are a multitude of other opportunities. Development lead roles may fuse together project management skills with senior-level development experience. Software architect roles fuse together knowledge of database and hardware architecture with planning skills and software modelling ability.

Development lead and architect roles vary greatly in terms of composition and salary .Once you're past the senior development roles the positions become less fungible, more fitted to a particular scenario. But as with the core development roles listed above, the increase in the breadth of the skill set required and the responsibilities correlates with an increase in salary.