DEV Community

Cover image for Top 10 Pieces of Advice for Becoming the Worst Developer Possible
Nader Dabit
Nader Dabit

Posted on

Top 10 Pieces of Advice for Becoming the Worst Developer Possible

Cover image by Dan Meyers

A lot of times I see posts with people suggesting their tips on things like career advice, interview tips, or how to be a good programmer aimed at developers.

I think putting a different spin on this can also be eye opening, revealing the things you should stay away from or try to focus on the inverse of.

To get more insight on this point, I sent out a tweet a few weeks ago asking developers this simple question:

What advice would you give to someone just getting into programming to help them become the worst developer possible?

In this post, I'll outline my 10 favorite answers, along with my own personal tips and tricks.

10. You need to know 100% of javascript before doing anything else at all.

This is such great advice, and can be applied all over the place. You should not do anything until you are the #1 expert that you know of, if not in your country at least in your immediate circle. How else are you to be sure you don't fuck anything up? How else will you be sure you won't be ridiculed?

If you start too early, you may make a mistake, and remember: As a developer, your job is to never make a mistake.

9. Never question the thought-leaders; they are always right and smarter than you.

Thought leaders should be looked up to as Gods. What they say goes. Even if they just started coding a few weeks ago and you have been coding for a few years: if they have a large following on social media, they are more knowledgable than you and you should listen to exactly what they say.

Remember: 1 follower === 1 billion brain cells. Do you have trillions of brain cells? I didn't think so.

8. If you don't understand something, it's the fault of the language creator and a fundamental flaw in the language. You should write your own language to fix this.

The reason we have so many bugs is because there simply are not enough programming languages. Brendan Eich created JavaScript in 10 days. Surely you can come up with something better if you spend, maybe 30 days or so. What's stopping you?

7. If someone proposes an alternate solution to yours then just say "but what about..." followed by any of these words and then just walk away: "security", "scalability", "orthogonality", "maintainability"

No one will truly understand your code and why it was written other than yourself. Don't expect anyone to give any feedback that could be helpful, 110% of the time they don't know what they are talking about. If they were so smart, they would be writing the code anyway not you.

6. Don't learn HTML, it's old and out of date.

Just because every modern web framework still uses HTML doesn't mean you should too. Instead, you should focus on building a new markup language and ecosystem around it (browsers, mobile devices, APIs, etc..).

Also be sure to jump into any conversation that is discussing HTML to remind everyone that HTML is indeed not a "real" programming language. Same goes for CSS. Leave links to these conversations on your resume so your hiring manager knows you're a "real programmer".

5. You don't need to care at all about how you communicate with people - humans don't matter, only computers!

One of the biggest mistakes I see developers making is wasting time communicating instead of writing code. You were hired as a Developer, not a Conversationer. The more lines of code you write, the larger your paycheck.

Ignore emails, Slack messages, and GitHub issues. Instead, work in a silo and bang out as many cool features as you can. When someone forces you into a meeting, cancel at the last minute with an extremely vague excuse.

4. Try to make things as complicated as possible. That's the key to staying employed.

This one is especially important once you find a place that you feel comfortable. Do everything you can to have full control over the repo with no oversight. Try to be as creative as possible with your function, variable, and file names. Use conventions like spelling words backwards, using your favorite TV show's character names, or family names as prefixes to variables randomly. Also consider running your code through jsFuck.

If you are the only one who can fix or update a codebase, this is the ultimate form of job security.

3. Copy and paste everything from the internet. Don't worry about understanding any of it.

The goal is to ship code. With numerous resources like Stack Overflow and Google, you have almost all of the answers right in front of your face. The problem here is that many developers waste time trying to understand something that works. If it works, move on and don't spend any time thinking about it.

Spending a lot of time understanding what you are doing will prevent you from accomplishing your end goal: Writing as many lines of code as possible.

2. Your opinion is the only one you need to listen to.

