Typically when you think of skills that software engineers need to have, you’ll hear what programming is the best or which framework is the best. You’ll see developers go back and forth on forums on why Agile methodology is better or why Scrum is better. I’ll go over the 3 skills that developers ignore and why it’s beneficial for you to add them to your toolkit. 

Git

To be quite frank, learning Git is easy if you’re utilizing it at a basic level. The thought of learning Git flustered me as well. However I only needed to know the basic commands to do my job.

I recommend downloading a Git GUI called SourceTree. This tool helps you visualize your Git branches and helps you understand what’s going on in the git repository. It has helped me tremendously and I still use it today. 

Why should you learn Git? When you are coding on your own, there is no other version of your code floating around somewhere else. The only version of the program you create is the one that you have on the machine you’re working on. 

When you eventually start coding with more people, you’ll sometimes find that you and your coworker are modifying the same file. This creates conflicts within the code. 

Git helps relieve this conflict by merging your code and your coworkers changes into code base.

Committing your code is much like saving your progress at a save point in games. If you die during the mission, you don’t have to start over. Just continue at the latest save point. 

Commiting your code is pretty much the same concept. You are saving your code at a point in time. Let’s say the new code you added breaks your program. You can go back to the latest commit at a point in time where your program was working normally. You can do this an unlimited amount of time. 

Git also keeps a copy of your repository on the cloud. Let’s say your computer suddenly dies or your hard drive starts smoking and dies on you. You don’t have to worry about losing everything you developed. If you backed up your repository frequently, you can just clone the repository on a new computer and pick up where you left off. 

I won’t go into too much detail about Git, but these are the commands you should master: add, pull, push merge and branch. 

Testing and Debugging

Nobody likes writing tests, especially for code that they’ve already written. I have to write code for the code I just worked on? No thank you.

As a result, developers often ignore testing. It’s because developers lean towards the happiest path, aka the path the code is based on. This path is bug-free and often not realistic once the code hits production. 

Ask any developer, they’ll be quick to tell you what their favorite programming language is, not what their favorite testing framework is. 

Developers are quite optimistic about the code they write. Oftentimes, the person writing the test isn’t the one that wrote the code. However, testing is still important in software development. 

How do you convince yourself to write tests for your own code? Well, testing actually proves that your code works. Also, testing saves you time since you don’t have to manually test the code end-to-end. Testing covers edge cases that you may not detect initially, making it more robust. 

You’ll stand out if you write tests for your code, since most developers don’t do it. 

Debugging. 

You’ll soon discover that code you’ve written (and code someone else wrote) will break and you’ll have to find the culprit. 

Debugging is a slow process that requires a ton of patience. I’ve spent hours debugging, only to find out that I could have found the bug within minutes if I didn’t assume a component worked correctly. 

And that’s the lesson I learned. Assume nothing and question everything until proven right. 

Debugging isn’t a skill you can pick up right away. Nor is there a course that teaches you how to debug. Debugging is a skill that is gained overtime. Improve your code reading skills and learn how to navigate through unfamiliar code. Doing this frequently will make you a better developer. 

Business Sense

This is something that I’ve advocated for for a long time. This is what being an all around programmer is all about. 

I’m a big believer in developers needing to understand WHY the project/product is being created and HOW it will generate revenue for the company. 

It creates an overall well-rounded outlook and a reminder that no one is working alone, that we are connected in some shape or form, whether it be the IT department or the Finance department. After all, you are not hired to simply code for the sake of coding. Rather, you are satisfying a business need for the company to make money. 

Can you still be a developer without business sense? Absolutely. But the most effective developers (those that the company values most) understand the business. They become leaders and leaders get paid WAY more.