Certainly, everyone has anecdotes about developers they've worked with who they thought were brilliant. Unfortunately, most of the time that judgement is made not based on code quality, or hitting of deadlines, but on less relevant criteria, like whether or not the developer knew the names of their colleagues, how many lines of code they output or how confident they sounded when talking about their work.

Unfortunately, the best developers don't always come across positively. While this list may not be applicable to every development environment, here are a few of the traits to look out for to spot a great developer.

Pessimistic

Great developers are almost always pessimistic with regard to their work. That doesn't mean they're not upbeat, lively or even cheerful - just that they will always be thinking about what can go wrong and how it can be dealt with.

They'll assume that at some point they'll need to undo work already completed, that hardware will fail, that all security will be compromised, and that your office will burn to the ground. The really brilliant ones will assume that will all happen on the same day. And they won't be happy until there is a specific, actionable, testable - and fully tested - plan for dealing with these sorts of issues. Even then they won't be completely happy.

Pessimistic developers will be the ones that find constant flaws in ideas, and the important thing to remember when working with them is that they're not doing that to tear down other people's ideas - they're doing it to ensure that the ideas that turn into projects are properly thought through and that as many problems as possible have been anticipated in advance. That neurotic, paranoid, pessimistic attitude is exactly what you should be looking for if what you want from your developers is robust, secure, reliable code.

By contrast, an optimistic developer will be more likely to simply assume code will work, or that it is secure, or give a deadline for a project without considering all the potential pitfalls.

Likely to be heard saying: "And what happens when that goes wrong?"

Lazy

Laziness is not usually viewed as a desirable trait, and in this case I don't mean turns-up-late-and-pretends-to-work laziness or just-move-that-logic-to-the-view laziness - both entirely unwanted. I mean a desire to not do tasks that are repetitive, or to waste time doing things a machine can do for you, or even to avoid future work by writing better code now. A lazy developer is one that builds a reusable code library, or wants a fully automated build process rather than a manual copy-and-paste one, or wants comprehensive automated unit testing, or writes code to be scalable even though that wasn't a requirement (rather than revisit it later).

As a bonus, a lazy developer is also usually one who will try and keep a project focussed on its core goals, rather than try and cram more work into the same time, providing a buffer against feature creep.

For example, when writing a category structure, a lazy developer might be likely to assume a many-to-many relationship between parent and child categories, even though the project specification says it will be a one-to-many relationship. Why? Because it might be needed one day and it would be better to write it that way from the start than to revisit it later.

Likely to be heard saying: "We could automate that."

Curious

Good developers are often rather like Gregory House. They're very easily bored by repetitive work (see laziness) and spend most of their time ploughing through it looking for an interesting and challenging (and hopefully new) problem to solve. The less time they can spend on the repetitive, the higher the frequency of the challenges.

Curious developers will be constantly looking for new problems to solve, and better ways to solve previous problems. They'll be the ones encouraging new ways to work and constantly tweaking and trying to improve existing systems. They'll also be the ones most conscious of existing problems in the current working environment, and trying to correct those problems. Curious developers will usually have a wide breadth of knowledge, not just of their primary language(s), but of supportive, associated and alternative technologies.

