Fundamentals 9 min read

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.

Programmer DD
Programmer DD
Programmer DD
10 Counterproductive Tips That Make You a Terrible Developer (And How to Avoid Them)

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaScriptprogramming humorbad practicescoding anti-patterns
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.