When I was a young man (yes that's been a while now) I suffered from Y.E.D. (Young Engineer's Disease). Here are some of the symptoms.
The design assumes the user thinks like a software engineer. For example, the user is expected to:
Click buttons in a prescribed order.
Know, or be able to deduce, things that will and will not work.
Comprehend technical jargon.
The problems with these assumptions are obvious: Users click what they want when they want and they will eventually try every permutation of button clicks; they cannot always deduce what will and will not work; and they do not always comprehend technical jargon.
The solution is to hide or disable buttons you do not want pushed; provide in-line feedback, help, and status messages; and spell out exactly what the application will do and when it will do it. Equally important (if not more so) is to explain what the application will not do. It's not that users are dumb. It's not their job to interpret what we meant when we developed the application. It's our job to develop intuitive applications.
One Size Fits All
Young Engineers rarely consider scale. Scale requires multi-dimensional thinking and that's hard.
Often, folks develop software to solve a particular problem. There's nothing wrong with that. The issue begins when the problem solved is not that big a deal in the original enterprise, but is a huge problem in for a different company, or relatively the same size in a much larger corporation. I've seen many an application delivered to a large enterprise only to fall on its face as soon as it's under load. Bummer.
The solution is to think in those other dimensions. Don't merely imagine what would happen to your application if it was pushed beyond the envelope, push it until it breaks and find out!
Grand Unified Solution
Sometimes Young Engineers write "Silver Bullet Applications". More often, Young Engineers think they've written a silver bullet application.
Silver bullets are hard. Making software that's really good at one thing is difficult enough. Refactoring the same software to solve an issue that appears similar is often more work than imagined. In my experience, it's usually a lot harder than anyone expects at the start. Why try to refactor then? Young Engineers readily identify the 90% of functionality overlap between the requirements. They fail to recognize the remaining 10% will not translate into "1/9th of the time it took to write the 90%". It usually takes much longer. And the increased complexity of bending an application to perform a more rich set of operations easily adds an order of magnitude to the complexity of the necessary coding.
The solution is really twofold: Either architect solutions from the beginning with multiple solutions in mind, resist the urge to refactor an existing application into a Grand Unified Solution, or both.
My bride Christy has an excellent saying: "Good judgment comes from experience, and experience comes from bad judgment." Y.E.D. is a self-correcting problem.
Young Engineers are tomorrow's architects. One of the most important jobs for today's architects is mentoring them.