- 10 Tips To Step Up Your Game as a Software Developer in 2021
Photo by Grzegorz Walczak on Unsplash.
Want to step up your game as a software engineer in 2021 and looking for advice on what to improve on? Here are some tips on what you can focus on to become a better developer.
If you are a software engineer or architect (or you aspire to be one), then I think this is the most critical advice that I can give you. If you don’t know how to write clean code, then read up on the various books and blogs on the subject. Here’s a good starting point: Clean Code by Robert C. Martin.
It won’t hurt if you read it with a highlighter and pen because it contains so much great advice, but don’t make a habit of highlighting everything, as this book does hold some controversial opinions.
Version control systems (VCSs) have been around for many years, but nowadays, they’re so easy to use that there isn’t any excuse for not using them.
As soon as you start working with others on a project, do yourself (and everyone else involved) a huge favor and use VCSs such as Git. Don’t worry about merging conflicts and stuff like that if your project doesn’t involve multiple developers — just learn how to resolve them when they come up eventually! Just use VCSs! Use them! You’ll thank me later!
And please don’t ever commit directly to your main branch. Always create new commits for every change you make before committing to main. Always keep your main branch clean, readable, and deploy-ready! That way, life will be much easier for people who will need to merge your changes back into their branches.
If you’re collaborating on projects with other people, then take some time out now and set up an account on GitHub, Bitbucket, or whatever online source-code repository service floats your boat. It’ll save you lots of time down the line and help improve collaboration between team members too!
As a software engineer or architect, you will spend a lot of your time reading other people’s code. This is an incredibly important skill to have! If you find yourself thinking, “This could be written much more elegantly,” then it means that maybe the author didn’t really know what they were doing, so try to help them out by fixing things up for them.
But if this doesn’t make sense to you right now, then don’t worry. It took me years before I realized how important this really is. Nowadays, I can hardly stand to read lousy code anymore. It makes me feel physically nauseous at times.
Please learn how to refactor other people’s code as soon as possible and get used to doing it regularly. It’s one of the essential skills that you can acquire if you want to work as a software engineer or architect. Just don’t fall into the trap of thinking that your own personal style of programming is the only correct way of writing things. Instead, always try to follow the conventions established by your team or company (as long as those conventions are good ones). Consistency is key!
This is another vital tip. If you aspire to be a software architect or engineer, read as many books on software architecture as possible! Here’s a short list of some good ones:
- The Pragmatic Programmer by Andrew Hunt and David Thomas
Working Effectively with Legacy Code by Michael Feathers
Refactoring: Improving the Design of Existing Code by Martin Fowler et al.
Effective Java (2nd Edition) by Joshua Bloch
The Clean Coder by Robert C. Martin
Finally, I would like to recommend one more book that isn’t strictly about software architecture but is very relevant in modern-day software development: Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister.
It might not seem like it at first, but this book is all about how to work in teams and how to manage things (such as deadlines, expectations, etc.) so that everyone involved has enough energy left over at the end of each day/week/month to do their best work. It’s a bit old now, but it still contains lots of great advice.
If you use an IDE, then learn its key bindings because they will save you lots of time when coding. I prefer using VS Code for most things these days because it has really lovely code completion, super-fast performance, and an excellent command-line interface — along with being highly customizable via plugins, etc.
However, PyCharm is also good if you’re stuck with Python or if all your team members are using it already and you need to cohabit peacefully with them.
Another essential piece of advice is to always write good commit messages for every commit that you make. Well-written commit messages are a pleasure for other people to read because they tell them what the code does, why it exists, and how it works — without having to read the actual code!
They also help people who come across your code after a long time to understand its purpose. If you want some inspiration, then look at some of the great commit messages in the Linux kernel project. Just copy their style, and you’ll be fine!
Well-written commit messages can also become handy documentation for others in your team who might not know (or remember) how certain things work in your code. And if anyone ever wants to go back through your history, then well-written commit logs will be invaluable too!
This is another fundamental piece of advice that I hope most software developers are already following, but just in case you aren’t, I think it’s worth mentioning. In my opinion, every software engineer should know at least one scripting language such as Python, PHP, Ruby, etc. This helps you learn about fundamental concepts like flow control, conditionals, loops, and so on that are applicable regardless of what language/paradigm/methodology you use (perhaps with some minor differences).
You’ll have an easier time reading other people’s code too because all of these languages share many similar features. And finally, if any bugs arise that require manual intervention from someone else, then knowing a scripting language will make life much easier for everyone involved because being able to automate repetitive tasks greatly reduces friction and makes things more efficient!
A good example that I’ve seen recently is how open source projects use build servers (such as Jenkins) where all automated tests are run by scripts written in a scripting language. The build server communicates with the CI server that handles the kicking-off process via SSH with proper credentials, etc.
This is another hot topic. It’s not just for Java programmers anymore! If you’re like me, you probably use unit tests to make sure that your code works, and perhaps you even have some integration tests. But these are only two types of testing. One testing technique that I think is often neglected is the concept of writing “happy path” or “integration” tests — meaning tests that make sure your code works in combination with other components that it depends on (e.g. database).
This is especially important if you work with many external dependencies such as third-party libraries, etc. In such cases, it’s very easy to break stuff without realizing it because you’ve changed something in one place but forgotten to check if it affects anything else in another part of the system that relies on it (this applies particularly to ORMs).
For example, if a particular piece of data is loaded into memory from the database every time, then changing its structure might mean that other parts of the system will fail to load data from the database into memory too!
All this is not meant to scare you or put you off writing unit and integration tests. I’m trying to raise awareness so that people consider this idea more carefully before deciding whether or not they want/need them in their projects. It’s also worth mentioning that there are people who advocate Test-Driven Development (TDD) and don’t use any unit or integration testing at all! They prefer writing their automated functional/acceptance/smoke tests first, which then act as a form of a regression test suite for their application after each commit has been made (but before being merged into main).
But whatever your preference may be, just make sure you learn how to write good-quality unit and integration tests to help you detect bugs in your application early on before they grow out of control with lots of side effects. Those become harder and harder to fix later.
It’s no secret that many modern web applications nowadays rely heavily on frameworks such as Rails/Sinatra/Django/Flask/React/Angular/etc. Some people are happy using these frameworks without really understanding what they do under the hood.
In contrast, others feel strongly about learning how these things work correctly before jumping straight into using them blindly.
Sometimes beginners fall into what I call “framework mode” where they start feeling like everything has to be done using Rails/Django/etc. because otherwise, it would involve:
- Reinventing wheels
A lack of domain knowledge required for building a particular feature
More time required than expected
Extra rework later down the line
Less maintainable code
Extra effort due to business requirements
Of course, there are plenty of valid reasons why choosing existing frameworks might be preferred. But please remember that there are still trade-offs involved, even though those might seem insignificant at first glance! So whenever possible, try reading up about the various options available before deciding whether or not rolling your solution makes sense. Maybe spending some time learning how existing solutions work could help solve problems faster while avoiding unnecessary headaches down the road.
Debugging can be fun! It’s a great way to learn about your code, and it’s also a great way to impress friends and colleagues. Make sure that you know how to use the debugger on whatever programming language you’re using. Take some time out now to look up documentation on whatever debugger you’re using and make sure that you know at least the basics of how it works (whether it’s GUI-based or console-based).
If your language doesn’t have a debugger, then try stepping through your code by hand. Yes, I know it sounds laborious, but trust me, it’s worth doing! And after all, debugging is a crucial skill for any software engineer, so why not get in some practice now?
Also, remember that there may be other ways of getting information out of your code to help debug problems (e.g. looking at its disassembly or its stack trace). In C++/Java/C#/etc., there are also tools such as Valgrind that allow you to detect memory leaks and various other kinds of bugs. Don’t forget the multiple types of compile options that might give helpful information about what went wrong too! I’m not saying that these things will always tell you exactly what went wrong, but sometimes they’re good starting points for investigating specific problems further, so don’t forget about them either!
I hope this article has been valuable and enlightening for you. Don’t forget to take the advice that I’ve discussed here and read up on it to be sure that you know what I’m talking about.
- Date of publication:
- Thu, 04/08/2021 - 10:00
Click on the link - it will be copied to clipboard