It is very easy to tell new engineers that they should learn from their mistakes, but often we struggle to explain how we should avoid those mistakes in the future.
The first and most basic method (as I often explain) is to simply write stuff down.
Having good documentation of the things you did correctly and the things you did poorly allows you to go back and review before starting a new project. Of course that assumes that you have the discipline to clearly document the current project—and that you have the discipline to review your past before starting a new effort. Many companies suffer from the “lessons not learned” syndrome. This is where they carefully document each project and then file that information away into some inaccessible archive that never is touched in the future.
One method of prevention is to use checklists. When a particularly egregious mistake is discovered, it becomes part of the engineering checklist for that specialty. There can be a trap in this method. A poorly designed checklist asks for too many items to be verified. Soon the engineer becomes overwhelmed in tedious and time-consuming testing that is not identifying any new failure modes.
Good checklists require constant maintenance: you have to review every item and ask if it is duplicating some other item. We want to keep checklists to the minimum and yet be sure to cover all of the failure modes we have already encountered. Sometimes this means inventing a new, complex test that actually covers many kinds of design impairments in a single measurement.
Another method for learning from mistakes is to create a culture that celebrates the identification and announcement of failure. Say what? Yes: you can encourage regularly scheduled, open and honest discussion of the things that went wrong. It is very important that these meetings avoid shaming, blaming, and gaming. The goal is to share wisdom and experience with each other. Remember that experience is what you get, just after you needed it.
One of the worst things an organization can do is to engage in fault-finding witch hunts. These efforts teach the exact opposite of what you really need in a healthy engineering organization. Instead they are sending the message that hiding failure and avoiding blame are the highest goals of your project. Such organizations will never produce great designs.
One excellent tool for learning from mistakes is to implement your checklists into automated systems for testing a design. This is where having a longer checklist does not have much impact on the engineer’s workload. The computer does not get tired. The computer does not care if you ask it to do extra tests or redundant testing. Just be sure that the automated test output is clearly reported, well organized, and understandable. Computers can generate mountains of useful test data, or just as much volume of garbage.
Finally, there is a need to constantly review the tools you apply to your efforts. Smart people, just like you, are always inventing new tools to help you discover problems in your designs. Smart organizations recognize the value in capital expenditure on these tools. Dumb organizations strangle their teams by saving money at all costs, and instead yell at their employees to stop making mistakes. I hope you work in a smart organization.