I think you're hinting at TDD.
In real life, you usually solve a problem, not simply write a piece of code. Unlless you have an amazingly detailed spec, the interface is usually unknown, and you cannot write tests for it at this stage. Usually, it takes some time before the interface is finalised. Thus, tests have to be postponed for a bit.
Second reason I didn't mention it here is because following TDD is rather difficult, especially for beginners. I don't want to scare developers off unit testing because they would think it is too difficult. It is actually easy - if you are starting slowly, with simple ways to do it.
Thirdly, I don't mind which way you come to the final result. If the final result is code sufficiently (sic!) covered with tests, I don't mind if you wrote tests before or during or after. One absolutely can write a great unit test suite without following TDD religiously. Gatekeeping of this sort - "you're not a good developer if you don't follow TDD" - has never seemed a good idea to me.
I usually advise to write tests along with the code, if possible, but I don't make it mandatory.
I don't mind, of course, if people do follow TDD. If it works for you, great! If you prefer it, why don't you write an article explaining its benefits?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.