loading...
Cover image for Top 10 Pieces of Advice for Becoming the Worst Developer Possible

Top 10 Pieces of Advice for Becoming the Worst Developer Possible

dabit3 profile image Nader Dabit ・4 min read

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).

Discussion

pic
Editor guide
Collapse
codemouse92 profile image
Jason C. McDonald

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

Collapse
dabit3 profile image
Nader Dabit Author

😂😂😭

Collapse
mtee profile image
Margaret W.N

😂😂 I'm inspired!

Collapse
hugekontrast profile image
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
willjohnsonio profile image
Will Johnson

Old man Nader is my favorite Nader

Collapse
jwp profile image
John Peters

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
jacobmgevans profile image
Jacob Evans

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

Collapse
devimposter1 profile image
devimposter

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

Collapse
sjatkins profile image
Samantha Atkins

Well, as a universal GUI specification the html/javascript/css trio does in fact really suck. It just happens to be the best universally supported one today. I would be delighted if some disgusted nerds attempted better - just not in the middle of an actual software company trying to ship product.

And the backend HTTP stack without or without graphQL is pretty awful. Slowly we try other things like websockets and http2. Which are still imho too close to what already sucks but are proof what we have isn't good enough.

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

Collapse
swyx profile image
shawn swyx wang 🇸🇬

i am glad that Clean Code is not on this list because that is obviously not something that worst developers can even comprehend

Collapse
cirphrank profile image
🎧Cirphrank👣

Thanks for these tips, they're golden.

Collapse
cwraytech profile image
Christopher Wray

Great advice! Not listening to any of it because of point 2.... wait...

Collapse
shadowtime2000 profile image
shadowtime2000

Time to make my own markup language!

Collapse
yoursunny profile image
Junxiao Shi

I deliver websites in LaTeX. It's so much prettier than HTML.

Collapse
carlyraejepsenstan profile image
CarlyRaeJepsenStan

You should have mentioned clever coding lmao. I'll take a if/else or switch/case block over a ternary any day.

Collapse
jack_garrus profile image
Nadia G.

I would add: learn all the techs that the market requires and don't expect to be paid fair if you don't know them at the same time

Collapse
nicolaerario profile image
Nicola Erario

Fantastic post, “but what about readability”??!
😂

Collapse
colabottles profile image
Todd Libby

CSS is the hardest thing ever. So either use a framework or it's so old, don't use it at all.

Collapse
qm3ster profile image
Mihail Malo

Nothing wrong with the last one if you don't take over one day for the whole codebase.

Collapse
enmorial profile image
Enmorial

I had a good laugh reading your Post here :D .

Collapse
aspokes profile image
Albert Angmor

This is the stuff of legends....copy and paste everything. no need to understand

Collapse
kcboi95 profile image
Nguyen Dat

Ha, ha

Collapse
codingfix1 profile image
codingfix

😂😂

Collapse
nitsanavni profile image
Nitsan Avni

I do #1 all the time 🤦🏻‍♂️

Collapse
dmh2000 profile image
david howard

corollary to #9. Always argue with the thought leaders and senior guys. They obviously know nothing about how things work and what the tradeoffs are. They are old and stupid.

Collapse
jankapunkt profile image
Jan Küster

Don't learn the underlying concepts of a language or framework, just get things done until the deadline. Everybody will love your for that, especially management.