10 simple habits to help you boost your programming skills and career as Software Developer (Part 1)
With the technology growth, we have to apply more effort into keeping up with the newest frameworks and tools, however, there are simple things that developers keep ignoring which could be holding their career back to the next level. Whilst this is an article to help you enhance your programming skills, it won’t cover coding best practices or any other approach to make your code better. It is the part 1 list of 10 things to help you excel amongst other developers in very simple ways.
Automate as much as possible
There is a lot going on regarding CI/CD or DevOps and they all sound like a crazy world you may not be ready to explore yet. However you can still save some development time by automating small-frequent-executed activities, such as:
- Scripts that you run every day which could be scheduled.
- Routinely commands. Instead of 4 commands to start the app, wrap them in only 1 script/command, ex: “npm run prepareSeedBuildStart” or just “npm start” or “prepareSeedBuildStart.sh”.
- Instead of querying data monthly, create a script to do it.
On top of that, there are several tools which allow integration with others, helping the status and updates to be shared across the team automatically. Instead of writing to your group on slack the status of a deployment, you could just add it in your deployment script. Time is money.
Test your own feature
This may sound obvious, but it is also a very common mistake. If you have been required to create a new CRUD, make sure you not only test the happy path but also invalid ones. This includes trying to save without data, reading data the requester doesn’t own, updating without a compulsory field, etc. Yet, if you are thinking that this should be the job of a tester or someone else, I just want you to ask yourself:
- If a bug is caught, who is going to be held responsible for it?
- When there is a bug in the feature you built, who is very likely to fix it?
- Is it better you finding a bug and fixing it or allowing someone else to do so?
- How is that going to reflect in your programming skills?
I guess I don’t have to give the answers for these questions, but I hope they will make you understand the value of the development test. In regards to the extra development time, if this is a concern, let’s consider you will spend an extra 15% of your time to test the feature. There are two things we can get from that: 1. The time of someone else finding the bug, reporting it and putting it back to be resolved and 2. The time you will spend going back to the feature and fixing the bug. They are both higher than the time of the initial suggested approach.
Always do what you promised.
Do you know that file someone asked you for and you said you would send in a couple of minutes? What about the quick task/favour you have been verbally asked for? Also the message you said you would reply with the best time to meet? I am not here to discuss whether these requests should arrive via a ticket because we know there will be always some which will not, but to reinforce that you should do what you promised.
Since we are always too busy (or just disorganised) doing other things, these tasks are very easy ignored, however, there is still an expectation of them to be accomplished. When you receive these types of requests write them down (maybe a post it) in a very visible place or add them to you reminder or TODO list. Once you have finished the task, kindly message informing that the job has been done. This attitude not only shows responsibility, but also your respect to your colleagues.
Never say “it worked on my computer”
Even though I would completely understand if someone tells me that, the answer is still not enough. It comes back to the ownership of your code and the fact that this statement implies you are trying to find something (or someone) else to blame. The best solution for this problem would be a CI, which will use a dedicated container to build and test the application. However, If you don’t have it in your team, there are two things you ought to do:
- Ask for a CI process. Relentlessly.
- Make sure you test you application not only locally, but also after the deployment in the staging/test environment. You could also, test it pointing to the testing/staging database.
Regarding the problems, they commonly are: 1. Dependencies or plugins you installed locally but forgot to add to the project (npm devs will identify), 2. New config data you added in your local DB but forgot to add to the deployment script, 3. Your local version of tools and plugins are not the same as in the other environment, 4. Cache has not been invalidated (both for Front End on browsers and Back End). Nevertheless, have a proactive approach since it is better to say “My feature is not working in the staging environment, but I don’t know why” than “It worked on my computer”.
Keep constantly learning
I was ambivalent about adding this topic as it is too obvious, but then I realised how many people don’t do this. If your excuse for not learning more is about lack of time or motivation, I have just one thing to say: “Don’t learn for the business you work for, learn for yourself”. Learning does not have to necessary be related to your day-to-day tasks, but to things that can help you be a better professional.
It goes without saying that it will be great if you are pursuing knowledge in your professional field, but it is also safe to say that: It is better to know someone has been studying music (in a sense it may not be related to work) than someone who is not learning anything at all. People can take everything from you, except your knowledge.
To sum up
As developers it is easy to be too focused on coding and practices, but the reality is that many things which defines a good programmer are not directly related to code. This article is to list the first 5 simple things, which will boost your skills and career. And you can start doing them right now.