5 Crucial non-technical skills every developer needs to work on -

A big assumption we may make as developers is thinking technical skills are the single and most important factor needed to accomplish our tasks. However, technical skills is only one aspect of being a developer.

There are non-technical skills that are equally important for developers. For example, if not more important than the software program itself, is to ensure the output actually meets the needs of the end user. If you work in a team, the ability to collaborate effectively with your teammates and work with people who don’t have a technical background is also crucial. These are just samples of situations that involve using non-technical related skills.

There is a lot more involved in the process of seeing a project from start to completion other than the ability to write code. Whether working on a solo project or with a team, we should place importance on building non-technical skills.

Here are 5 non-technical skills important for every programmer to start working on.

1. Requirements Gathering

Knowing what your users want.

What use is a software program that doesn’t do what it’s supposed to?

Even if it’s something you’re developing for your personal use only, making sure the final product meets what you want is still worth thinking about from the beginning.

This is where requirements gathering comes in. Before you write a single line of code, at the very least, make it a habit to write down what you actually want the resulting program to do.

A customer focused approach is key here. A customer in this case is anyone that will make use of the software. We want to deliver something that will be of use in the end. If this application is for yourself or for fun, then YOU are the customer (although this makes requirements gathering a lot easier).

Regardless of who the customer is, answering questions such as the following is a good place to start:

What is the minimum functionality required?
What are the use cases?
What are the supported environments and or platforms?
Are there any security considerations?
Are these requirements testable?
Have the requirements been confirmed?

Answering these questions will help in writing a complete program that not only does what it should, but does so efficiently as the required functions can be integrated in a structured manner.

Keep in mind, when developing applications for someone else it’s not unusual for requirements to change with time. So part of this process is always keeping in communication with the customer and ensuring there is a constant review process in place to keep the development in line with any potential changes.

Knowing the importance of taking the time to draw up requirements and actually forming a detailed set of requirements is a skill worth being aware of and learning about.

This skill is especially important if you work in management or lead roles in a software development team. Having a customer focused approach from the start of the development process will save your team a lot of time and effort as it helps ensure the needs of the end user can be met as closely as possible.

2. Accepting Feedback

Never stop finding out what your users want.

So you’ve delivered a project and are certain you captured most of the requirements. A few weeks later you receive emails or reviews with comments stating the product doesn’t do what it should.

How could this happen?

Well, maybe you hadn’t captured requirements as well as you thought.

Just accept that it’s impossible to get everything completely right.

The end users could realise what they thought they wanted isn’t actually what they wanted (Yes, this happens). Or maybe the user experience isn’t as smooth as it could be, resulting in complaints.

Either way, the important factor here is to always accept feedback you receive and review them to see what can be done to resolve them.

Let’s say you developed a mobile app and just launched it. You take a look at some app reviews and see a lot of negative comments on a certain functionality of the app. If users are complaining about the same thing, it’s likely to be a real problem. Don’t ignore this and check it out.

Letting go of some pride here and accepting things need fixing is just as important as being able to develop the app in the first place. After all, you went through all that effort to deliver it, why wouldn’t you want to make sure the end users are happy when they start using it?

Also, other potential users wanting to download your app may be put off by the negative comments. That would be a shame especially if the problem is one that could be fixed easily.

If it was an application you developed for yourself and you discovered something majorly flawed with the design, wouldn’t you fix it? So why wouldn’t you do the same for an application you wrote for someone else?

Part of the work here is putting some extra effort in keeping an eye on a project after shipment and handling feedback in a professional manner.

This is a critical non-technical side of development to pay attention to, especially for developers who release programs for use to the public or to clients.

3. Being a Team Player

Help one another and share the knowledge.

No surprise here. Being able to work in a team is an essential skill for most professions and for the software developer, it’s no exception.

There are many ways to improve your ability to work in a team. The most effective ways involve a change of mindset. Let’s go through some of these mindsets.

Sharing knowledge is caring

I’m a huge believer in sharing knowledge with others. If the people I’ve worked with kept their knowledge to themselves how could I have gained knowledge myself? If people online didn’t share their knowledge for free, how could I have fixed all those bugs and compilation errors? Imagine a world where free sharing of knowledge wasn’t available?

Not a nice thought is it? So keep the knowledge going round by willingly sharing your own knowledge with others!

Learn to accept help

