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