12 Coding tips for my younger self — Parv The IT Geek

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

Photo by David Ballew on Unsplash

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

Photo by Pankaj Patel on Unsplash

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

Photo by Luca Bravo on Unsplash

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

Photo by Hans-Peter Gauster on Unsplash

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

Photo by Sarah Kilian on Unsplash

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

Photo by Jon Cartagena on Unsplash

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

Photo by Estée Janssens on Unsplash

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

Photo by Markus Winkler on Unsplash

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

Photo by Viktor Talashuk on Unsplash

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

Photo by Nicolas Thomas on Unsplash

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

Photo by Roozbeh Eslami on Unsplash

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

Photo by Road Trip with Raj on Unsplash

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.


Published by Parvinder Nijjar

I blog at ParvTheITGeek.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: