In a reasonably good team, you should have a _queue_ of tasks assigned to you in an [issue tracker](http://programmers.stackexchange.com/tags/issue-tracking/info).

That way, while you are waiting for a reviewer, you could (_should_) work on next task waiting in that queue. Once you get used to work in that fashion, this will open an opportunity to have your changes reviewed in "batches", thus decreasing delays.

* <sup>If you don't have such a "queue", discuss this with your manager, or better yet, with reviewer. If your team doesn't have reasonably convenient issue tracker for stuff like that, consider studying job boards or company internal job opportunities to find a better team (you might also discuss this with manager / reviewer but don't expect this to help - lack of a good issue tracker is often a symptom of something being severely broken in a team).</sup>

---

> I want to be free when coding. How could I gain the trust for development freedom?

To find out, you need first to understand the purpose of code reviews. You mentioned _trust_ - that's a good "approximation", but not entirely accurate one.

* <sup>For example, in one of my recent projects development has been done by a mini-team of me and my colleague. We fully mutually trusted and respected each other - but despite this we reviewed 100% of code. We were doing it because this allowed us to find and quickly fix some bugs and, which is also *very* important, because reviews didn't take much time and didn't block our work.</sup>

You see, it would be more accurate to think of code reviews in terms of **efforts invested in order to prevent certain risks**. In a good team, you can expect sort of shared understanding of how to "properly balance" this. Note there is no one-size-fits-all proper balance, it heavily depends on a project - risk of bugs in a mission critical software naturally differs from one in a non-critical application.

Using your example, you can expect "blocking reviews" as long as efforts invested by your reviewer are **justified** by finding bugs and improvements that are better be done prior to committing your code.

They likely expect that with practice and with guidance received at reviews you will get better at coding, so that they will find less and less issues worth fixing prior to commit. As soon as they discover that your code got "safe enough" to allow less cumbersome "risk prevention measures", you could expect the process to change, for example to [reviews after commit](http://programmers.stackexchange.com/q/164056/31260 "discussed eg here").

Depending on a project, at some point you code may be even considered safe enough to skip reviews at all, leaving discovery of the bugs to testers (but that not necessarily will happen, see my example above).