Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "wasabi"
Call comes down from the CEO and through his "Yes Man" that some investors are coming by to visit and he want to show off the data center and test servers. There are four full racks of storage servers filled with HDDs and each server has 4 to 16 HDDs a piece.
I got told to "make all of the lights blink", which can be epic seeing it in action but my test cycles rarely aligned that way.
All morning I was striping RAID arrays and building short mixed I/O tests to maximize "LED blinking" for the boss's henchman.
Investors apparently live/die by blinking light progress and it was all on me to get everything working.21
Applies to: instructions, signs, traveling to new locations, arriving on time, etc.
1. Always read the documentation before asking questions.
2. Ask for clarifications as soon as possible.
3. Never underestimate the complexity of a task even when it looks simple. (traffic)
4. Always test the current application before adding a new feature. (shortcuts, baggage, companions)
5. Never trust everything the previous developers say about their code. People forget. See for yourself.
6. No, you will not remember what this part does. Take notes, write comments, docstrings, and give objects reasonable names. (that hookup has a name and is someone's child)
7. Get things working way before the deadline. (check-ins)
Applies to: talking to people, being precise, etc.
8. Don't turn the method definition into an essay.
9. Break things down into smaller pieces, if possible.
10. Avoid misspellings. The computer may not get confused but the next developers will.
Applies to: communication, relationships, etc.
11. Be considerate.
12. People in higher positions make mistakes too.
13. Communicate. Don't expect people to read your mind and don't assume you have all the information you need.
Applies to: utensils, sex toys, compatibility, sexual preferences, etc.
14. Don't do random hacks just to make something work. If it's not the tool for the job, use something else. Wasabi doesn't make a good lube.
15. Product owners and users don't always know what they want. ;)
16. Stop being an asshole unless you have lubes and da hole tyt.
17. Be assertive, not aggressive but spank and choke me anyway.
18. Consider each sprint as a sport. You may have almost killed each other during the game but keep it civil after. (violent love-making)
19. Don't burn the bridge when leaving. Someday, they can refer you to a better job or you can refer them and get money out it. (hookups and prostitutes)
Applies to: beliefs, religion, obsessions, hobbies, etc.
20. Programming languages are not cults. Same with IDEs, tech stacks, etc.
21. Use linters. (check yourself)
22. Be aware of your own bias especially when testing and debugging your own code. (reflect)
23. Being antisocial does not make you a better developer. Stop romanticizing it. (delusions)
Applies to: life in general
24. Be patient. You'll get out of the maze. You always do.
25. Stop blaming inanimate objects for your code not working. Behind every inanimate object is a person responsible for the failure. Most of the time, that person is you. If not, talk to the person and solve the issue.
26. Take breaks.
27. Keep learning new things.
Applies to: negotiation, transactions, relationships, etc.
28. Always send documented proof of requirement changes. (50 shades of grey contract, ew)
Applies to: sex
29. Write tests. Test your tests. Testes. Testicles. Tentacles. Testicular cancer.
30. Hostility never results to productivity. Wank it out, get back to work, and stay calm. (doms in BDSMs are gentle creatures)5