Being a developer is hard. Not only we have to know technical skills, but we also have lots of soft skills that we have to get good at.
In this article, we’ll look at some ways that we can all lower the risks for us when working as developers.
Clear Technical Debt
Technical debts are bad solutions that are added to speed up the development process.
Therefore, when we have time, we should clear the out by cleaning up our code.
Clean up anything with bad names, spaghetti code, multiple levels of nesting, and anything else that are hard to read and maintain.
Working with them is a pain and they’re fragile, so working with them is riskier and harder.
Ship Code Often
Delivering things in small pieces makes delivery less risky. Also, it feels good to have small wins that we can achieve in a short time rather than writing a lot of code that no customer sees for a long time.
Big bugs and breaking changes are also less likely with small changes, which makes them even better,
It’s also good for getting feedback early on so we can improve according to feedback.
Commit Early and Often
When we got something to work, we should commit them right away. This way, we won’t be at risk of losing them or ruining them with bad changes in the future.
Once they’re committed, then we can revert to them and we know they’ll be the last good changes.
It also reduces the chance of reverting the hard work that we’ve done.
Asking for Help
Asking for help helps all of us move faster since getting stuck on a problem for a long time means no progress.
Therefore, if we’re stuck, then ask for help.
Get Feedback on Unfinished Work
Getting feedback on unfinished work can steer us in the right direction before the work is done.
This way, we don’t have to throw out as much work since we’ve been steered in the right direction from the feedback that we obtained.
Try Things
If we don’t try different things, then we may not know that there’s a solution that we can use.
There are no risks so we should try it.
Read Documentation
We can learn how to use a lot of things with documentation, so we should read them before trying anything to avoid going down the wrong path and waste our time using anything improperly.
Don’t Overlook the Details
Details are important. If we screw up the details or miss them, then we may screw up some of our work.
So we shouldn’t ignore them.
Don’t Start for Scale
Build with scalability in the future in mind, but we shouldn’t overengineer our product by building it for scale when we don’t need it yet.
We just waste our time with overengineering and it doesn’t do us any good right now other than wasting our time.
However, we should make scaling easy to do by making our code prepared for scaling.
Think About Performance Implications
Performance is important since no one wants to wait for something to load. Worse yet, our code may run so long that it times out.
We should think about performance so that we get adequate performance in our apps so no one will be frustrated when using our app.
If our solution takes a great performance hit, then we should think again before doing anything.
Apply For Jobs We Are Qualified For
Ideally, we should at least know some of the stuff on the job description before applying. Never lie in our resume about our qualifications.
It’s easy to find out in interviews and even if we get in, we probably can’t do the work that we ask for. And we can’t do anything, we probably won’t last long.
So we probably should make sure at least we know some of the stuff listed before applying.
Modularize Our Code
We should divide our code into small modules so that we can all read, maintain, and test them more easily.
Long files are hard to read and unmaintainable.
Conclusion
We should divide our code into small pieces and don’t overengineer our code. Deliveries should also be small.
Cleaning technical debt and committing code often also reduce risks of making changes in the future.
If we’re applying to jobs, at least we should know some of the things in there. Otherwise, even if we get hired, we won’t last long.
