Just a few weeks until the 2021 JavaScript Full-Stack Bootcamp opens.
Signup to the waiting list!
In this tutorial I want to illustrate how to write unmaintainable code.
By writing unmaintainable code you can make sure you will never get fired because you’ll be the only one capable of understanding what the code does, and most importantly why.
Please note: this post is ironic
- Assign weird, fantasy and casual names to your variables, functions and objects. There should be no correlation between the name and what the item does or how it behaves.
- Prefer abbreviations and acronyms over descriptive names. One-letter variables are great.
- Favor reuse of variables in the code. Always use
i
in your loops. - Use your own language for names. After all, there’s no need to all use English.
- Same applies to comments. Feel free to write them in whatever language you speak, who cares if the next developer is from another country?
- As for comments, I was joking. Do not write any comments.
- If you really want to write comments, do not bother to update them when you change the code that they describe.
- Prefer global variables over getting too clever with scoping
- Never test your code. You are good, your code is good too.
- Prefer overcomplicating than being too simplistic. No one was ever fired for creating a complex and ego-fulfilling architecture that required a 3-months long useless rewrite of code that was perfectly working.
- Optimize whatever you can in clever ways. Computers are slow, we should avoid overheating them and help fight climate change. Rewrite your code in assembly is often a good idea.
- Relatively unknown languages and frameworks are always better than popular and battle tested solutions. Prefer them over the solution everyone else uses.
- Better yet, create your own framework.
- Never use 3rd party libraries
- Overuse 3rd party libraries
- Use every design pattern you read about, and try to fit it into your design even if it’s not, really
- Use tools built by large corporations because they know it better and your 1-person startup will surely benefit from the thousands of man hours that went into building them. Bonus points if they are very complicated to use and have their own set of clever-sounding naming conventions.
- Do not use version control, and do not even version the code at all. After all there’s just one right version of the program. You can easily remember all the changes you perform and most importantly why a change was made. No need to track it in an external repository.
- Freely copy and paste code from Stack Overflow or random blogs without understanding it first
- Indentation does not matter. At all. Mix spaces and tabs, too.
- Freely overuse abstractions. Abstractions are great. Make everything reusable and overthink things like a king.
- Perhaps you’ll reuse this library in every project you’ll make in the next 20 years, who knows? Better think about all the possible edge cases first.
- Always implement every single great idea you have
- 2000-lines functions are a great idea
- Assume there’s a 10x engineer watching over your shoulders while you code.
The 2021 JavaScript Full-Stack Bootcamp will start at the end of March 2021. Don't miss this opportunity, signup to the waiting list!
More lab tutorials:
- The stack I use to run this blog
- 8 good reasons to become a software developer
- SEO for developers writing blogs
- Review of the book The 4-Hour Work Week
- Build a lifestyle business
- Build your own platform
- As an indie maker, what kind of product should you build?
- Create your own job security
- Developers, learn marketing
- The freedom of a product business
- Generating value
- Have a purpose for your business
- The idea is nothing
- The niche
- Remote working for software developers
- Product / market fit
- The best podcasts for frontend developers
- Why should I create an email list?
- Disconnect time from money
- The scarcity principle applied to software products
- The social proof principle
- How I added Dark Mode to my website
- My notes on the Deep Work book
- The pros of using a boring stack
- How to estimate programming time
- On going independent as a developer
- How to learn how to learn
- Why interview questions for programming jobs are so difficult?
- Do I need a degree to be a programmer?
- Everyone can learn programming
- How to be productive
- How to get the real number of pageviews of a static site
- Have you filled a developer bucket today?
- How I record my videos
- All the software projects I made in the past
- Tutorial purgatory from the perspective of a tutorial maker
- Every developer should have a blog. Hereβs why, and how to stick with it
- Having a business mindset for developers
- How to write Unmaintainable Code
- What is Imposter Syndrome
- How to work from home without going crazy
- How I stopped worrying and learned to love the JavaScript ecosystem
- How I prototype a Web Page
- You should be the worst developer in your team
- How to start a blog using Hugo
- Write what you don't know
- How to block distractions using uBlock Origin
- Coding is an art
- I wrote 1 blog post every day for 2 years. Here's 5 things I learned about SEO
- Dealing with the fire
- On being a generalist
- The Developerβs Dilemma
- My plan for being hired as a Go developer. In 2017
- Productivity gains of using a Mac and an iOS device
- How to go from tutorials to your own project
- This is my little Digital Garden
- How to start freelancing as a developer
- Sharing the Journey Towards Building a Software Product Business
- Subfolder vs subdomain
- How I use text expanding to save time
- Software is a superpower
- I love books
- How I decided to create a new projects management app
- On using IndexedDB as the main database