1. High-quality code

It’s easy to write code, but much harder to write good, clean code. And by good, I mean readable code which matches a specific style, is commented enough but not too much, has short methods, self-documenting names of variables, etc.

2. Broad knowledge

One can hardly be called a professional developer if he only knows one programming language. Understanding different paradigms (like object oriented, functional or reflective) is a must-have too.

Also, as a web developer, one should know HTTP, JavaScript, SQL, REST and too many things to be listed here. A professional web developer should be able to do an average-scale website alone, with the exception of visual design and graphics. It shouldn’t be as good as a website created by a team of highly specialized people, but still should be acceptable.

Knowing your tools is a requirement too. You should be familiar enough with version control, IDEs, etc.

3. Solid experience

You don’t get professional after two years of college. Somebody with ten years professional experience will likely have more chances of being called a professional developer.

Of course, there are different sorts of experience. Working in a small company where nobody cares about product quality is not very valuable.

An experience in a large-scale project is nice too. It’s pretty easy to build a small website, but much harder to get it right when it comes to a website which should be deployed on an array of servers, rely heavily on caching, etc.

4. Personal motivation

If a person is truly motivated by software development, she should be able to show it. When I interview a person who claims to be passionate about programming and has 15 years experience in software development, but can’t answer the simple question: “Talk me about your last personal project related to programming”, I know that there is something wrong with this candidate.

Have open source projects with source code available for download. Have a blog. Participate to Stack Exchange. All those things are valuable when presenting yourself as a professional developer.

I’ve been developing with PHP for 8 years now – since I was 16. I meet people of all ages, shapes and sizes and backgrounds. I agree with most of MainMa’s points, but let me add some emphasize and a few points of my own.

Passion & Motivation

This is the most important thing by far. Strive to be the best (you can be), and eventually you will. It takes true passion for problem solving and honing your craft. You can tell in 5 seconds if somebody is passionate. When you ask them a question, do they instantly engage, or do they give a two-word response? If you recommend something, do they come back and tell you about it after?

Dedication

Software development is a craft that can take decades to master. They say it takes 10,000 hours to master something, but I think when working with a moving target like software development, it’s much more. If you work full time, you will hit that mark every few years so you can constantly re-invent yourself. Being able to stick with something this long requires an enormous amount patience & again, passion. Be wary of the people with 10/15 years of experience who are not incredible. They are not dedicated, and probably lost the passion a decade ago. 15 years of experience is not the same as 1 year of experience 15 times.

Hunger for Knowledge

It takes constant learning and defeat. It should be downright embarassing/depressing looking at code from the previous year If it’s not, then you aren’t learning enough. Find the people who are at the top and learn everything you can from them. Typically that’s key open source contributors (for PHP: Symfony, Zend, PHPUnit/Behat/etc. developers). They are the ones who train everyone else. When somebody tells you X is better than Y, do your own research. They are usually sheep who were told that 5 years ago and still preach it. I’ve actually this site to be an amazing resource. I find a very wide range of content which usually leads back to the same key people or principals (Martin Fowler, Uncle Bob, etc., DDD, etc.)

PHP Sucks

Whatever. If people want to rag on you/PHP, don’t let it get you down. If you follow the key development principles and actually build software, then keep on keeping on. PHP has come a long way and it’s not the ugly duckling it used to be. Learn from other languages, and mess around with others once and a while. You may like them more, or you may not. Either way, it’ll widen your knowledge and introduce you to new patterns or practices that aren’t popular or even possible in PHP.

Network

Start building a brand for yourself. Blog. Attend meetups/conferences. Reach out to others on Twitter. Find a community/niche to engage with. Contribute to open-source projects. Programming is a very social job now. Don’t isolate yourself, and make your work known. The sooner you do this, the sooner you’ll build relationships with great developers who will take you under their wing, and the sooner you’ll find decent clients/employers rather than the crappy ones that everyone else works for.

In addition to what Adrian Schneider and MainMa has written (which are both good), I do think that one hallmark of a professional programmer, regardless of language, is the realization that code has an extremely long half-life — much longer than we commonly realize or for that matter expect when writing it.

Yes, there are extreme cases of systems dating back 50 years still in active use (business-critical applications written in COBOL back in the 1960s to 1970s still being used), but it doesn’t need to be quite that extreme. Of course at the other extreme is ad-hoc code written to be executed only once. One of the applications I work on is basically a web-based CRUD application. Lots of table views, some specialized views, some reports, a few surrounding odds and ends. Really, nothing very fancy in the grand scheme of things. With some of the core classes and database code dating back 10+ years currently, I do believe it rather nicely fits around the median. The language and framework (C#.NET, in this particular case) have of course evolved over that time, and the people involved have gained experience in using it, but the old code remains in place because it works and works well enough, seeing minor changes now and then but most often just providing the foundation that the whole system rests on. My employment before that was centered around replacing an aging system which was designed for only a single user and with parts written 15+ years prior with something slightly more modern. Let me rephrase that. Some of the most important parts of the system I was tasked with replacing predated Windows 3.0.

A professional programmer will, when writing code that isn’t explicitly throwaway code designed to solve a very specific one-time-only issue, consider the fact that the code s/he writes today will likely remain in some form for many years. If it is a core piece of the software, it is likely to remain for a significant portion of the product’s lifetime. It is likely to need maintenance down the road by a programmer which has nothing to do with the original development team. Heck, it might even need maintenance by the programmer who originally wrote it! (If you don’t get that, consider the saying that code you wrote six months ago may as well have been written by someone else — then try six years rather than six months.)

From this comes the realization that code needs to be easy to read and understand, easy to modify and easy to extend to fit into new uses or meet changing requirements. It also needs to be easy to debug, as well as preferably easy to follow without running it through an interactive debugger.