If you're trying to figure out whether the developer you are working with is great or not-so-great, here are some dead giveaways. 1. HE SAYS "IT WORKS", AND IT CLEARLY DOESN'T. Great developers are harder on their own code than anyone else. A dev who declares victory easily, and leaves it for others to find and then escalate the bad news wastes everyone's time, and isn't learning. 2. THE SAME BUGS KEEP COMING UP. Great developers abhor waste. Time is the ultimate scarcity. Every bug is offensive to them. They fix things once and for all. The really great ones fix classes of bugs, and put safeguards in place so that bugs of that class can't get past the sniff tests. If you notice a pattern before he/she does, beware. 3. SHE SAYS "I DON'T KNOW ANYTHING ABOUT THAT" WITHOUT SHAME OR CURIOSITY. A great developer not only knows how everything in the product works, he/she is perenially intrigued by the unknown. Devs who draw a line around "my stuff" and cower within are a problem. 4. HE CAN'T EXPLAIN WHY IT IS WORKING NOW. Bugs don't "go away" (same as garbage). Devs who tweak code into submission without understanding the problem in the first place end up bandaging wounds with band-aids. The bleeding will start again, and soon. 5. SHE FLIPS THE BOZO BIT ON THE CUSTOMER AND / OR PM. Great devs realize that the user and the customer matter, deeply. If these stakeholders or their representatives (PM) are unhappy, that is meaningful, important, and offensive. A dev who shrugs a customer off as "precious", "unimportant" or "stupid", or (even worse) who silently doesn't respond to the PM's priorities is playing some other game which has nothing to do with building great product. 6. HE'S MORE INTO TOOLS THAN THE PRODUCT. Every team needs a great toolsmith. Many great developers spend a bunch of time improving the team's ability to develop the product. BUT, if the conversation seems to be all about the tools and the process, and these changes aren't triggered by a product need, you may be a victim of the pointless tweakers. Tool changes are expensive and disruptive. Needless tool changes are a sign of a lack of engagement. 7. SHE DOESN'T CODE LATE AT NIGHT OR EARLY IN THE MORNING OR BOTH. People who love coding seek out that flow and solitude that happens in the wee hours. Devs who are passionate love coding. A dev who clocks in and out isn't really engaged. This doesn't mean that everyone has to be only working, but that great devs find a way to structure their time to get uninterrupted chunks, and that is when the magic happens. 8. HE DOESN'T USE THE PRODUCT LIKE A USER. Users are gold. They are what matter. Great devs love to delight them. Developers who only ever look at the product locally, in a full screen window, on their top of the line 17 inch macbook pros using Chrome, are just not paying attention to the user. A great dev has one machine that absolutely sucks, over a flaky 802.11b connection so he can "feel their pain". 9. SHE CAN'T DO MATH IN HER HEAD. It might seem silly, since we have ubiquitous calculating engines, but, in my experience, great devs are always doing that back of the envelope calculation in their heads. The thing the machines can't do for us is to tell whether something makes sense. Great devs are always asking themselves whether it does, and that means a ballpark measure on demand. 10. HE GIVES ESTIMATES WITHOUT THINKING, AND MISSES THEM WITHOUT APOLOGY. Everyone understands that lots of development tasks aren't exact, but great devs learn how to get it right, or right enough, and even more so, to pay attention to when they get it wrong. A dev who can't hit a date and who doesn't take that seriously is forcing you to leak team integrity. Your promises depend on their promises. What does it mean if he doesn't care?