Many of us started programming out of curiosity or by joining a Bachelor's degree program where we picked up this stuff. When we start learning coding our only aim is to become the best coder in this world. So we put all our efforts to code as much as we can. But often when we land our jobs this whole regime is a different game altogether. There are a lot of aspects which makes our code great and actually a great contribution to our organization.Below are some 6 points I wish someone had me introduced earlier in my career
1) Scaling
While writing your code have you ever wondered how your code would react if it interacts with a million or a billion users? Will it cause any side effects? Will it run out of memory or CPU? will it be abusing network I/O operations? will it be efficiently writing on the Disk? Well all these factors can make or break a product. Today in the world of web apps, most of the enterprises deploy their code on the cloud these days. Cloud is nothing but a bunch of computers which you use to run your code. These resources generally go by hourly prices which range from a few cents to a couple of dollars. So we are talking about actual money here and if your code is not efficient enough then it will need extra resources which means increase in billing.
Scaling should be number one on your list while coding. because it seems pretty easy to handle a few requests while in the development phase. but things turn south when you reach production. I'm not implying that your code should be able to handle 1 billion users even on a small server/system. whereas it should be taken with a pinch of salt that whatever server/instance is given to you, you should be able to efficiently use it to its core.
2) Security
I bet security is least of your concerns or most of the time at the back of your head. To be honest it is somewhat the industry's fault that we talk so less about it. I have been working in the software industry for more than 5 years now and to be honest, now I have started to give attention to the security part of it.
So let's take an example here, you wrote an API to insert some data in your MySQL database which was requested by a client. You process the request, boom! your entire database is corrupt now.
How did this happen in the first place? your code is pretty much the same nothing changed in it, it was a very specific operation but then it led to the corruption of the whole database. The answer here is an SQL injection attack. A malicious SQL script was submitted in the form to your API, it wasn't verified or sanitized and that script got executed by your API.
This is one of the examples which I gave. If you read the OWASP Top 10 vulnerabilities you will get to know more about such attacks and these happen on a daily basis.
I don't want you to become a security expert to just write a piece of code that is safe. But to be aware of such vulnerabilities and what you can do with your technology to avoid them, should be your goal. Because only prevention is better than cure and preventing huge law suits. ;-)
3) Clean code
Let me be honest, I have personal feelings for this particular point.
I have a story to share…
During my graduation, we used to have external invigilators who would assess students during vivas. In one of the assessments I got a program to write, we were supposed to write our programs on paper(Yeah! who does that). The invigilator pointed out on my code where I had given a gibberish to one of my variables. He asked me what the name of that variable meant? I said it means nothing and I have used random names because it's my variable and I can give any name to my variables because I only need to understand this code. It quickly became a heated discussion, eventually the invigilator granted me with good grades. I was very proud that day because I won a battle.
Now I know how foolish I was that day and showed a pure characteristic of a newbie. Why? because when you work in the industry it is not always that you will be working on a fresh piece of code. Most of the time you will be working on someone else's code. It might be a person who has moved to a different team or has left the organization. Let's say you are working on one such code and you don't understand it. You might be able to ask the person who wrote the code in the former case and clarify the issue. But what happens in the later scenario, the guy is not available and you are stuck and have no choice other than to debug every step of that code. It is madness isn't it?
In one of the talks google shared a statistics that we read the code 80% of the time and write only 20% of the time. This is a huge proportion. Now you must understand its gravity, writing clean well defined code which is easier to read and can convey what it's intended to do.
Always keep in mind most of these programs are going to stay as long as a decade and somebody needs to maintain this. Always write code as if you are going to maintain it for the next 10 years or someone after you can even read it and make sense out of it. so it is less of a battle for them.
4) Testing
Yes this is one of your responsibilities too (don't tell me you didn't sign up for this).
Hear my part and then decide if it makes sense or not.
When you are working on a project/module/product you are constantly evolving the face of it. Let's say you had a module where you have a form and the purpose of that form is to submit user details to an API. Now you need to include a new field called "Username". You worked on that module, you have perfectly added a new field and its running also perfectly. After this you refactored your code for some easy readability and pushed it to production. This code got deployed on production servers and now the users are reporting that the form is not working for them. You start scratching your head how come this is not working - "It was working on my machine" yeah the age old constant statement. After debugging you get to know that during refactoring your code you created a typo mistake. As you were too confident of your code you pushed it without retesting it and led to this whole fiasco. Yeah I know you want to write more code, testing is ultimately not your job to do, because it's boring for you. But then these silly mistakes can cause a lot of problems and can hamper your reputation too.
How can you avoid this? start writing unit test cases, integration test cases. Yes you can write these things. The good part is you write it once(ok a few more times) but it eases out your testing part. Now like in the above case let's say you earlier wrote a unit test to test the functionality of that form. now when you make changes all you need to do is to run the unit test case if it passes then you can be sure that the base functionality still functions. If it breaks then you know it before even hitting the production servers. isn't it cool to know such issues beforehand. Automating this increases your efficiency by avoiding manual testing which is prone to human errors. And automation tests such as these run pretty fast and if integrated with a CI/CD tool reduces the effort.
5) Considering space and time complexities.
Most of us have learned that Big O is the best time complexity but have we ever considered applying it in real life scenarios? This is something which you can relate to the first point of this article. Because these notations depend on the input size, so it definitely affects scalability.
Let's say we have a single for loop if we execute on N inputs its time complexity is O(n) which is the best case scenario. But if we have a nested for loop then its time complexity will be O(n^2) .
If to process one input in a for loop takes 2 seconds and we have 10000 inputs then the total execution time would be 20000 seconds. whereas in a nested for loop for the same scenario it would 10000*10000*2= 200000000 seconds.
So this definitely shows the difference that can make while writing your code. So always try to consider the complexity of your program and you will reap its benefits.
6) Thinking before writing.
This I have learned from one of my mentors, because of constant bashing but it has definitely served me well. What a lot of us do is that as soon as a problem statement comes to us we start thinking on how to implement it. And whatever the first solution that comes to our mind we write it down. The code goes for testing and boom! The tester has created a lot of tickets for us, next thing you know your manager gets to know about these tickets and starts bashing you. Why? because you didn't think of all the possible cases/scenarios. Software development is all about covering the scenarios that may occur during its execution.
Let's take a very basic example of a calculator. try diving any number by zero and the calculator will tell you that it can't divide it by zero. Now if the calculator would have not handled it well enough would you be still trusting and using the same calculator? The answer should be 'No'. The same goes with any problem solving skill. Whenever a problem statement is presented to you, spend at least 60% of the time thinking what are the possible ways by which you can solve that problem. If you spend enough time you will always find that there are more than one ways to solve that problem. And once you have ruled out all the possible scenarios then that solution would be least prone to errors and bugs. It would probably use less number of LOC, would be easy to maintain and easy to read too.
So always make sure that you don't jump in excitement to solve a problem rather take ample time to think about it. Because the more you think about the solution the less time it will take you to write it down.
A little about me…
I have been working in the software industry since 2015 and I have been a full stack developer since my early days. After doing a lot of mistakes(I mean a lot) now I'm proficient with Angular, .Net Core, RDBMS and NoSQL, NodeJS. Currently transitioning towards DevOps practices. I have hands on experience with Azure, AWS and Alibaba Cloud.
If you have more to discuss then please comment below or we can discuss this over my Instagram handle: i_m_vibh or my Twitter handle: VibhanshuBiswas
Top comments (1)
Please also consider my all time favorite the YAGNI principle and the problem of premature optimization :-p
But you're absolutely right about your points. İt's essential to learn to have these in the back of your head.