10 ways to know you’re actually a great developer
This post might seem as stating the obvious. But for a lot of developers it is not as easy to assert their own value to the company, community or world they live in. Despite what others think of them! In a nut shell: Great developers have a knack for greatly help progressing a project they work on in unexpected (or unintended) ways.
At various moments during my work in the past years I encountered quite some of these positive contributions in work either created by others or by myself. In one of my recent "Eureka" moments I decided to brainstorm a bit and write them down so others might recognize them in themselves or in others.
As an added bonus, I also describe what the default behavior would be in such a case so you can avoid the pitfalls.
(Please note that the list is not in any particular order!)
1. You start 'decompiling' the problem while it is described to you. Even before you started actively working on it.
Someone describes a problem to you, and you immediately start taking a step back in your mind and create a birds-eye perspective of the problem. You start to look at in an abstract way, in terms of components or parts working with each other. You start asking questions, not about how it would function, but how certain sub-parts need to function to make the whole system work.
Standard Behavior: The default mode when a problem is described to you is just listening to what is said. Afterwards the developer starts to break down the task into subtasks. When you're just starting in the programming world, it isn't all that abnormal that you can't do this immediately. It's like reading between the lines in a language. When you start learning the language, you won't notice the subtleties.
2. During a project people start to rely on you for information or resources
Normally you receive tasks and complete them in the allotted time and continue to the next task afterwards. However when you get more information about a project, and can order it right in your mind, the project will start to become an entity which can shape and form into something more. You create a 'bigger picture' for yourself about the code as well as the project as a whole. This unique perspective can be very helpful to your fellow developers, management, stakeholders or third parties needed for the project. This is a quality that is very, very, useful (if not required) for Technical Leads, as they are required grasp the bigger picture and act on it.
Standard Behavior: Developers stay within their scope of the problem. They solve what is asked and wouldn't think any further.. Beyond the problem itself and how his code will affect other parts of the system. This is probably a mindset, some switch that needs to be flipped. Or just a general lack of interest in the company (if the last one, get the hell out of there!). Of course the right mindset is no guarantee. It is entirely possible that there is no need for your unique perspective. So there will be no relying on you.
3. Coming across a difficult problem, you take out your notepad and scribble things down
It is virtually impossible to create solutions purely in your head. You are bound to make mistakes or forget things you thought up earlier. When you realize a problem is too large to fit in your mind, you quickly fetch your notepad and start writing down the problem and it sub-problems, tackling every sub problem one at a time.
Standard Behavior: The developer will probably think of something that is a step in the right direction, but won't entirely solve the problem. He will continue on the path and come across a new sub problem, and another one, and another one. Eventually they will either create (working?) spaghetti code, or end in an endless coding frenzy.
4. You discuss solutions with someone (or yourself; explain it to the duck) before definitely going for either solution
The first solution might not (probably won't!) be the best solution for the problem. Coming up with multiple solutions and discussing them is key to getting the best result. When having multiple solutions, you can choose what is best. And, you have a reference which can helps you choose.
Standard Behavior: Think of a solution and go blindly for it. The solution is easy, just think of more than one solution 
5. You don't just say "No!". You say "No! But we could..."
They say it is hard to say 'no' to something. Although this is certainly true, it is also true that when you do say no without anything else, all progress will halt and you go into a yes/no debate. Giving an alternative solution or suggestion goes a long way.
Of course this doesn't really count for obvious situations where you are required to do an 8 hour job in 2 hours. Although in this scenario you could say: "I can't complete this task in 8 hours, but I can give you <part of the job> in 2 hours".
Standard Behavior: Just yelling and screaming (well maybe not yelling and screaming...) that something isn't possible without giving an alternative or reason.
6. You just know an idea stinks, but can't quite formulate what it is... Yet!
When a task/job is described to you, your gut wells up and you feel it is wrong in so many ways. This is something you act on. You find out where this feeling comes from. It is important you do this, because the feeling comes from somewhere. You don't rest until you find it. And when you do, you find out it is a fundamental problem of the idea. You suggest an alternative or fix to the idea which might be something seemingly small, but can have a large impact on the whole project.
Standard Behavior: Ignoring the gut feeling.
7. You know when it is time to call in the cavalry.
When knee-deep in the project, you find out the work is much more than you thought at the start or you realize you don't know everything you need to know. You realize the project is important so you ask for help. This can be done by either asking for more coding power (when there is more work) or asking for help on the topics you lack knowledge of. You don't just "grunt through it" as it will probably create spaghetti code. If, despite your warning, you are asked to continue the project anyway, you know you can fall back on this statement later when the proverbial feces hit the proverbial rotating blades. You could also decide to cut your losses and quit the project to protect yourself.
Standard Behavior: Continuing as you where. This is very normal and safe behavior. And for a while it seems to work. You continue because you don't want to let your manager/boss/client down. But while you do so you might end up not making the deadline. Most of the time fear plays a part in this scenario as well. When you ask for help it feels like giving up or acknowledging that you are weak or incompetent. But thats not true, you just acknowledge the task is not a 1 man job, or requires some specific knowledge that you don't yet have.
8. You say so when realizing you can not deliver what is asked
Some projects may seem right up your alley, but soon you realize you didn't had all the information required to make a good assessment. This is the time you speak up! It takes balls to do so, and it probably won't be an easy conversation. But you know that for both parties it is the best thing to do. You know that it is best for yourself too, because when you continue, you will end up with a lot of extra stress which could be prevented.
This one may seem like the previous one, but has a fundamental difference. In the former we speak of lack of information or time. In the latter the problem lies within the core of the project. Something that can not be solved with extra information or manpower.
Standard Behavior: Just continue and grunt on. Thinking you will learn as you go along.
9. You complete tasks more quickly than others
Last week you were working on a task and after lunch your manager came to you and asked you and your colleague to do some quick things on a project you are both very familiar with. In a rather small amount of time you rush through the requests and you go back to your regular work. After a while you notice that your colleague has only just finished his tasks. Strange, but he probably had something that turned out to be more difficult. Over time you notice these kind of things more and more. Still strange? No not really, you are just a great developer, one who has knowledge and experience and knows how to apply it in different situations. And as a result finishes all kinds of tasks more quickly. It seems a bit cocky to say. But you can measure your skill level by comparing how you perform in relation to your peers.
Standard Behavior: Well this one is kind of obvious, you don't do things faster than others The solution? Practice makes perfect! So code some more, explore the program some more, experience with certain features.
10. Creating sound code, even when you think you created absolute horsecrap.
Some times you are forced to create some code in little time. Despite the fact that you meticulously insisted on the fact that it can't be done in the alloted time, your boss/manager/client forced you to create it even if it would turn out to be crap. You start the work and are not proud of what you created. You feel kind of miserable with the work you delivered and in fact, you all you want is to remove the code and make it right. However, after a few days when you receive some requests for (seemingly huge) changes to the code you created, you find out you can make those changes quite easily because the code you created actually had structure in it and was made orthogonal to other parts so the changes where as easy as pie.
The lesson learned from such a revelation is that despite the fact you had to rush your work and probably won't get to be your finest work, you (subconsciously?) applied all your knowledge and created something developer worthy.
Standard Behavior: Ending up coding by coincidence or creating spaghetti code. This is done because it is thought that the time constrain trumps everything. Just start coding and all will be well is the general approach. As with decompiling while discussing a problem, you can't do right away. It takes time, knowledge of the programming language, experience and a way of thinking. Of course you can prevent creating spaghetti code and preventing coding by coincide by thinking before you do.
That sums it up! 10 ways to know you're actually a great developer!
Now don't think you're a bad developer when you don't recognize all of them, or maybe even only a few of them. It doesn't mean you're a bad developer. There are tons of reasons you haven't experienced them. Maybe you just started in the development world. Maybe you switched to another programming language and don't know the details of the language. Or maybe the company you work for is just not the right company for you. Or, of course, you're just really not that good a developer 