1. Emotional Thinking
If you start viewing the world through emotional lenses, you might become a bad programmer. Emotional thinking or attitudes can easily turn you into a monster. You’ve probably heard many terrible programmers say things like:
- "My program can’t possibly have this kind of problem."
- "Java is crap."
- "I hate using UML for design."
- "The requirements keep changing, what can I do?"
- "I can’t stand these people, do they even understand anything?"
These emotionally charged thoughts and attitudes not only make you a terrible programmer but could also harm your career. Emotional thinking is usually a devil that leads to bad judgments and decisions, and these wrong decisions directly influence your future.
2. Doubting Others
Bad programmers often say things like, “My code is definitely correct, I suspect the compiler has a bug,” or “This should be fine, why is STL so hard to use?” I once saw a programmer use the STL class like this: map, and when he couldn’t retrieve the string he inserted, he blamed the STL library, thinking it was a bug, and proceeded to write his own map! Oh my god! Sometimes, jumping to conclusions too early is a very bad habit. Every issue has a reason, and only by understanding the reason can you figure out who is at fault. Generally speaking, the problem is usually your own.
3. Focusing Too Much on Implementation, Getting Lost in Details
Sometimes, when faced with a problem or a requirement, bad programmers rush to find a solution or implement it immediately. This is a very bad habit. Design patterns tell us, “Prefer interfaces over implementation,” meaning that understanding the nature and characteristics of the problem is more important than worrying about how to implement it.
For a client’s problem, the first priority should be to help the user resume normal operations and fix the bleeding system, not to analyze the problem and find a solution while neglecting the user.
When solving a bug, the first thing is to reproduce the bug and understand the original intent of the program, not to immediately start fixing the code, as that will only introduce more bugs.
For a requirement, it’s important to understand the business background, use cases, and real intent behind it, rather than focusing on implementation. Only when you understand the user’s true intent, usage patterns, and cases can you truly design a solution.
Bad programmers tend to get stuck in details, debating implementation and the root cause of the problem, while neglecting more important things. Only by seeing the entire map can we understand where to go next.
4. Using Code They Aren’t Familiar With
The best friends of bad programmers are Ctrl-C and Ctrl-V. Sometimes, they use code without understanding its exact meaning. Evidence shows that bugs caused by copy-pasting code account for a large majority of issues. Code can only work in a specific environment, and changing the context might result in unexpected behaviors that the programmer doesn’t know about. If you can’t even control the code, how can you write good programs?
5. Working Hard Instead of Working Smart
Bad programmers are often seen working tirelessly to fix their bugs, spending a lot of time repeating the same tasks. A good programmer might spend twice as much time setting up an effective development environment, tools, and using those tools to avoid errors during development. Good programmers always use tools and techniques to make their work more efficient, aiming to minimize mistakes during development. The cost of fixing errors later is huge, and the pressure to correct them is immense. Bad programmers often fall into a vicious cycle: they appear exhausted and overworked, leaving them with no time to improve. The more they don’t improve, the more problems arise. So, working hard sometimes might indicate that you’re not a good programmer.
6. Always Waiting, Making Excuses, and Complaining
When requirements are unclear or the environment is unsatisfactory, they’re always waiting for someone else to fix things. When problems arise, they find excuses or complain about how bad things are, saying, “This is wrong, that’s wrong,” so of course, they didn’t do a good job. Bad programmers always want the environment to be perfect: clear requirements, great development tools, enough time, good QA, strong team leadership, a thoughtful manager, enough training, good discussions, and strong support from others. This is a “wait to be served” attitude. The world is never perfect, and a team needs everyone to contribute. If everything were perfect, where would your value lie? Driving instead of waiting, leading instead of following.
7. Fostering Office Politics
There’s a saying, “Ugly women cause trouble,” meaning that when someone lacks real ability, they will make trouble in other areas. Bad programmers are the same. When they can’t write good code or outperform others, they often resort to blaming others, shifting responsibility, or trying to push out more capable colleagues to save themselves. As a result, bad programmers often bring office politics into the workplace.
8. Talking More, Doing Less
Bad programmers often think they know everything. They don’t realize that their understanding and knowledge are limited. This is what’s called “bragging.” Yes, when a programmer can’t do their job well, they rely on talking and bragging to get by. Another manifestation of this behavior is when they criticize others’ code or designs, always pointing out problems but writing terrible code themselves. They always complain and criticize without offering any constructive feedback or proposing viable solutions. These bad programmers love to criticize others’ work to show off their own supposed excellence.
9. Stubbornness
When you provide a lot of evidence showing that there’s a better solution or direction, they stubbornly believe that their own method is the best. I once witnessed a new programmer heading in the wrong direction while solving a problem. I pointed it out and showed him a simpler way, but he insisted on sticking to his method, saying, “This is my method, and I must go down this path or I’ll feel bad.” Eventually, three days later, during the code review, after stubbornly defending his method amidst much skepticism, he had to adopt the approach I had suggested.
These programmers never think to ask others for better solutions, instead, they doggedly stick to their own ideas, even if it leads to a dead end. They will keep going forward without looking back, even if they hit a wall.
10. Writing "Clever" Code
Bad programmers often write code that requires colleagues to refer to programming language manuals to understand, or their code looks stylish but is very difficult to read. Code should be simple and readable, but they like to show off their skills by trying out unconventional techniques or writing overly clever code. Yes, only programmers who lack real ability need to rely on such displays.
I remember one time when a programmer with excellent English joined the company. For those of us with less-than-perfect English, we preferred simple and readable documentation. But this guy, trying to show off his English skills, used a lot of rare words and GRE-level phrases, making it very hard for everyone to read. Ironically, one of the native English speakers later had to ask him the meaning of a word in his email. Haha.
Visit the https://payhip.com/OracleeBookSoftwareShop website to get an e-book about Oracle internal storage.
Top comments (0)