What non-technical skills do I need? [closed]

Question

Apart from:

1. being strong technically
2. 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...).

Answer 1

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".

Develop Empathy

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.

Be Assertive

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.

Answer 2

Don't know if you are counting this somewhere under the first two

3. Knowing what's important and what to disregard

Answer 3

Here would be some other skills that I'd note:

1. Problem solving - How well can you create a solution for a given problem? How well can you diagnose what is the problem and what are the trade-offs of various solutions?

2. Learning quickly - How fast can you acquire sufficient knowledge to finish a task in something you had never heard of before today? How well do you know your best learning style? New versions of software, programming languages, platforms and tools can change a developer's life and this has to be managed.

3. Time management - Do you know how to make the most of the time you have? Do you know where to allocate your time to get the best results? In some ways this can overlap with one as sometimes a problem requires a quick solution such as when people go to the hospital and triage has to be done to see who gets seen first.

4. Managing yourself/attitude - While this may seem rather vague in a sense, the idea here is how well do you project a Professional mindset in your work. Can you get right to work or do you have a bunch of things to do before starting to work? How responsible are you in handling what you have and communicating if it is too much or too little?

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.

Answer 4

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.

Answer 5

Being skeptic to a certain amount.

Answer 6

A pleasant personality. Helps when working in teams.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

English (if it's not your mother tongue).

Answer 15

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.