11 Tips to Be a Better Software Engineer

Written By John Sonmez

1. Get a Programming Mentor

If you want to accelerate your programming career, there’s few things more effective than having someone mentor you on this path of professional growth. For one, you’ll be more motivated to go after your goals with a mentor watching over you.

They’ll also be able to point you towards the best resources for your current stage of learning. And finally, your Software Engineering mentor can give you valuable industry insights and connections that you never would’ve had access to on your own. 

2. Think like a Computer Scientist

A programmer is somebody coding different functionality into a program.

A Computer Scientist, on the other hand, is someone who figures out solutions to problems from a high-level view – and will also likely use code to implement a lot of those solutions.

This kind of work is more all-encompassing and demanding, allows for more growth, and is more well-paid. Which is why I encourage you to think like a computer scientist, not a programmer.

Don’t limit yourself to being someone who codes program features. Also be the one who’s creating the high-level solutions.

3. Know how to approach your development tasks

Start any project by listing the work items you’ll need to complete, and put them into the most efficient order.

Then it’s not just about coding each item – you should use the principles of Test-Driven Development (TDD): If you want to approach your development tasks optimally, you’ll create unit tests for each piece of the software as a form of quality assurance.

In the end you want to have achieved code coverage – you have tests for all bits of your code. Now, write code that’s only as complex as it needs to be.

Finally, refactor your code to make it even better.

4. Stay clear of code katas

Yes, you need to do a lot of coding practice if you want to be a better Software Engineer. But – you need to be smart about how you practice. It’s not about mindless repetition, which in the long won’t help you improve your skills at all.

Most people’s version of doing so-called ‘Code Katas’ is a waste of time.

Here’s what to do instead: Constantly give yourself new challenges. Try to solve new problems, or old problems in a new way. Up the difficulty of your practice, and soon you’ll find your level of skill has increased along with it.

5. Practice deliberately

Don’t just ‘practice programming’. Practice it in a way that’s challenging, purposeful and measured. You can apply the principles of deliberate practice to improving your coding.

It starts with setting goals that aren’t mushy, but can be exactly measured. Clear, focused, and with a deadline. Then break it down into skills you need to improve so you can achieve these goals. Set up a practice plan for yourself, and execute it using Ericksson’s laws of deliberate practice.

At last it’s time to review your efforts, ask for feedback, and reiterate your process if necessary.

6. Re-think code comments

Are code comments as much of a great idea as people make them out to be? What if they’re a crutch for code that’s too complicated and not optimally named?

In fact, if we can rewrite a piece of code with clear naming, delete comments, and it comes out more readable than before, then that proves code comments are mostly a bad idea

7. Respect levels of abstraction

A great way to make sure you’re implementing best practices is to respect the levels of abstraction in your code.

This means you’re focusing each piece of code on either a low-level task (say, computing a necessary math operation) or a higher-level one (like evaluating a portfolio). The levels of abstraction build on each other, but you never mix them in a single piece of code. You respect them as a separate entity.

To do this correctly, you’ll have to pay special attention to good naming, class cohesion, readability and more – forcing you to write better code.

8. Obey the KISS principle

Keeping It Simple, Stupid isn’t easy to do in practice. You need to be a great abstract thinker and a competent Software Engineer to carry out the KISS principle correctly in your code.

Your goal should be to create software with as few statements as possible. Your program will be more readable to others, have less potential for bugs, and be easier to refactor.

But achieving these things requires much forethought and skill of execution. 

9. Understand the two purposes of code

Algorithms and coordinators are the two roles our code has. We should divide these roles into distinct classes. That way, none of your algorithmic code has dependencies on other code – making for code that’s less complex as well as easier to test and reuse.

Strive to not use mocks. Create separate classes for algorithms and coordinators. You’ll improve your code design and make something that’s easy to understand and work on.

10. Protect your passwords

Beyond the obvious tips like not storing passwords you need in your Software Engineering job (or your private use) in cleartext or showing them to other people, there’s advanced methods for programmers to protect their passwords.

Once you understand how the common attacks – dictionary attack, brute force attack, rainbow table attack, offline cracking attack, collision-based attack – work, you’ll be able to take proper steps to prevent them.

Namely you do this by choosing strong passwords, and also by maintaining a cryptographic storage with the correct hashing algorithms.

11. Read Fiction to Become a Better Programmer

Wait, how could reading seemingly unrelated books (fiction even!) ever make you better at computer programming?

For one, these creative books help you with outside-the-box thinking. New connections are sparked – and some of them can lead to a brilliant idea for your work projects you wouldn’t have gotten otherwise.

Reading fiction can also help you recharge and recover from your programming work.

As if that wasn’t enough, engaging with high-quality prose can improve your own sense for words. It’s easy to imagine how that would help with any writing tasks on the job.