What Makes Great Developers Great?

Over the last few years I’ve been working with a lot of developers origin from different countries all around the world.
Some of them where really amazing, some distinctly “lustreless”.  
As recently I have a pleasure to work with rarely skilled, talented and ambitious individuals, I started wondering – why do I admire them? What makes them not only good, but great developers?
1. Passion
Some people may say that programmer’s life is boring. Typing thousands lines of code, debugging, bug fixing, and retyping again. Other would even say that it is the most boring job ever, but… it is not! Programming is an Art!  There is no single path to realize goal. Week programmers treat their tasks as duty, great developers – as yet another challenge. Every time when they solve an issue, they feel proud and satisfied. Kept in mind that there is always better way to solve an issue keep them “hungry” and learning new ways to solve it, satisfies theirs’ hunger!
2. Problem solving
I think I won’t lie if I say that 95% of programming is about solving problems. What differs developers is the way they act when another problem occurs. Week developers give up quickly and report to management that they faced issue which they can’t solve. Good ones will proactively search for solution. Starting from manual, through net to end up with senior colleagues. They won’t give up until they either solve an issue or really check ALL possible channels to find resolution, and even then – when they report an issue to management, they most probably have already workaround.

3. They read an errorerror-300x248

Errors are everywhere, some of them are really nasty, some are so called PICNIC (Problem In Char Not In Code) but most of them are pretty accurate. Especially for high level programming languages (unless you get lovely null pointer exception ;] ). And yes – sometimes you can get really ugly one which looks more like hieroglyph than Latin alphabet. When that happens (and it does more often than we all wish) there are 2 options. Weak developers will immediately call someone who is more senior and try to get rid of  (handover) responsibility. Good developer will dig into problem (see previous point), analyse and solve. Treat it as a challenge.
You think it’s ridiculous ? I think you would be surprise to see how many times I was asked by developers with >5 years of experience to help them with “weird” error. I couldn’t count how many times error was clearly explained in stack trace. All you had to do was scroll few lines down…
4. They can write and read code Yes, exactly! The same code might be written in thousand different ways and it’s up to developer whether he will write it in the way that anyone else will understand it. Good code is well formatted and described both, using inline comments as well as documented in specification. There is nothing worse that reading someone else’s code where function names doesn’t say anything about what they are meant for, there is no naming conventions, every now and then you see commented piece of code and every second variable has name: temp1 , temp3, fortest…
On the other hand, as long as code is written clearly shouldn’t have issue with understanding someone else implementation. That’s driven by 2 factors – knowledge and experience. Without deep knowledge on what certain native methods are doing it’s really difficult to understand even well written code. Furthermore, practice as always is a key. The same functionality might be implemented in 1000 different ways reading someone else code show us different approaches to solve same issue, as most probably we would do it slightly differently.
5. They don’t postpone 
Many times when we are requested to fix some small issue we find out other bugs or issues related to the same piece of code which may cause issues in the future. What most of week developers do? They ignore it, implement their change and finish task.  Good developers never ignore issues like this. They know that sooner or later but eventually it will come to back to them so they prefer to fix it right away. In Software Development, cost of fixing a bug grows with the time and can be hundreds times more expensive if we spot it i.e. after going commercial live.  Also from implementation perspective – if fix or enhancement has to be done on base/framework level, complexity of change is much lower if we do it right away.
6. They communicatetalking-guys-1382970-m

Sounds silly? There is nothing worse that lack of communication. I faced that issue so many times. Really good, technical developer was not performing well since they didn’t communicate anything to the rest of the team. Any issues, obstacles or show blockers. Lot of them won’t share their concerns until someone explicitly ask them if everything goes fine. Also from team perspective communication seems to be key to the success. I saw that scenario so many times. Daily stand-up meeting, everyone shares information what they done: