Ravi Shankar Rajan’s 5 Toxic Habits That Will Make You a Bad Developer.
You can’t change your future, but you can change your habits, and your habits will definitely change your future.
“The bonds of habit are so light that they become too heavy to be broken.” — Warren Buffett
When we feel uncomfortable because of our bad habits, we look around for solutions. We turn to books or turn to others, hoping to figure out how to get rid of it. The reality, however, is that breaking any bad habit depends solely on “the man in the mirror.” You expect to get better and do something different. Once you master the paradigm of change, getting rid of bad habits becomes easy.
Like life, programming has good habits and bad habits. Being a good programmer depends on how well you can control bad coding habits. What you do over and over affects what you do, what you believe and how you perceive the world at large. In short, forming good habits or bad habits depends on thinking.
If you don’t realize that what you’re doing is sabotaging your work, bad habits can be hard to break. You’ll still feel good about yourself, and you’ll continue to get bogged down in inefficiency and poor code quality.
As a self-taught developer, I’ve had plenty of experience with the consequences of bad habits. But now I know what mistakes I made and have learned to avoid making the same mistakes in the future. I’m still learning, and I’m changing with each passing day.
Here are some harmful habits that can make you a bad developer.
No planned coding
“I have always found that planning is useless, but planning is essential.” — General Eisenhower
Unfortunately, many developers (myself included) often think, “I can do this easily,” and end up with poor results. We started work without really thinking about it, and by the end of the project deadline, we had a bunch of unfinished requirements, and the code was a mess.
Taking the time to analyze requirements prior to coding, breaking them down into manageable modules, brainstorming with colleagues and business analysts, and coming up with an incremental plan from there can help us create high-quality code. Use a pen and paper, or a whiteboard, or even talk to a yellow duck, and come up with a trackable, organized plan.
Remember, you can’t plan everything. The first plan to solve the problem may be completely wrong, but that’s okay. It’s important that when you finish your first draft, you have a clear idea of where the gaps are and what needs to be done to fill them. Plans are important, but they can change by accident.
Be wary of code reviews
“The problem with most of us is that we would rather be destroyed by praise than rescued by criticism.” “– Norman Peale
Criticism may be unacceptable, but it is necessary. Like physical pain, it can draw attention to an unhealthy state. You may think you’re the best developer in the world, but your code doesn’t perform as well. The sooner you realize this fact, the sooner you will become a good programmer.
You need to be humble about any errors or bugs you detect during code reviews and make sure they don’t happen again. Bad developers who do nothing about it end up hurting people.
Good developers are willing to put their code out there for discussion and keep improving. They are not blinded by their own brilliant solutions, are willing to accept their own ignorance and are constantly learning new things.
Act like you know everything
Not knowing everything is sometimes a good thing — Neil Gaiman
There are many reasons why bad developers can’t admit their ignorance. Fear of ridicule, ego enlargement, fear of condemnation, etc. But whatever the reason, they end up losers in terms of knowledge acquisition and reputation. Stephen J. Dubner and Steven D. Levitt, authors of the behavioral economics bestseller “Fanaticism,” argue that the three hardest words to say are not “I love you, “but “I don’t know.”
Remember, it’s perfectly okay to say “I don’t know”. This is much better than covering up your lack of certain knowledge/skills. The key here is to know how to solve the problem — either by asking others or doing further research.
Instead of clinging to utopian dreams of knowing everything, it is better to see the world as the foundation for learning. You should always be open to new, different or changing ideas and adapt your problem-solving skills to the changing situation.
Measure progress in lines of code
“Measuring programming progress by lines of code is like measuring aircraft manufacturing progress by weight.” — Bill Gates
“I can write 10,000 lines of code in an overnight session.”
“Did you see the project? That’s all mine. I wrote 30,000 lines of code.”
“I have my own coding style. No matter what other people do, I code it my way.”
Sound familiar? This is called the programmer self. Doing things your own way and rewriting existing code may satisfy your ego, but it certainly doesn’t satisfy the needs of the project.
As a developer, your job should be to write as little code as possible to meet requirements. When given a new functional requirement, the first question you should ask yourself is: “Has anyone done it? Can I reuse it?” There is no shame in borrowing off-the-shelf solutions, as the creation of any software is usually a team effort. Always want the team to be solid, not just a patchwork of individuals.
Save yourself some trouble. Don’t repeat yourself. Do not repeat the same or nearly the same code in your program. Instead, you put your code into a class or function that can handle multiple situations. If someone has done it for you, use it shamelessly.
Pass the buck
Good people are introspective. People with low self-esteem blame others — Don Shula
Software development is a team sport. Agreed
Software development is about teamwork. Agreed
Therefore, I am not responsible for my code. Not OK
It’s no secret that there’s some arrogance and arrogance among developers. So it takes a lot of humility and selflessness to admit that you made a mistake and confirm that the production problem was caused by the code you wrote. It’s easy to blame others for problems. But it’s much more efficient to look at past code and figure out what caused the error.
Everyone values developers who take responsibility for their code and make sure they don’t make the same mistakes in the future. Software can’t always be perfect. Flaws will always exist. The key is to control defects and strive for excellence.
From now on, you should strive to make your code and others’ code as readable as possible. Remember, if you don’t open up and admit your mistakes, you’re not actually growing.
As Walt Whitman put it:
Be curious, not judgmental.
The original link
More good articles, please pay attention to the public number of knowledge small set (ID: zsxjtip)