Over the years I have written quite a lot of code. These are the tips that I wish I had known when I had started out and would have saved me a lot of head scratching and restless nights:
Create a “to do” list
Always write down your tasks and keep it updated as you work through the problem. Your memory is limited and you can often forget something which may be critical later. There is nothing worse than spotting a potential Production breaking bug and then forgetting about it. Your memory will definitely be jogged when its been released into Production and is causing major problems.
Always use variables and don’t hardcode
Generally this will make your life easier and it makes the application more flexible. Your future self will always be thankful that you took that little extra time to resolve the problem properly rather than create something which breaks regularly. It is more likely when your future self comes across the same problem they can easily re-use that code and go back to wasting their time on their phone.
Code comments are your friend
Many times I returned to code I have written and never known what a function or piece of code is expected to do. Some people may enjoy looking in disbelief that they may have ever had anything to do with a piece of code and deciphering whatever code you managed to smash together once at 3AM a long time time ago but I definitely am no one of those adrenaline junkies. If I had taken some time out to put some comments into the code it would have saved me hours troubleshooting issues and probably would have helped the poor soul who got to look after the code after I had left.
Always break a big problem down
Sometimes a big problem can feel daunting and be more difficult than it seems. Break the problem down into smaller blocks and then solve each block one at a time. It’s okay to skip a block and return to a previous block as it may give you clues to fixing the skipped block. In all honesty whilst coding the parts you can do a piece of divine inspiration will enable you to problem you couldn’t solve or you will enough code to show one of your more capable colleagues that you had tried to fix the issue and now this rubbish was there problem to fix.
Errors are not a bad thing
This will help you to solve the error more easily and doesn’t mean you’re a bad programmer. Only be worried when something goes wrong and you don’t get an error message.
Never reinvent the wheel
It is more than likely someone has faced the same problem as you and it is okay to copy their solution. Stack Overflow and Google are your friend and code found on the internet can greatly decrease the time to complete any task. It would be foolish to run it straight into Production but feel free to trash your non Production Environments.
A difficult problem doesn’t mean you’re a failure
There will be times when you face a problem which you find hard to grasp. It is perfectly acceptable to find things difficult and it will happen over and over again during your career. Trust me when I say that difficult problems do not strengthen your character but just help you to improve your Googling skills.
Know who to contact in your organisation
When you have very little information and need more details it is infinitely better when you have a list of go to people for all the applications you will be supporting. Most of the time this list will help you fix a problem promptly with very little stress. Sometimes this list will turn into a future hit list of people who should have been able to help you in your hour of need but were unable to or simply chose not to.
99% of your work will never be seen by anyone
Your solution may not necessarily be the most elegant one but try to keep it simple. When you manage to super optimise that code and it runs in seconds rather than hours nobody will truly care and they will only ask if it works or not.
Prototypes do not have to end up in production
Building things allows us to learn from coding. What you learnt is better than whether it ends up in production. Sometimes it is better to start again than fix problems with some poorly written code. I mean if you see the utter trash that gets promoted into Production it is staggering how bad the stuff which the QA process rejected must have been.
Read code of more experienced programmers
When you get passed some code don’t just deploy it. Read it and review it. You might learn something or you might pick up a problem which will save everyone time. Equally you will learn that the other coder is just as bad as you or probably even worse.
Don’t stop learning
Programming can change quite rapidly. If you don’t invest in learning new things you might end up encountering it for the first time when you are debugging something in Production. Nobody will care that you requested training in that Application and can’t fix it quickly but will instead say “we know you work 50 hours a week when your contracted to do 35 but you should still reduce your life outside of work time to train yourself up so we don’t have to.”
Originally published at https://parvtheitgeek.com on March 23, 2020.
Parv The IT Geek 