This goes back to rule #5 - The more people that get involved, the more you have to hear shit from other people. If you are forced to listen to the opinion of your manager or other devs on your team, join the call but when they are talking try to visualize the Intergalactic video from Beastie Boys playing in your head during the conversation to be sure nothing they say enters your brain.

1. You must rewrite every instance of let in your colleague's code to be const wherever possible. They may hate you now, but they'll thank you later. It is critical to the stability of your application and should be prioritized over shipping new features

This one is the most important of all (and is self-explanatory).

Top comments (37)

Collapse
 
codemouse92 profile image
Jason C. McDonald

"If you can understand your own code, you're not trying."

Collapse
 
dabit3 profile image
Nader Dabit

😂😂😭

Collapse
 
mtee profile image
Margaret W.N

😂😂 I'm inspired!

Collapse
 
ashishk1331 profile image
Ashish Khare😎

😎

Collapse
 
iagommendes profile image
Iago Mendes

🤪🤪

Collapse
 
_garybell profile image
Gary Bell

It's missing the bonus "Never test anything - that's what production is for. You can never hope to recreate real-world use, so why try?"

Collapse
 
gilb03 profile image
Gil B.

LMAO

Collapse
 
agiesey profile image
AGiesey

Re. number 9: When I got to my second job I realized the fallacy of this. There were 3 "thought leaders" who I considered (would still consider...) mentors. But when THEY disagreed about things it dawned on me that not any one of them had the RIGHT answer. Before that I always thought there was this mystical "right" way to do things. After I had this experience I started to do my own things but to pay attention to each little decision I had to make, what my choice was and most importantly WHY I did it that way.

Collapse
 
jhilgeman profile image
Jonathan H

Sometimes there is a mystical right way to do things, especially when it comes to security. For example, it's usually a Bad Thing to "roll your own" when it comes to crypto. I've also seen rookie developers who think that the veterans are simply wrong but they just make that assumption instead of asking questions. It's not always that way - I'm just saying there are times when it can be good to follow thought leaders.

Collapse
 
agiesey profile image
AGiesey

Thanks for adding, I agree with your points. After re-reading my response I think that a point I was trying to make and missed was that this helped me to continue to try something before asking for help and then not get down on myself for being "wrong" when what I tried went through code review or whatever.

Collapse
 
hrishio profile image
Hrishi Mittal

These are all excellent! Once you've mastered these and graduated to senior developer (there's no such thing as mid-level), I have one pro tip:

When you join a new team, look at the code and be shocked at how horrible it is. "Who wrote this!?", exclaim in your first standups. Then completely rewrite core business logic (don't worry about not understanding it yet, remember tip 2 from the beginners list) using the advanced patterns that only you know (and others haven't even heard of!). Win everyone's hearts ❤️💚💙💜.

Collapse
 
yoursunny profile image
Junxiao Shi

TCP/IP and HTTP are so outdated. I'm building a new network protocol.
I plan to dig a tunnel and lay a fiber across the country for the new Internet. Anyone wants to donate a shovel?

Collapse
 
jwp profile image
John Peters • Edited

A true masterpiece. It should be a requirement to memorize for every CS101 class available. Nobody can be hired without repeating it all.

-The Nader Principals

  • Nader Rules
  • Nader Raiders
Collapse
 
dansilcox profile image
Dan Silcox

Nader’s Law

Collapse
 
willjohnsonio profile image
Will Johnson

Old man Nader is my favorite Nader

Collapse
 
devimposter1 profile image
devimposter

I seriously thought this was going to be a wasted read but it was pretty funny :)

Collapse
 
jacobmgevans profile image
Jacob Evans

Nader...Seething, dripping sarcasm THIS IS MY HOME! The spice of LIFE my friend lmao

Collapse
 
crystalhappy777 profile image
CrystalHappy

So how many clicked on intergalactic beastie boys video lol haven’t heard that in a long time. I still don’t get why let went to const especially for new learner your start learning with let and then mid course using const I would be one of the ones fixing it to make it all match and I love html back in the day when you could design your own MySpace page I hooked all my friends up. Ha ha