As a developer, our job is not only limited to wring the code. There are a few more things that we must do apart from writing code.
Today, we will tell you a few points that you should not do as a developer.
1. Writing Over Optimized Code
It's always good to write optimized code, but it's also important to make sure that we don't over-optimize it. Let's say, you are working in a team and you are assigned to write a function that does something. Suppose, you come up with a solution that does that job in 2 or 3 lines, but it's over-optimized and not very easily readable.
If other team members are trying to understand this function, they will hardly understand what your code is doing and how is it working, because it's hardly readable due to being over-optimized.
Always write optimized code, but not at the cost of readability and ease of understanding.
2. Pushing untested code into production
No matter how much sure you are about your code and its working, pushing it directly to production without testing it, is a BAD decision.
You might feel like doing this when you have made a really small change and not feel like testing it.
But, there could be chances that that change might not be implemented as you wanted.
3. Pushing commented code in production
This is very dangerous. You might think what harm it might do? But, when code comes under maintenance or updations and some other dev starts working with the code, there are always chances that he might uncomment it and screw up the entire application. Also, it might create unnecessary confusion.
4. Not considering the bad scenarios
Your code will not always run in an ideal scenario or your users will not always use the app as you want them to use. So, ignoring all the basic bad scenarios is the worst thing to do. If you do that, your code will horribly fail.
As a developer, always consider, manage all the bad scenarios. Make sure your code is ready to face the worst of conditions.
Thanks for reading.
Let us know your thoughts in the comments below
Top comments (2)
Don't confuse brevity with optimization. Optimized code is all about the number of machine instructions, not how many lines of code it is. There are two-line solutions which are less optimized by an order of magnitude than a 10-line solution.
Do you mean commented out code? Good, maintainable code is commented, meaning it has comments to help explain intent. Commented out code is code that was turned into a comment to stop it from working.
Always push the former to production; never push the latter at all. (That's what VCS is for.)
P.S. There are rare exceptions, but if you're wondering whether your situation is one of them, it isn't.
More important than managing the bad scenarios, explicitly test for them.
I wouldn't say "only bad developers do", even though I agree with you they are all practices that should be avoided.
My point: level of pressure, work environment (temporary or customary) may lead even good/star programmers into some or all of these traps!