Curious (or easily-bored) developers are often the least stuck in their ways - the most open to change. They may well need convincing of why a new way of working is better (and that's no bad thing) but as long as it's an improvement, and likely to release more time to spend on the interesting problems, they'll embrace it with a minimum of resistance.

Curiosity also breeds creativity, another highly desirable trait in any developer. A strong desire to work out what has caused a problem and how to solve it is highly likely to motivate someone to continue once obvious avenues are exhausted. It is that sort of mentality that fosters "outside the box" thinking and creative coding.

Possibly the most useful attribute of a curious developer is that desire to find and cure a problem rather than just paper over the crack.

Likely to be heard saying: "Maybe there's another way to do this."

Meticulous

Many great developers are sticklers for detail. They will demand consistency in their work and the work of their team (they're likely to care about common code standards and naming conventions, for example). They'll want unit testing and peer review of code. They'll want everyone in their team to comment on and document code. They are likely to be fussy about version control log messages.

They'll also be fussy about details in communication, and happy to ask what might seem like obvious questions, simply to be sure they have properly understood. This is especially true of things like bug reports. While they may not be terribly motivational communicators, they will usually be able to explain concepts clearly and effectively. That clarity is a tremendous advantage in any development environment, especially if teaching and learning are encouraged.

Likely to be heard saying: "I just have a couple of questions ..."

Translations

• Russian / Русский

Back in August, I wrote about PPC Management Software, and my uphill struggle to find a really good PPC software provider. Well, after a few months of trawling the web and trying various options out, I've found a program that works exactly the way PPC software really should work: Kazaam from Israeli firm Kenshoo.

A gentleman by the name of Etai Rosen spotted my plea for help and got in touch to show me through Kenshoo's system, and I was completely blown away. In the training sessions since that initial sales session, and using it since the training, I could swear it's reading my mind and getting better. And there's a new version due out any minute that fixes just about every little gripe and problem I have found so far, and even adds the biggest feature currently missing from their offering.

So what's good about it ... well, it has the ability to import an XML file, daily and automatically from a URL. Awesome - that takes care of my product lists, special offers and so on. Other providers seemed to trip up on this point frequently.

There's a great system of bid policies - you set and forget (to a degree). Bids can be raised and lowered, bad keywords weeded out, all based on pre-set metrics, including an average CPA, and/or actual conversion data.

Copying campaigns from one engine to another takes 5 clicks.

A huge selection of highly automated keyword generators, some smarter than others but all interesting.

The objective appears to be to automate, as far as possible, the PPC process, and in that regard I think they've succeeded admirably. The whole system appears to be able to take control of most of the day to day tasks involved with running PPC campaigns.

It's early days yet but so far I'm very impressed. Things may change, of course, but I'll keep you posted!

A busy week this week at work is currently not looking like it will improve much, and primarily that is because I can't find a piece of software that can do what I want it to (and doesn't cost a fortune). Our contract with our previous PPC software supplier is about to expire and, because of their abysmal service and support, will not be renewed. So I am shortly to find myself without software to manage our PPC, and far too many keywords to do so manually.

So I need to find something to help manage our PPC campaigns at work. While I can live with simple maintenance functionality, a degree of automated bid adjustment wouldn't be a bad thing if at all possible. Can you help?

While working with our previous supplier, I have developed an internal PPC management system that allows us to set up keywords and adverts for products through our own CMS. This system regularly builds a text file with all of our PPC data in and sends it via FTP to said company. I would like to work with a company (or piece of software) where this system would not go to waste, if at all possible.

So what is your software of choice? All reccommendations very much appreciated!

A more technical breakdown of HTTP 1.1 status codes and their meanings is available at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. There are several versions of HTTP, but currently HTTP 1.1 is the most widely used.

Informational

• 100 - Continue
  A status code of 100 indicates that (usually the first) part of a request has been received without any problems, and that the rest of the request should now be sent.
• 101 - Switching Protocols
  HTTP 1.1 is just one type of protocol for transferring data on the web, and a status code of 101 indicates that the server is changing to the protocol it defines in the "Upgrade" header it returns to the client. For example, when requesting a page, a browser might receive a statis code of 101, followed by an "Upgrade" header showing that the server is changing to a different version of HTTP.

Successful

• 200 - OK
  The 200 status code is by far the most common returned. It means, simply, that the request was received and understood and is being processed.
• 201 - Created
  A 201 status code indicates that a request was successful and as a result, a resource has been created (for example a new page).
• 202 - Accepted
  The status code 202 indicates that server has received and understood the request, and that it has been accepted for processing, although it may not be processed immediately.
• 203 - Non-Authoritative Information
  A 203 status code means that the request was received and understood, and that information sent back about the response is from a third party, rather than the original server. This is virtually identical in meaning to a 200 status code.
• 204 - No Content
  The 204 status code means that the request was received and understood, but that there is no need to send any data back.
• 205 - Reset Content
  The 205 status code is a request from the server to the client to reset the document from which the original request was sent. For example, if a user fills out a form, and submits it, a status code of 205 means the server is asking the browser to clear the form.
• 206 - Partial Content
  A status code of 206 is a response to a request for part of a document. This is used by advanced caching tools, when a user agent requests only a small part of a page, and just that section is returned.

Redirection

• 300 - Multiple Choices
  The 300 status code indicates that a resource has moved. The response will also include a list of locations from which the user agent can select the most appropriate.
• 301 - Moved Permanently
  A status code of 301 tells a client that the resource they asked for has permanently moved to a new location. The response should also include this location. It tells the client to use the new URL the next time it wants to fetch the same resource.
• 302 - Found
  A status code of 302 tells a client that the resource they asked for has temporarily moved to a new location. The response should also include this location. It tells the client that it should carry on using the same URL to access this resource.
• 303 - See Other
  A 303 status code indicates that the response to the request can be found at the specified URL, and should be retrieved from there. It does not mean that something has moved - it is simply specifying the address at which the response to the request can be found.
• 304 - Not Modified
  The 304 status code is sent in response to a request (for a document) that asked for the document only if it was newer than the one the client already had. Normally, when a document is cached, the date it was cached is stored. The next time the document is viewed, the client asks the server if the document has changed. If not, the client just reloads the document from the cache.
• 305 - Use Proxy
  A 305 status code tells the client that the requested resource has to be reached through a proxy, which will be specified in the response.
• 307 - Temporary Redirect
  307 is the status code that is sent when a document is temporarily available at a different URL, which is also returned. There is very little difference between a 302 status code and a 307 status code. 307 was created as another, less ambiguous, version of the 302 status code.

Client Error

• 400 - Bad Request
  A status code of 400 indicates that the server did not understand the request due to bad syntax.
• 401 - Unauthorized
  A 401 status code indicates that before a resource can be accessed, the client must be authorised by the server.
• 402 - Payment Required
  The 402 status code is not currently in use, being listed as "reserved for future use".
• 403 - Forbidden
  A 403 status code indicates that the client cannot access the requested resource. That might mean that the wrong username and password were sent in the request, or that the permissions on the server do not allow what was being asked.
• 404 - Not Found
  The best known of them all, the 404 status code indicates that the requested resource was not found at the URL given, and the server has no idea how long for.
• 405 - Method Not Allowed
  A 405 status code is returned when the client has tried to use a request method that the server does not allow. Request methods that are allowed should be sent with the response (common request methods are POST and GET).
• 406 - Not Acceptable
  The 406 status code means that, although the server understood and processed the request, the response is of a form the client cannot understand. A client sends, as part of a request, headers indicating what types of data it can use, and a 406 error is returned when the response is of a type not i that list.
• 407 - Proxy Authentication Required
  The 407 status code is very similar to the 401 status code, and means that the client must be authorised by the proxy before the request can proceed.
• 408 - Request Timeout
  A 408 status code means that the client did not produce a request quickly enough. A server is set to only wait a certain amount of time for responses from clients, and a 408 status code indicates that time has passed.
• 409 - Conflict
  A 409 status code indicates that the server was unable to complete the request, often because a file would need to be editted, created or deleted, and that file cannot be editted, created or deleted.
• 410 - Gone
  A 410 status code is the 404's lesser known cousin. It indicates that a resource has permanently gone (a 404 status code gives no indication if a resource has gine permanently or temporarily), and no new address is known for it.
• 411 - Length Required
  The 411 status code occurs when a server refuses to process a request because a content length was not specified.
• 412 - Precondition Failed
  A 412 status code indicates that one of the conditions the request was made under has failed.
• 413 - Request Entity Too Large
  The 413 status code indicates that the request was larger than the server is able to handle, either due to physical constraints or to settings. Usually, this occurs when a file is sent using the POST method from a form, and the file is larger than the maximum size allowed in the server settings.
• 414 - Request-URI Too Long
  The 414 status code indicates the the URL requested by the client was longer than it can process.
• 415 - Unsupported Media Type
  A 415 status code is returned by a server to indicate that part of the request was in an unsupported format.
• 416 - Requested Range Not Satisfiable
  A 416 status code indicates that the server was unable to fulfill the request. This may be, for example, because the client asked for the 800th-900th bytes of a document, but the document was only 200 bytes long.
• 417 - Expectation Failed
  The 417 status code means that the server was unable to properly complete the request. One of the headers sent to the server, the "Expect" header, indicated an expectation the server could not meet.

Server Error

• 500 - Internal Server Error
  A 500 status code (all too often seen by Perl programmers) indicates that the server encountered something it didn't expect and was unable to complete the request.
• 501 - Not Implemented
  The 501 status code indicates that the server does not support all that is needed for the request to be completed.
• 502 - Bad Gateway
  A 502 status code indicates that a server, while acting as a proxy, received a response from a server further upstream that it judged invalid.
• 503 - Service Unavailable
  A 503 status code is most often seen on extremely busy servers, and it indicates that the server was unable to complete the request due to a server overload.
• 504 - Gateway Timeout
  A 504 status code is returned when a server acting as a proxy has waited too long for a response from a server further upstream.
• 505 - HTTP Version Not Supported
  A 505 status code is returned when the HTTP version indicated in the request is no supported. The response should indicate which HTTP versions are supported.