In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.
But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.
Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.
what ive found works is to /always/ pair a jr with a sr engineer to write any ddoc. 2nd, always assign a specific sr reviewer. only after that review, release the hounds. others that have interest or particular insight can reflect on deficiencies (or, rarely, strengths) without the dread feeling of having to deeply understand the context or underlying dependencies.
same reason you don’t just throw a code review out to “everyone”. everyone = no one
In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.
But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.
Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.