Emotion Driven Development
Tags: methodology, edd, emotion, human
Published: 2021-01-07 11:14:34

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0hmcan64cpvahy27ccpq.jpg)

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.