Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
We've all been there:
My question is, what is the most productive way for a programmer to handle development-related failures such as these?
Your project failed.
Software development is highly prone to project failures, and depending on the severity, this is best handled by management.
Many projects have failed and many more will fail, so take notes! Learn why your project failed so you don't make the same mistakes next time. You learn much more from your failures than from your successes.
What you have spend coding days on was rejected by your team.
Save your work (for later). There are two possibilities: (a) It sucks, and the fact multiple people responded the same way is indication of this (b) It's truly genius work, but far ahead of what people are used to or can understand. People generally do not like what they do not understand. Perhaps its better to show it when the time is right OR in a different place with a different "Culture"
Nobody listen to your ideas in your company.
Its probably a bad idea, OR the culture is not aligned with your thinking. Either move to a place that supports your culture or critically evaluate your idea again (objectively without your own bias) -> is my idea really that good? <- Kill thy ego
The design pattern you introduced with force in your team created a mess.
Be honest, you tried your best but it did not turn out how you planned it. It may be better to start again or learn from the mistakes made in the design as a team and move forward.
They're not failures - they are experiences
You learn and grow from your experiences by reflecting on how they made you feel and if you want more of that feeling.
If it's a bad experience (like that list you offered) then the accompanying bad feeling is probably something you'll want to avoid (assuming you not so thick-skinned that you didn't care about the impact of your actions).
Overall, don't get too involved in comparing yourself to others, they're having just as much trouble working through it all as you are.
You build something.
For me (I don't think it's right for everybody), building something (comics, drawings, little games, anything) is like building a bit of confidence to get back to fighting failure. It might also be a good way to express your anger or bitterness or any feelings relative to the failure, but in a "constructive" way.
That works for me anyway.
Well, you asked :) One by one:
* Your project failed.
That is hardly new. We've all failed privately, and we've all failed in full view of our peers. Anyone who has gone through primary and secondary education has experienced this.
If I can't make mistakes and expect stable employment, you should consider sending a memo to HR letting them know that human beings will be banned from future consideration.
Several failures in a row means you either have unreasonable demands and specifications, or you don't learn from your mistakes. Either scenario begs immediate action.
It is conceivable that many people sign onto something just to gain employment, then work out some way of making the requirements happen.
* What you have spent days coding was rejected by your team.
That happens. As others noted, save it. Do it again. This is why we call it work. I think, in this case, you probably did not involve the team very much in what you were doing.
It could also be that requirements changed yesterday, or an hour ago. This should be an exception, not a norm, however. Peer review is as brutal as it is helpful. If your code is constantly dismissed as 'inadequate' (or something like that), you should spend more time picking brains and involving others. I believe this question to be a fallacy in most team settings, unless the 'team' is anything but self describing.
* Nobody listens to your ideas in your company.
Again, this needs context. How long have you been there? How much do your fellow hackers trust in your ability? Have you considered that ideas that result in more work for many people might invite ANY reason to dismiss it? I once had something dismissed because it was not IPV6 ready, yet it used a simple domain socket on the loopback device (exclusively). The person who sunk it simply couldn't take any more work to do.
Also, how well do you articulate yourself? Can you make friends and influence people?
* The design pattern you introduced with force in your team created a mess.
Hence why force should have been avoided. Being able to talk is not a prerequisite for being able to listen. No other comments.
Oh boy, that's a lot if you really meant everything happened to you!
WARNING: In many of the points below you might feel like I criticize you and that I want to make you responsible for the mis-happs and not consider external factors. I don't. It's just that you don't give much details, and I just provide check-lists of actions to undertake to ensure that things don't go awry. I know I've done lots of mistakes myself (everybody does) and we only get better if we learn from them. And to learn from them, we need to start to see them as mistakes in the first place, and accept responsibility for what went wrong on our part. Hell, accept responsibility for what went wrong in other people's parts, you can learn from that as well.
Not much you can do to mitigate it now.
However you can do a lot to avoid that to reproduce in the future. I'd suggest trying to improve your project and time management skills.
One of the books with the best ratio ((valid advice) / pages) I've read on the subject, while maybe not the best, it Rob Thomsett's Radical Project Management.
You don't really specify what your project failed, but I'd assume a combination of thing which brought unbalance in the usual cost/time/qualiy triangle. The most important factor in my eyes is to lead the project and the development while being always in touch with both your technical actors (devs and testers) but also your stakeholders. Far too many projects fail because they don't listen to sponsors or stakeholders and don't push them to get involved in the process.
If they're not involved, you cannot know what they want. If you cannot know what they want, you cannot deliver it. If you don't deliver it, they'll be unhappy. That's a failure. Furthermore, if you don't involve your stakeholders, they're disconnected from the reality of software engineering, meaning they don't understand your issues. If they are often in touch with you, they get a better grasp of what you have to deal with. They'll be more able to understand when you tell them that a "small" [laughter] feature will take months. They can trust your planning better because they helped building it. A project cannot succeed with just "specs at the beginning, dev, testing, delivery at the end". It just never does. You might deliver what was asked for in the specs, but not what the customer really wanted.
Most important as well, do a retrospective, and ensure it is ego-less and not a blame-game. Just identify issues.
I have been in that situation. Again, not much you can do to mitigate that except:
But there are things again you can do to prevent this sort of situation:
Well, there are 2 options here, and we'll look at both:
Let's start assuming they were bad (again, self-reflecting on that and accepting your idea was just plain bad might be difficult, I know). What do you do to change that?
Ideas are only ideas. If you just suggest them as ideas and they are rejected, I don't see why you would feel bad about it. If however you act up on them without notifying anyone and THEN only submit your ideas and they get rejected, obviously I feel the frustration at the time wasted. And your managers do to!
Assuming your ideas were good:
Also, I am a bit surprised by the approach itself. You had to actually push for a design pattern to be introduced? That seems rather odd. A pattern is either there already, or you need to refactor a part of your solution according to the pattern. You don't push it like you would the adoption of a framework or technology (like people pushed really hard to have XML everywhere, and now like people start pushing to be able to write HTML5 on their product cover in big bright letters).
Why did you have to push? Why was there resistance? Maybe it was justified.
Were you able to you provide examples that this particular pattern would help to improve your code base in significant ways (for instance, by matching it with an example of Refactoring to Patterns).
Completely off-topic note but that's what I first thought of when I read the question's title as I thought it referred to software failures... I had a software who implemented a BlackHole class to manage a very special kind of exceptions in one of the components. It may seems like (and really is) an obviously weird and dirty hack, but the naming itself was so superb we all appreciated it for a fairly cool way to handle a failure! :)
First, it's understandable to be upset or angry when encountering failure. If giving advice to someone in such a situation, they are most likely not going to want to hear "Just get over it and move on" or "Just think of it as a learning opportunity".
In fact, I think it can be healthy and productive to get upset and vent your frustrations, provided that you do it privately or with a friend. People have different ways of doing that, but I think one of the most productive ways is to write an angry fake letter (Important! do not send this letter to anyone). Explain your feelings, such as why you feel that whatever happened was unjustified.
Make sure that you've expressed everything that you're feeling, and after venting your anger just take some time to calm down. Maybe you only need a few minutes, or perhaps a few hours.
At this point you will hopefully be able to think more objectively about the situation. If you wrote a letter, then read it to yourself. If you confided in someone, then try to remember what you said. If you just imagined shouting at someone, then just mentally review that.
I often write a letter when I'm angry and then after I've calmed down I will work on refining the letter to more clearly communicate what I was originally trying to say until I'm satisfied that someone reading it would understand what I was feeling at the time.
The point is to objectively try to pick out what your points were. Did they make sense? Perhaps they need clarification or further detail. Are they unfounded? If you were to objectively put yourself in someone else's shoes, would you understand the points that you made? Would you agree with those points? You can use this opportunity to evaluate yourself. What did you do well? What were some things that you could have done better?
Is there something that can be done to remedy the situation or to at least improve it? Take a moment to consider if there is realistically anything that can be done to fix or improve the situation. Often there isn't, but sometimes there is.
If you are at fault for something, then that might be as simple as a formal apology to someone, clearly explaining what went wrong, what you did, why you did it, and what you will do to fix it or prevent it from happening in the future.
Next, consider what you can do to improve the future. What can you do to prevent the same thing from happening again? Decide what it is that you want to achieve and use what you've learned from step 3 to create a plan for yourself.
If all else fails, try rebooting:
try
{
// ...
}
catch (OhNoes111Exception)
{
// reboot fixes everything!
System.Diagnostics.Process.Start("ShutDown", "/r");
}
