"Error establishing a database connection"
Maybe you should rethink that rule when it comes to your sysadmins and database admins.
Maybe you should rethink that rule when it comes to your sysadmins and database admins.
Being completely risk averse creates an environment where it's very difficult to improve, for fear that your good change will happen to cause a problem and you'll get blamed for it.
That's not being risk averse. That's bad management. A manager's role is also that of a mentor, helping your employees leapfrog over obstacles you've encountered in the past. (Don't get me wrong, there's a wrong way to do it - micromanagement.)
Controlling for how big or how expensive that failure is are both necessary components of the task; don't let them fail in a way that's going to torpedo the company.
But only being told how to do something makes a person a good follower and does nothing for their innovative or problem-solving skills. That's also bad management.
A successful professional needs a back catalog of failures and misses to understand why to do something.
For example, if they are designing a backup solution for the first time, asking them "what will the system do if the backup media is full?" is good. Telling them what it should do when full is bad. By asking the question, you're basically teaching them that there should be a contingency in case of failure. From there, a discussion on possible solutions can take place, where the mentor once again guides the employee to figure out the pros and cons of each approach.
That said, I'd never knowingly let people fail. Even without that, any good professional will have plenty of failures anyway. If they don't, they are playing it too safe and aren't learning some important lessons, and it might be time to assign them more challenging projects.
That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together?
It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. It also assumes you can predict every problem they'll encounter well enough to precisely ration out additional obstacles.
People learn differently from experience than they do from being told something.
>>It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself.
That's the thing though: people rarely make the same mistakes as you did. They tend to make different mistakes, and fail differently, with different results and consequences. By serving the solution to them on a silver platter, you're robbing them of very valuable learning opportunities.
A mentor's job is to use their experience to guide the employee and help them figure out how to avoid mistakes. And if they do make a mistake, then the mentor is there to help them recover. The recovery is followed by by what I call "lesson time", which is a judgment-free session where we discuss why the incident or failure happened and come up with actionable steps to prevent it from happening again.
If you find yourself in situations where you absolutely have to tell someone how to do something because failure would be fatal, at that point you should do that thing yourself, and have the employee watch you do it and take notes. That's another type of mentorship that a lot of people are not comfortable with, but it can be extremely valuable.
This wasn't assumed in the premise, though the mentored may for sure have some experiences that the mentor did.
Learning and internalization happen after we synthesize stories and narratives into lessons that we can deeply connect with.
If a junior teammate comes to me with a solution and I say "I tried it that way once and it didn't work because xyz," that teammate will change their execution and, from my experience, not really internalize the xyz. This means they'll come back to me in the future with the same problem and we'll go through that again, because they didn't learn.
The critical action in both success and failure is reflection. Discovering the lessons through discussion is the way for us both to learn, and to ensure the experience is meaningful and sticks.
Second worse case is that they fail, don't learn anything; lather, rinse, repeat. The worst case? They produce a semi-functional failure and you have a shambling horror of a monstrosity to support until you finally give up and resign.
Don't let them fail: Second best case: You mentor them into a failure, but they learn something and you learn something. That's sort of good, right? The best case is that you mentor them into a success, they learn stuff and you have a functional project.
The second worst case is that you beat them into submission and get a functional project, but they resent you for not letting them do things their way; they haven't learned anything. The worst case is that you mentor them into a failure, catch all the blame for it, and they're now mentoring you. (And yes, I'm explicitly assuming that you are ten times as skilled and experienced as they are; this is a very bad thing.)
Now, it may just be my experience, but the best cases on either side are entirely theoretical. I've only personally experienced variations on the worst cases. But, I've also worked in government contracting (that may be redundant). There are a lot of hard-headed, not-especially-competent junior devs out there.
The bottom line is that you should just do it yourself---it'll generally save you a lot of grief.
I'd love to find some way to deal with the politics of the case where you end up with the shambling semi functional monstrosity.
Watching someone who is clearly out of their depth trying like hell to save face while time slips past and the software doesn't improve is very frustrating.
For vital infrastructure, it's more important that those "failures" be more in the way of the dba or sa needing to look up how to make something work properly, than actually fry the server instance and wipe your data.