We don’t seem to have any problems asking Google for help. So why should there be a problem asking a fellow team member that’s likely to give insight into a problem you’ve come across?

“There’s no such thing as a stupid question” is the mindset I like to have.

Asking questions to your teammates will not only help you when you’re stuck, it will help your teammates realise they can also ask you questions. This way everyone is happy as we can get over any blockers to our tasks quicker.

Consider the opinions and suggestions of others

No one likes it when their thoughts are brushed off and not acknowledged, so don’t do the same to others. If a teammate is speaking out on something they believe needs improvement, it’s important to consider their point. This keeps a friendly, open and encouraging environment and improves team spirit.

Being a team player is an essential skill to have as a developer and requires effort to build up. If you work for an organisation, you likely work within a team. If you work solo, you are maybe involved with open source projects. Regardless of the scale or nature of the team, make a conscious effort to improve your ability to work effectively with others.

4. A Habit of Documenting

Write things down, it helps.

Developers write code, so why do we need to know how to document? These are just a few reasons you need to work on your documentation skills.

Requirements

As covered previously, requirements is an important list or document detailing what the software program should do according to the needs of the end users. Being able to write these down in a clear and actionable manner is a skill in itself. As you get used to documenting requirements, you’ll become better at capturing the key functions that need to be monitored throughout the development process.

Bug tracking

“The program crashes occasionally, needs fixing” – What a lovely explanation right?

Well no. When reading bug reports, what’s worse than getting a bug reported is not knowing where to start with the investigation. Documenting the details is important when reporting bugs.

What version are you using? What were you doing when the program crashed? How many times has it happened? Do you have logs from the program at the time of crash?

Get used to writing detailed reports of issues you come across.

Usage documents

It might not be fun for everyone to write, but all those READMEs you rely on to tell you exactly how to build, use or run source code you come across on the web are as important as the source code itself. No one wants to waste time figuring out how to do something that could be explained in a document which is not that difficult to put together.

Code comments

Comments are valuable for several reasons. If you treat your comments as part of the documentation process you can pay more attention to writing useful comments. This makes things easier for someone else reading your code, and for yourself, when you need to revise your code in the future.

I also place comments under the skill of documentation because if planned well, comments can form part of official documentation. For example, tools such as Doxygen allows you to generate documentation extracted from comments if they are written in a specific format.

When you see a neatly documented API reference manual that clearly explains a function, it’s parameters and return values, that’s a result of someone taking the time to write comments carefully and using document generation tools such as Doxygen. So here’s a code related aspect of documentation for you to work on (and honestly, something I need to work on myself!).

Documentation in the context of development is mainly about ensuring others and your future self have enough information to pick up the project.

So as you would want others to do for you, do for them i.e. document!

Related: See this post on how Trello can help document development related work.

5. An Attitude of Continuous Learning

You’ll never know it all.

While the skill of learning to program is certainly technical in nature, it takes a skill in itself to have the mindset of continuing to develop those skills.

Technologies are constantly evolving and we need to keep up to date. You might also find yourself learning a new framework for every new project you start because that’s what’s needed to deliver.

There are two main factors I believe are crucial when it comes to continuous learning.

First, it’s important to have an openness to learn.

To avoid becoming stagnant in your skills, the willingness to actually learn new things is important. If you don’t already have this mindset, start working on it. It comes as part of the package of being a developer.

Second, be aware that the discipline of self-learning is crucial.

When you accept that you need to learn, how do you actually achieve this? Some organisations may have workshops or send developers to training courses to get them up to date on a particular technology, framework or programming language.

However, this isn’t always the case and more than likely you need to learn new skills without formal training.

If you work as a solo developer this is something you have to take the initiative on yourself. Whether you work solo or for an organisation, it’s important to know how to teach yourself new skills and technologies.

This goes for both technical and non-technical skills by the way. Learn to develop both, and learn to take the initiative to do so yourself.

There are more than enough resources available on the internet, whether paid or free, and you just need to make use of it.

Just by reading through this post you’re already taking the initiative to learn!

Conclusion

There are skills not directly technical-related but maintain an important role in the process of developing software. These skills are crucial for every developer to have and in some cases, is as important as the task of writing code.

Whether you work alone or as part of a team, growing these skills should be part of your priorities and will enable you to stand out as a developer.

What are your thoughts? Do you need to put more effort into developing non-technical skills? Leave a comment below.