DEV Community

loading...
Cover image for Things only bad developers do

Things only bad developers do

theninjaprogrammer profile image The Ninja Programmer ・2 min read

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

Discussion (2)

pic
Editor guide
Collapse
codemouse92 profile image
Jason C. McDonald

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.

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.

Pushing commented code in production

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.

As a developer, always consider, manage all the bad scenarios. Make sure your code is ready to face the worst of conditions.

More important than managing the bad scenarios, explicitly test for them.

Collapse
tmpalma profile image
Thiago Palma

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!