The critical objective either of these approaches is aimed at achieving is helping you _think deeply_ about the problem; how that is best done largely depends on the software engineer.
I feel design docs are a way to ensure that you indeed think through a problem as much as they are a tool for peer review. If you wen't through a fairly standard educational system, it's not unfamiliar to use writing as a way of thinking more deeply about a problem and communicating those thoughts with others (namely your teacher) -- a design doc is no different. This can fail when design docs are written as templated box-ticking exercises and address more superficial technical questions than the core problem of course; it actually needs to address the problem and that is very contextual in my experience.
However some folks are just better at solving problems with a more hands-on approach, in which case throwaway code may be more effective. If that is you then go for it, though its likely you'd need to still need to write _something_ to either document changes or communicate your decisions/trade-offs with the rest of your team.
Fundamentally just do what allows you to solve problems best and take into consideration how to best work with your team. There is no one-size-fits-all solution to _thinking_ and broadly no-one cares how you work (I believe, I mean I certainly don't) if you're efficient, communicate well and get the job done to a high standard.