I consider myself a Frustration Driven Developer.

A FD Developer thinks that any system produces a certain amount of frustration during its maintenance and development operations and this is directly correlated to its overall quality. Frustration related to a system is something that is primarily perceived by its caretakers, who have direct contact with the system and its day-to-day operations, but a FD approach involves that a system with difficult maintenance will eventually fail its goal(s) and this will be reflected on its stakeholders.

A system frustrating for its builders and maintainers is a system frustrating for its users and owners.

A FD approach considers generated frustration as a human-centric metric with a difficult to measure value but a concrete manifestation in terms of bugs, un-happiness, missing knowledge, lack of trust, and general instability.

Given that frustration is built with every evolution of the system and increase in complexity, the more often a system changes the more effort is required to keep control of its new complexity and therefore of its new source of frustration. A software developer who is aware of such is someone who believes in continuous improvement in terms of understandability of the parts of the system, she/he tends to make the code a bit better every time is modified and consider improvement as a non-delayable part of every development. Code developed following the principle of continuous deployment tends to change in circles of minutes or hours, therefore tackling complexity and indirectly frustration is fundamental for its success.

In short, a frustration driven software developer knows that:

• A sustainable development pace is necessary for keeping frustration under control.
• Time is the best test. Every change requires time to stabilize.
• Quality is influenced by frustration, quality can be perceived even outside the system.
• Building incrementally is the best way to build good systems.
• Automatization and the domain of it is key in controlling frustration.
• Documentation separated by the code tends to be wrong with time, clean and speaking code is the best documentation.
• Complexity and frustration applies also to development teams. Developing requires continuous decision-making, when too many people are involved, the time price to pay for every single decision might become too high.
• Satisfied developers build excellent products, frustrated developers leave or break.

I consider frustration in my day-to-day work as a software developer and being aware of it and actively working for its reduction makes me a better professional.