|
I have often pondered what traits make for a great software developer. There is an abundance of good ones, but what are the traits that make a truly great one. Here are my own personal thoughts on what separates a good software developer from a great one.
1. Technical skills and knowledge. This obviously goes without saying. A great software developer must possess strong technical skills, be a fountain of knowledge in their chosen field (whatever that is), and be the goto person who has the answers (or at least can point you in the right direction). This person has a solid understanding of their chosen technology and regarded highly by their peers and associates.
2. Is not precious about always being right. They are happy to be proved wrong, and embrace the opportunity to learn something new from a given situation. I have come across many developers who are quite combative in their approach, and rigid in their thinking. They think that their way is always the best way (or worse, the only way). Instead, a great developer will go "Wow I never knew that, that's a great idea". They embrace new ideas and are willing to learn from situations in which they arise.
3. Remains calm under pressure. I have worked with many developers who simply crack under pressure, and create a lot of negative energy around them when they do so. They get frustrated, angry, and snap at other members of the team. As the pressure increases, so does the amount of friction and negative energy that they create. They are not good to be around under pressure situations.
4. Willing to make a stand for quality. I have admiration and respect for those people who are willing to make a stand for quality. Those that care about the end product because they see it as an extension of themselves. Their name is associated with the product, so they want to ensure that it is of sufficiently high quality. That doesn't mean spending endless time implementing every design pattern and new feature, but someone who will ensure that the product has gone through the appropriate checks and processes to ensure that it is of the highest quality possible given the constraints of time and budget and is willing to make a case to the business to ensure that this happens.
5. Passion. For me this is the defining quality between a good developer and a great one. They get excited about technology; they want to get their hands on the new shiny tools and technologies as they emerge. Software development is more than just a job; it is an integral part of the person's personality. They love nothing more than discussing technology and passing on what they know to others. Their passion is infectious and is always invaluable on any project in which they are involved.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
The definition of a programmer[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
It's frustrating when you put your heart and soul into an article only for someone to quickly dismiss it by giving it a poor mark. It takes time and effort to write an article. Researching the subject matter, proof-reading etc. And it can take a second for someone to dismiss that effort with a poor mark.
Don't get me wrong, I welcome constructive criticism as I certainly don't profess to have all the answers, and I enjoy learning as much as I do teaching.
But when someone gives you a poor mark for an article, and then cannot justify that mark, is very frustrating.
To mark an article I would expect (demand) the following criteria are met as an absolute minimum.
1. Have read the article in its entirety.
2. Be sufficiently familiar with the subject matter of the article to constructively criticise it.
3. Ensure you have fully substantiated your mark with detailed technical information.
4. No personal attacks, sarcasm or other similar derogatory language. Comments should only address the technical content of the article.
If these criteria are not met then don't expect me to take your mark or comment seriously.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
Some developers seem to want to post questions on technical forums such as this one, and be supplied with a fully qualified answer, without so much as lifting a finger to research the answer for themselves. This is just laziness. How will they ever learn to find information for themselves?
There is a skill in finding information, and gradually solving your problem. I have got stuck many times finding a solution to a problem, and will explore many alternatives and sources to exhaustion before I post a question on a forum.
All developers should read this article before posting on a technical forum http://mattgemmell.com/what-have-you-tried/[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
A pet peeve of mine is the use of the var keyword and especially for declaring value types such as int, bool etc.
var mBool;
var myInt;
These are value types and IMO should be declared using their intended type. Why let the compiler infer the type at runtime when you already know the type at compile time?
The same can be said for reference types too.
var myString;
var myCustomer;
var myTransaction;
I can see why you would use the var keyword when working with LINQ (where the var keyword was actually intended to be used), but fail to see why you would use it elsewhere.
modified 23-Oct-14 2:58am.
|
|
|
|