Automated testing & development psychology

It's vital that you receive feedback for a work you've done - the sooner the better.

I myself too aware of situations, when you don't get enough feedback from your job in software development. Sometimes managers don't provide developers full details on their plans, sometimes they don't realize themselves. A product is not always properly tested. Frequently it's written as an experiment, a prototype, or it's not intended to be in use in the nearest few months. These situations can reduce developer's motivation.

How a developer knows that what he's done will work properly?
How he knows that he has done well today?

Job is being different.

Frontend developer is in a better position, as he checks result of his job directly. Yet in case of more complex interfaces, his product will behave differently in different cases, e.g. different devices or custom widget layouts. Even when you just do HTML and CSS, you have to be aware of smartphones and tablets quirks.

Backend developer sees nothing. If he owns great memory & imagination, and nobody distracts him with minor tasks and fixes or personal affairs, he can keep a small system (or a module) in his head, and see that he'd done all properly, and praise himself.

Though if he's working on multiple projects simultaneously, and distractions emerge constantly, it's impossible to work that way. If it's possible yet, a project is becoming too dependent on human factor, i.e. on intellectual strength and disposition to errors of one single person.

How it can be solved?

In case of backend & frontend, you can give both parts of the job to single person. This means he or she can check results quickly, but it won't work for complex systems. If backend and frontend is written by two different persons, too much time will be spent for bug report exchanging (I myself been in such situations, at both sides).

One can write backend together with automated tests, and this will result in immediate feedback, and a feedback system for all features for future. This gives confidence, and most important, a chance to learn on one's mistakes.

The sooner we get feedback on a job we've done, the better we realize this feedback.

What else?

I myself like to start a phase of  work with some refactoring. It's pleasant as the task is changed: your job at the moment is not a new feature, but a better code structure. You check yourself only by assuring that old features are working as before.

Another advantage is that automated tests also give a chance to see your code from another point of view, even if you're tired because of large amount of job. This may result in a better module or public API design, and better readiness for generic usage.

And again:

• Feedback is a vital condition to learn and improve. It's just how our brains work.
• Sooner you receive it, more you'll get from it.
• Feedback makes you feel content.