- being strong technically
- being able to communicate effectively
What are the most important formal / informal skills required to really shine as a developer?
(Naturally, I struggle with the first two, but even so...).
Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.
In addition to all the answers posted on that question and this one. There are so much to suggest. Here are few things I try to improve myself everyday.
Develop your interpersonal skills
Keep your word, always
The more you will do this, the more people will trust you. You will get more opportunities to get better. The key here is to not commit on things you know you won't be able to achieve. So learn to say "no".
You must be able to put yourself in other's shoes. This includes your colleagues, but also your users, managers, the insane sales guy or the crazy marketing girl. By practicing this, you will be able to identify what are their interests. You will discover that while they are most of the time very different than yours, it's possible to create a win-win scheme with them.
Anger, fear, jealousy, shame, etc. They are all created by your mind. Understand you decide how to respond to events. "In between stimulus and response there is a space, in that space lies our power to choose our response in our response lies our growth and our freedom." Victor Frankl
Develop your problem solving capabilities
Know when to unlearn.
I like the concept of creative destruction. This has nothing to do with communism! ;)
Experiment, Fail, Learn
The more you will fail, the more you will learn. Be sure to learn from your mistakes.
Don't say in your comfort zone
The more you will leave it, the fastest your will learn new things. Interest yourself to the business. Instead of taking lunch only with technical guys, try to go with the suits some times.
Develop your physical skills
Invest in your body
Doing sport regularly will not only improve your overall health, it will improve your ability to think.
Know your limits
Take regular pauses. This will boost your productivity.
I also suggest you to have a look at this great book on the subject.
Don't know if you are counting this somewhere under the first two
Here would be some other skills that I'd note:
These are all big things that I use on a regular basis and am still developing as new stuff keeps coming out all the time.
Getting Stuff Done
You can be as savvy as you want, but the bottom line entails getting stuff done, and in a timely manner.
Stay on schedule, learn how to plan and project, network effectively, and have deliverables.
You need to align your interests with what the business values.
Geeks are often not great at considering the wider context of their work. Many products fail because developers build it using technology/methods that interest them at the time. They aren't thinking impartially about solving the problem in the best way for the business.
If you can consistently solve problems in the best way for the business then you are on your way to becoming a great developer.
Social perception is never a waste of time to develop. Please don't confuse it with empathy. When social skills don't come naturally, you must be able to identify and understand the implications of any cognitive bias in those around you, and also in an introspective sense. You must also be able to fit in with others without needing to conduct multiple breaching experiments. (Does this sound to anyone like the smart person who tried too hard to fit in?)
The article I mentioned suggests something called "Implicit Personality Theory", but I caution anyone against making assumptions. If in doubt, don't.
Finally, learning how to 'not think like a programmer' comes in handy, especially when dealing with the opposite sex or designing user interfaces.
The main of non-technical skills is what called common sense. It may be not obvious but to clearly look on the things is rather hard in some situations.
Also, it is always necessary to think about user experience while developing anything. So, the abstracting skill, which will divide you from your product and make you think like user is also valuable.
The ability to agree to disagree. You will be forced to work with people who don't agree with you and never will agree with you. This doesn't need to be a source of conflict. In fact, it's a good thing! Would you really like working only with people who are just like you?
There's a peculiar kind of empathy that I have found useful in making additions or fixes to the code of another developer. Most developers have a coding style that is somewhat akin to the style any artist or craftsman evolves towards his art/craft. Programmers have an unusual craft in that it is highly likely that when they leave a project the project will continue in the hands of some other programmer.
When I am that other programmer I tend to read through the code, get an overview of the structure of what's been created and follow the design decisions the original developer made even if I personally wouldn't have done it like that. I don't know for certain whether that's right or wrong but I do know that in examples I have seen of systems that have had a change of dev team more than twice the resultant mess of conflicting design approaches and coding standards slowly begins to undermine the original system.
Even in systems I've seen where one developer has programmed bits one way and then a second developer has taken on a subsystem or modification and just arbitrarily changed the underlying design ethic it has tended to cause severe problems in implementation, bug-fixing and so on. Essentially two bits of half-built system don't make a whole system, they make a mess. It's like someone building a suspension bridge and then another engineer replacing the middle with a bridge on a columnar support while trying to leave the ends suspended.
I think what I'm talking about is an appreciation of what someone else has done, good and bad and a willingness to undertake not to make things worse. Particularly not in the most pernicious way "making things worse by trying to make them better".
It's not a skill I've seen many others exhibit so maybe I'm just crackers, but personally I have found it has made things smoother in my day to day programming life.
Persuasion Don't confuse with coercion. You're going to get management demands, user requests, and other developer's opinions, so you better learn how to handle them when you think they are wrong. If you just take it, you'll drive yourself nuts in this business. Being able to persuade people will require: communication, empathy, logic, social skills, tact, understanding of the business, etc. You will also learn what battles to fight because nobody wants to be the person who disagrees with everything. Try to keep in mind that you're doing these people a favor by using your technical expertise to identify and solve problems.
Have a thick skin. Don't get insulted or upset at every little thing. Most stuff in business is not meant personally. They did not pick C# for the project to personally annoy you.
Learn to work with people you dislike. There will always be people you dislike in any large workplace. Deal with it. BTW if you compliment people that you dislike when they (perhaps by sheer chance) do something right, it will make your criticisms be more meaningful. If you acknowledge the good, then people won't dismiss your comments about the bad as "Take that with a grain of salt because he hates Joe."
Criticize actions not people. Learn to sense when the timing is right for a criticism. Saying, "we need to redo this from scratch because it..." 2 days before a deadline won't make you any friends or business allies.
The time for input is before a decision is made. You only make yourself look childish and stupid for whining about it after it is too late to change. You look unprofessional to refuse to implement a decision you disagree with and are at risk for being fired. All employees in all professions always have to implement some decisions they disagree with. That's part of life. If you don't like the direction of most of the decions being made, either become one of the decision makers or move on to a place that suits you better.
Compliment people often, especially in writing to their bosses. Especially compliment people outside of IT that you have to work with to develop internal projects. Say please and thank you. But don't give fake compliments (people can usually tell), you don't want to sound like a sales person. People work alot better with people who are nice to them and who they feel appreciate them.
Make your case for changes you want in business terms not in technical terms. Managers don't care that it is the cool new technology that you want to learn. They care that it solves a problem the old technology didn't solve or didn't solve well. A real problem that the organization has, not a problem described in the marketing literature for the product. Learn to create a decision analysis document. When you show the pros and cons in writing, it is alot easier for the managers to accept your ideas. I have never yet lost an argument when I had a decision analysis document to show them why what I wanted was the best way to go.
The amount of input you have in an organization is directly related to your organizational position (managers have more input, it's a fact of life) or the respect that you are held in. You may not want to be a manager, but everyone can strive for being that respected employee who is always asked for input informally before the manager decides. You get that respect by delivering product, by behaving professionally, by showing that you have in depth knowledge and sharing it (become the person others go to when they are stuck), and sometimes by being consistently right when others are wrong (but not by being snotty about it). Junior employees almost never have much input into processes, design, tools, etc. Seniors almost always do. Whether you make the leap from junior to senior often depends as much on your attitude as your ability.
Am surprised that hardly anyone has mentioned one important skill: at least rudimentary business or finance skills. Considering that programming may even take you to industries dealing with financial domains and services, this skill would help you a lot.