Medium is full of useful articles and great advice to create robust and maintainable applications. But what If you don't like your colleagues and want to ruin their day? Then worry no more. I’m great at giving bad advice and came up with 15 tips to cause frustration and waste everyone's time.

1. Abstraction Layers

Use as many abstraction layers as possible until:

The code is difficult to understand and debug.
It is difficult to make changes to the code.
The code is slow or inefficient.
The code is not reusable.

2. Always Request Changes on Pull Requests

You should always block a pull request during the first review to assert dominance.

Some ideas for change requests are:

Make a variable name longer
Make a variable name shorter
Rename a variable name
Make code more DRY

3. No Commit Messages

Good commit messages take time to write. Instead of spending your valuable time writing something like

[JIRA-1234] build: replace vue-cli with vite

you can use the following command to push your code with an empty commit message

git commit --allow-empty-message -m "" && git push --force

4. Use Magic Numbers

Use magic numbers often to indicate that you know exactly what you are doing

window.scrollTo({
 top: 89,
 left: 12,
 behavior: "smooth",
});

5. Mix Return Statements

Never let them know your next move by mixing the return statements of a function

function shouldPayTax(income) {
 if(income.amount < 20_000) {
 return false
 }
 if(income.amount > 20_000 && income.country == 'USA') {
 return true
 }
 if(income.country == 'Panama') {
 return false
 }
 if(this.totalWorkingHoursPerWeek > 60) {
 return true
 }
 if(income.amount > 20_000 && income.isCelebrity == true) {
 return false
 }
 if(income.amount > 20_000) {
 return true
 }
}

6. Typescript

If someone had the audacity to add TypeScript to the project, you can bypass type checking by using any everywhere.

function add(a:any, b:any):any {
 return a + b
}

7. Use double equal instead of triple equal

Use == instead of === with the excuse of saving valuable bytes in your production bundle.

8. Comment Code

On top of writing code that is hard to understand, leaving misleading comments that make no sense is a great way to confuse others.

Some rules to follow:

Comments should duplicate the code.
Comments excuse unclear code.
If you can write a clear comment, don’t.
Comments should cause confusion, not dispel it.
Never provide links to the original source of copied code.
Never include links to external references where they will be most helpful.
Never add comments (or tests) when fixing bugs.
Never use comments to mark incomplete implementations.

More rules to avoid

9. Use Props for Shared State

Passing state around with props is a great way to couple component hierarchy and make refactoring harder.

10. Use State Management for Component State

Component state on the other hand should be moved to a global store so everyone can modify it.

11. Long Component Files

Use big and monolithic components with the excuse of having a better view of the component responsibilities and the ability to reuse variables across features.

12. No Linter

A linter can analyze your code, and detect potential errors, inconsistencies, and deviations from established coding standards which is something that we clearly don't want.

The difference in the two following snippets is apparent:

const props=defineProps({
elements:Array,
counter:{
type:Number,
default:0,
},
});
const{data,method}=useComposable();
const isEmpty=computed(()=>{returnprops.counter===0;});

watch(props.counter,()=>{console.log("Countervaluechanged");});
const emit=defineEmits(["event-name"]);

function emitEvent(){
emit("event-name");
}

function getParam(param){
return param;
}

const props = defineProps({
 elements: Array,
 counter: {
 type: Number,
 default: 0,
 },
});

const { data, method } = useComposable();

const isEmpty = computed(() => {
 return props.counter === 0;
});

watch(props.counter, () => {
 console.log("Counter value changed");
});

const emit = defineEmits(["event-name"]);

function emitEvent() {
 emit("event-name");
}

function getParam(param) {
 return param;
}

Pro tip: the only acceptable usage of a linting rule is to enfore a file to be longer that a given amount of lines. 1000 is a good starting number.

13. Use HTML inside Translations

Using hardcoded strings is always a good idea. But sometimes using translations that include html elements and classes can be even better.

translation.key.name = Hello <span class="red">World!</span>

14. Write Tests

Not writing tests is a good option but having a bad suite can cause even more frustration. As a general guideline, a test should be:

[S]low — taking enough time to brew a coffee
[U]nreliable — produce variable results
[C]oupled — affect other tests
[K]nowledgable — know as much as possible about other parts of the application

More tips to avoid about unit tests.

15. Always Trust Everyone

Lastly, defensive programming is for the weak and inexperienced. Why would anyone want to hurt you anyway?

Conclusion

Please don’t hate me and don’t get fired because of this. 😅

If you want to read more terrible advice have a look at 60 terrible tips for a C++ developer which inspired this article. And if you have a piece of evil advice yourself please leave a comment below.

15 Terrible Advice for Web Developers