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.
@dabit3 You need to know 100% of javascript before doing anything else at all.18:26 PM - 12 Aug 2020
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.
@dabit3 Never question the thought-leaders; they are always right and smarter than you14:52 PM - 12 Aug 2020
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.
Richard H. Boyd@rchrdbyd
@dabit3 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.13:57 PM - 12 Aug 2020
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"
Josh Carroll@jwcarroll@dabit3 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"15:57 PM - 12 Aug 2020
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.
Lindsay Wardell@yagaboosh@dabit3 Don't learn HTML, it's old and out of date.22:13 PM - 12 Aug 2020
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.
@dabit3 Try to make things as complicated as possible. That's the key to staying employed. #BadAdvice14:14 PM - 12 Aug 2020
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.
Sam Martinez@sam_martinez22@dabit3 Your opinion is the only one you need to listen to.14:38 PM - 12 Aug 2020
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
@dabit3 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.14:41 PM - 12 Aug 2020
This one is the most important of all (and is self-explanatory).
Latest comments (37)
It's mostly about frontend. That is why there are only 10 terrible tips. But things are much more serious for backend developers (C++)!
60 terrible tips for a C++ developer - pvs-studio.com/en/blog/posts/cpp/1...
This is the stuff of legends....copy and paste everything. no need to understand
Ha, ha
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
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
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.
😂😂
I do #1 all the time 🤦🏻♂️
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.
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.
I seriously thought this was going to be a wasted read but it was pretty funny :)
Thanks for these tips, they're golden.
Great advice! Not listening to any of it because of point 2.... wait...
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?
You should have mentioned clever coding lmao. I'll take a if/else or switch/case block over a ternary any day.