10 Counterproductive Tips That Make You a Terrible Developer (And How to Avoid Them)
A satirical list of ten misguided developer habits—from obsessively mastering JavaScript to ignoring communication—highlights how these anti‑patterns sabotage code quality, teamwork, and career growth, offering a cautionary guide for anyone aiming to become a better programmer.
Yesterday on dev.to I saw an interesting article where a foreign developer shared ten tongue‑in‑cheek suggestions on how to become the worst programmer, offering a stark contrast to typical advice on becoming a good developer.
Top 10: Before doing anything, you need 100% understanding of JavaScript
This is a solid suggestion that can be applied anywhere; unless you are the top expert in a field, you shouldn’t act without thorough knowledge, otherwise you risk messing up and being ridiculed.
Starting too early can lead to mistakes, and remember: as a developer, your job is to never make errors.
Top 9: Never question thought leaders; they are always right and smarter than you
Thought leaders should be revered as gods; whatever they say is gospel, even if they started coding weeks ago while you have years of experience. If they have many followers, they must be more knowledgeable, so you should listen carefully.
Remember: one follower equals ten billion brain cells. Do you have trillions?
Top 8: If you don’t understand something, blame the language creator and its fundamental flaws; create your own language to fix it
We have many bugs because we lack enough programming languages. Brendan Eich created JavaScript in ten days; with thirty days you could probably devise something better.
Top 7: When someone offers an alternative solution, just say “but… ” and throw out a buzzword like “security”, “scalability”, “orthogonality”, or “maintainability” and walk away
No one will truly understand your code or why you wrote it. Don’t expect helpful feedback; 110% of the time they don’t know what they’re talking about. If they’re that smart, they should be writing code, not you.
Top 6: Don’t learn HTML; it’s outdated
Just because modern web frameworks still use HTML doesn’t mean you should. Instead, focus on building a new markup language and ecosystem (browsers, mobile, APIs, etc.).
When HTML comes up, remind everyone it’s not a “real” programming language, same for CSS. Link these discussions in your résumé so recruiters know you’re a “real programmer”.
Top 5: You don’t need to care about communication—humans are irrelevant, computers are what matter
One of the biggest mistakes developers make is wasting time on communication instead of coding. You’re hired as a developer, not a talker. The more lines of code you write, the higher your salary.
Ignore emails, Slack messages, and GitHub issues. Instead, work in a silo, cranking out cool features. When forced into a meeting, cancel at the last minute with a vague excuse.
Top 4: Make things as complex as possible; it’s the key to keeping your job
Find a comfortable spot, control it completely, and be meticulous. Get creative with functions, variables, and filenames—reverse‑spell words, use TV character names, or prefix variables with family names. Consider running your code through jsFuck.
If you’re the only one who can fix or update the codebase, that’s the ultimate job security.
Top 3: Copy‑paste everything without worrying about understanding it
The internet is full of resources like Stack Overflow and Google; answers are everywhere. Many developers waste time trying to understand useful things. If you succeed, move on without spending time thinking about it.
Spending a lot of time understanding what you’re doing prevents you from achieving the ultimate goal: writing as much code as possible.
Top 2: Your opinion is the only one you need to listen to
This ties back to Top 5: the more people involved, the more nonsense you hear. If forced to listen to a manager or teammate, imagine the Beastie Boys’ “Intergalactic” video playing in your head so nothing they say sticks.
Top 1: Rewrite every instance of let in a colleague’s code as soon as possible; they’ll thank you later
This is self‑evident and crucial for application stability, taking priority over releasing new features.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
