Emotion Driven Development

Traditionally, software engineering lacks empathy and consideration towards human beings. Digital machines often fail to
see the shades of gray between 0 and 1. Engineers are not machines, they are people with feelings that could be hurt.

For too many years engineers suffered from merciless compile errors or from heartless machines so stupid that they could
not understand engineer's intent. Bugs caused by a misbehaving machine is an inexhaustible source of frustration.

There is a solution to keep developer's fragile mind in peace. The solution naturally comes from the inherent human
advantage: fuzzy emotionality. If you can not compete with a soulless machine in precision, just add emotions to your
daily routine!

There are few best practices that will help you to feel better and build software that cares about you.

• If your code have places where errors may happen, ignore the errors. Errors are well known to be a prominent source of bugs and disappointment, so no error means happier developer.
• No tests. Not only they are tedious to write, but also tend to fail from time to time raising anxiety and disturbance.
• When picking dependencies always look at the number of stars on the project, stars are just like likes in social networks. Using a dependency with many stars makes you more confident and delighted as you share the joy with other empathic people.
• Never check your dependencies for technical metrics like performance or number of outstanding issues, you can save that time for the carefree exploration.
• Stay away from the projects with single or few contributors. There is a high chance the project is done by a very toxic person, that's why nobody wants to help her.
• Whenever new cool technology appears on the horizon, immediately integrate it into your production ecosystem. New technology is like a new jacket, it always brings satisfaction and a fresh look. If something goes wrong, that's not your fault, but rather a misbehaving machine out of control.
• Throw away established technologies. If something just works, that is a poor excuse of existence. Technology must bring joy of discovery!
• Implement most of the things yourself. While it is okay to depend on library with many stars, it is totally unacceptable to depend on the code written by your colleague. You know who knows best. You! Code written by a teammate is not only obscure and hard to empathize, but also is not clever enough. Maybe it was a mistake to hire that guy in the first place. Rewriting the code for aesthetics reason grants a great feeling of supremacy and helps your mojo to grow.
• Take every opportunity to replace the code. If you discovered a bug, or have a security concern in a 3rd party library, remove/replace that library. It does not make sense to contribute the fix, because it is too much of a burden with no guarantee that maintainer(s) will accept the change without asking a bunch of toxic questions. Even raising an issue might be not a great option, removing the code altogether is the safest bet.
• Avoid finishing projects. When the project is done and supposedly ready to serve, the outer environment might be too harsh to the baby. The load can be too high, the edge cases can be too edgy and consumers can be just too demanding. All those things contribute to the unhappiness of a developer. The best strategy is to close projects just before they are finished or to delegate them to some other people. There is no doubt, other people will be excited to finish the project and learn so many things from you.
• Disrupt the routine. Don't take all the fun of EDD to yourself, enjoy it together with other people. If you've spotted a shiny new technology or if something is built not in a way you would build it, share your finding! Make sure everybody listens and prioritizes your idea on top their useless plans. It would help if you have some authority granted by the hierarchy in the company.
• Embrace changes. Make changes your best friend. Rename a few variables and functions to get the feeling of high productivity. Don't hesitate to make changes in public API and application behavior when you feel the originals are not ideal.
• Listen to your heart. If somebody questions your idea or code or anything else, don't answer or try to postpone the answer. That person is most likely toxic if they decided to ask you a question. Gentle people don't ask, they understand. No need for a heated discussion if you already know the right answer, the one coming from your heart.
• An emotional engineer has no goal, only path, and engineer’s path is learning themselves through code.