Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Have you always been fundamentally correct in the software designs you proposed? When you give out some design that was fundamentally wrong, you tend to lose the respect of your fellow team members. No matter what you do after that you end up being crosschecked for everything thing you propose after that incident. This is especially worse when you are new to a team and they don't know your past where you have had some good success stories.

Maybe the reason you gave a bad design was because of lack of experience or knowledge or both in that area. How have you who have faced such a situation dealt with it? Is this like a one time thing in your career or does it happen on and off? Does one put this behind or does one in such a situation need to look for a new line of work? Some honest feedback please...

Thank you.

share|improve this question

closed as not constructive by Mark Trapp Jan 10 '12 at 21:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

17  
perhaps the design was correct, just for a different system ;-) don't invest your ego in your code/designs, there are too many factors to expect perfection; invest instead in your willingness to learn, honesty (especially self-honesty), and teamwork. The design could have been perfect on day 1, and the requirements change on day 2! Learn from it and go on –  Steven A. Lowe Aug 4 '11 at 16:09
1  
I did not disagree. The solution I put out wasn't contested by my team as they are all juniors.When I proposed this to our customer who has had more experience than me and of better quality too, I began to realize just as he was shooting it down that I made a fundamentally wrong decision somewhere. Not only did I feel like a fool, I also feel like I let my team members down because they had put their trust in me and now I doubt they will do that. I don't blame them. I'd look at me with suspect if I were in their place. –  user20358 Aug 5 '11 at 4:54
4  
A good developer is not a developer that always make the correct decision but a developer that makes bad decision, admits it and quickly recovers from it. –  Rudy Aug 5 '11 at 7:06

18 Answers 18

up vote 176 down vote accepted

Once, the vp of a fortune 500 cost the company 1 million dollars with a bad business decision. When he turned in his resignation to the C.E.O the response he was given was, "I just invested One Million dollars in your education and now you are trying to leave? I do not accept."

I grow tired of managers and other workers who are quick to blame a mistake on someone being a rookie or assuming that they are incompetent. There is only one way to become a good designer and that is to f@$% a few up. I don't care if my employees make a mistake, I care if they make the same one multiple times. The question is, how humble and how teachable are you? When someone presents your error to you, do you defend yourself first, or hear them out? If you are one of the rare guys who can swallow his pride and learn from it, then you are worth hanging on to. Anyone who you lose respect from for making an error once, is not someone who deserves your respect.

I personally had to rewrite the first two projects I designed at least twice, but you know what? I learned a ton, and though my employers were perturbed at the time, that was quickly offset by the efficiency I gained over time by being willing to learn from my mistakes.

As to the humiliation aspect and how to recover, I have two pieces of advice. First, people forget over time. Also, when someone else has the spotlight on them, they will screw up too. Then all will be equal again. Second, don't be an asshole to others when they make honest, learning, mistakes. In fact, you should encourage them unless they just really need a firm kick in the ass. You can over time help change the culture of your team by remembering how you felt when you made an honest mistake. You will eventually inspire people to be better programmers, designers, and human beings.

share|improve this answer
3  
I really like this comment. I've made a few mistakes in my workplace in the past, and while I'm not perfect, I did make a point to learn from them. I went up to my coworker (far senior in this field than I am) and asked what I could do better and she gave me some good pointers. I like to think I'm doing better, now. While it did hurt to know that I messed up, and I felt humiliation, it passes eventually. This is encouraging to me because it tells me I did the right thing, and that this is something that will happen. Especially since this is actually my first job. :) –  Ben Richards Aug 4 '11 at 18:22
1  
Your right that people do forget. I once helped take down the company for a half of a day once on a botched DB upgrade. That was a horrible day, but I'm over it and I think everyone else is too. –  Kratz Aug 4 '11 at 19:57
5  
Nice anecdote and a good point. Of course I'm thinking: Easy for the CEO to say. Didn't invest his/her own money. Someone with skin in the game won't have such a bizarrely detached reaction to a colossal mistake. However if honest they'll recognize they made plenty of smaller mistakes along the way, and learned from each one. The key is to fail quickly, be honest, and choose something new for your next mistake. :) That attitude will be recognized and rewarded at companies that are worth investing your career time at. –  Greg Hendershott Aug 4 '11 at 23:20
1  
@BiAiB Vice-President-- usally means "second in command". –  Jonathan Henson Aug 5 '11 at 14:03
2  
@Greg H: "bizzarely detached?" No, only rational. Someone trying to do a good job who makes a mistake, learns from that mistake. Replacing that person, after they have learned better, with someone else who doesn't have experience is a bad decision. They new guy may have a clean record, but only because he's never tried anything interesting. –  Zan Lynx Aug 6 '11 at 5:50

I've been doing this a long time (15+ years), and I still don't get it right the first time. The best designs come out of an iterative, collaborative process. When you have been working on a design for a while, it is easy to get trapped in thinking that it is the only way that it can be done. A fresh perspective is helpful for seeing the things that you miss.

In order for this to work, the team needs to trust each other. You can't be afraid to show people a design that might be flawed, and need to be able to accept criticism of the design. In turn, the rest of the team needs to understand that flaws in a design are not a reflection on designer. It is an expected part of the design. It is also how the team members learn and get better: from their own mistakes and the mistakes of others.

If you are in a dysfunctional team that doesn't work like this, you have two options:

  1. try to fix the team
  2. find a new team (either internally or at a new employeer).
share|improve this answer

As far as I know, I've always been fundamentally defensible. That's not quite the same thing as being fundamentally correct. Often circumstances change between the time you have to make decision 'x' and the time it becomes clear that 'x' was the wrong decision in hindsight.

It's kind of like preparing your US income taxes. A lot of people think there's supposed to be an answer. There isn't. You have your opinion; your tax accountant has her opinion; the IRS has their opinion.

When I make mistakes, I don't lose anyone's respect. (As far as I know.) I think that's because, in part, I always admit my own mistakes. (In fact, I often find my own mistakes.) Also, almost all significant design decisions have more than one person signing off on them. Any mistakes in those decisions are owned by the group, not entirely by a single person.

As far as admitting mistakes, I think that gets easier as you gain competence and experience. In my experience, the newer you are to design and development, the less likely you are to admit a mistake.

It happens off and on, and it shouldn't derail your career. Nobody in a position of significant responsibility invariably makes correct decisions. In fact, nobody in a position of significant responsibility invariably makes defensible decisions.

But most of the time, you ought to be able to make defensible decisions based on incomplete information. As my daughter would say, "That's just being people."

share|improve this answer

Everyone gets things wrong sometimes. Mistakes are inevitable. Admit freely when you are wrong, learn from your mistakes, and show humility especially if you were initially unconvinced that you were actually wrong.

"Humiliation" should never, ever happen. It is not likely to improve a person's performance at all.

Here at my company we have developed a culture of respect for those people who are still willing to stick their neck out on tough decisions but can admit to being wrong and adjust their behaviour when needed.

share|improve this answer

Have you always been fundamentally correct in the software designs you proposed?

Yeah, I'm a superhuman! Well, of course not.

When you give out some design that was fundamentally wrong, you tend to lose the respect of your fellow team members.

No! If that happens, then there's something wrong with the team spirit.

Everybody makes mistakes. Some solutions turn out to be good, some bad, most something in between. Both successes and failures should be taken as a lesson, by you and by the rest of the team.

The first mistakes may feel bad, but after you've made hundreds of them, it's just like part of the job.

share|improve this answer

It happens to everyone. The main thing is to learn from your mistakes and try not to let it happen again. Also, be sure to admit that it was a mistake on your part. For instance, I once made the mistake of using an inferior Data Access Layer(SubSonic3). At the time I made the decision, I was just wanting to get away from hand crafted SQL queries. So I chose what at the time seemed like one of the easiest to get started with. I wasn't too experienced with DALs either. Well, after resolving a few problems I was wondering why some queries were taking a bit too long and found SubSonic was pulling down entire tables for no good reason.

So, I told my boss, explained I made a mistake, and gave him my plan to fix it. My boss of course wasn't enthusiastic about me making a rather large mistake requiring a few days of pure migration. But, he also made sure I didn't make the same mistake again. He made me create a proof-of-concept project for the next data access layer I proposed to migrate to and we made sure it'd work with our requirements, and that it didn't pull down entire tables. All in all, it was a good learning experience to me and now I'll be sure to make sure a key part of the project meets requirements and doesn't have huge problems.

So basically what you do is this:

  1. Admit you made a mistake
  2. Make a plan to fix it
  3. Make sure your plan will actually work
  4. Make sure again.
  5. Fix it!

If you're not sure how to fix it, do not be afraid to get other team members in on it.

One last thing, relax! Everyone makes mistakes. Very few people get it perfect the first time

share|improve this answer

This is geeky pissing contest stuff, and not a good situation to be in. No one is always right, and there is nothing to be ashamed of if someone comes up with a better way to do it, or if they find a problem with the way you did it.

You need to emotionally divest yourself from your solution, and spend your time trying to find the best solution, then you can be pleased when the problem is solved, even if it is solved by someone else.

share|improve this answer

There is a lot that you are not saying in your question. I can't tell what your setting is for "giving out a design". Is it initial discussion with a peer on your planned approach or is it the delivery of what you hope is final code?

If the former, then there's no reason to feel bad and no reason for your peers to suspect you in the future.

If you are waiting until final delivery to discuss your design with someone else, then I don't blame them for being suspicious of your other work.

Everyone needs to discuss their design with someone else. Depending on the complexity or criticality, you may need to discuss it with multiple people multiple times. Everyone can make a mistake, misunderstand a requirement, or miss a special case.

Mistakes identified early are easier and cheaper to fix. They should be very forgiveable unless you are repeating the same mistakes over and over. Peer reviews make it easier to catch mistakes early.

If you are trying to be a lone coder in a team environment, you are committing the (almost unforgiveable) sin of thinking you are perfect enough that you don't need anyone else's help. The fact that it's a team environment proves that the problem is large enough that no one person is going to understand it all. People have to talk to each other or mistakes will rear their ugle heads way too close to release (or after release).

share|improve this answer

I have always made a distinction between, on the one hand, good or bad decisions; and on the other correct and incorrect decisions. A good decision is one that, in the same circumstances, with the same information, you would make in the same way; a bad decision is one that you would make differently. A correct decision is one that, with the benefit of hindsight and additional information, proves to have been correct; and conversely with incorrect decisions.

It has often been said that the person who makes no incorrect decisions never makes anything. Incorrect decisions are the way one learns. Bad decisions are often exacerbated because the decision maker invests themselves in the decision and tries to retrospectively justify the decision, or prove that it was a good decision after all (the cover up is always more damaging than the original decision).

Most of the design decisions I have made proved to be correct, but I learnt most and advanced more with those decisions that were incorrect. I hope that very few of my decisions were bad decisions, but part of the problem with one's bad decisions is recognising that a decision was bad and accepting the often unpalatable lessons arising from them.

share|improve this answer

As long as they aren't being the "Monday Morning Quarterback." I have no use for someone who sits through all the design discussions without saying anything only to claim they knew it wouldn't work after the fact. You have to be able to take criticism even if it is not put in a constructive context.

Probably one of the best features of the SO site is to be able to take a risk and propose and uncertain solution. This is how you learn. Going through life with a bunch of crap in your head that is wrong, but you've never been told the contray, is true ignorance.

They may know something you don't, but they won't know everything. Get over it, get to work, and get something done. Let them waste time thinking they're so damn smart.

share|improve this answer

Have I always provided good design? No! I strive to do it, I strive to get better, but with each successive project, what I can seemingly always do is look back to what I've done before and cringe at how I missed the mark in some way.

As for someone who has proposed a less than stellar design, I would not hold it against that person if that person demonstrated that he or she was willing to learn from the mistake and was open to the criticism. If I see evidence that the person is similarly striving to become better and has the aptitude to do so, then a bad design proposal is just a learning opportunity.

share|improve this answer

It happens to everyone now and then, so the best thing to do is to figure out why the design was wrong and to learn from that. If it's a lack of knowledge, then the design failure will hopefully give you some new knowledge which you can use next time. Don't let it discourage you, everyone goes through this at some point. It's the best way to gain experience and to catch with a new team/environment.

share|improve this answer

This will happen often. Our industry is changing so rapidly, the chances of never being wrong are effectivly zero.

However, did you push the bad design down their thoats over their objections? That could be why they are overreacting.

If the mistake was massive, of course it will take time to regain respect. If one of your coworkers took you in a bad direction and created problems for the whole team, wouldn't you need him to prove himself more in the near term?

All you can do is admit you were wrong, give credit to whoever was right, and strive to listen better and research options better in the future.

What didn't you consider that made the design a mistake? (Not random example - design an import process to use existing web service that runs row-by-row (code reuse and only needing to change business rules in one place) not realizing that some imports will have millions of records and would take days to finish.) Learn from it and consider those things in the future.

share|improve this answer
1  
Then you just have to work to prove yourself to them in the near term. People make mistakes, it is how they recover from amking them that is important. It sounds as if you didn't have a ll the inforamtion you needed to do the design, perhaps you need to consider doing more thorough research before the next design proposal. When somethign is already in a bad state, it is hard to design to fix all the problems, you focus on some but the more critical ones might not have been as apparent. –  HLGEM Aug 5 '11 at 14:13

There will always be mistakes. To err is to be a programmer. Continue to learn from others on the internet and especially from your coworkers. The only shame here would be in giving up, or burying your head in the sand when it comes to issues like this from here on out.

Put it behind you, put your head down, and do your best. If you're a good programmer, you'll shine through your mistakes.

share|improve this answer

If you're not certain that your idea sits on a solid foundation, you ought to discuss it with a few trusted colleagues before you propose it to the entire company or department. In fact, even if you ARE certain, you should still discuss it with the people you work with and who are most likely to know you the best. They'll help you spot problems early on.

share|improve this answer

It happens to us all at times. Use the first design as a prototype. Find out exactly what worked and what didnt and why. Then you can write a much better final product.

Dont try to justify yourself or get defensive. Admit the mistake and move on.

share|improve this answer

The fundamental problem doesn't seem to be explained: this is a social problem. You can see such behavior in almost every profession: if you make a mistake, and they like "categorize" you in a certain stuff, it's forever. It's a social behavior. Even clever and smart people will tend to follow everybody.

Let me give you an example which has nothing to do with programming: in my previous job, I had forgotten to wash my dishes say once or twice. Since then, all the workers thought I'm the kind of man who never washes my dishes. And now as soon as there's a dirty thing in the sink, it's me (who else could it be).

It's the same everywhere: this is a social behavior, no matter what kind of problem it could be.

You tell me you want honest feedback? The only solution is to quit for another job. If all the people of the team think you not good at your work it won't change any time soon, sorry to say it this way. So look for another job, because you'll never change this kind of (stupid I must confess) social behavior.

share|improve this answer

The key is how do you state your case and what kinds of changes do you make. If you claim to be a programming guru that does no wrong and is more awesome than Jon Skeet, then it is quite likely that at some point you will be taken down for that. The key is how do you present your solutions so that you are able to show that this is a reasonable solution to the problem rather than the perfect solution that shouldn't even be checked.

My best example would be discovering the side effects of having a class be static in a web application where I worked once. I didn't know how badly it would be to have that one instance persist and be shared across all the users of the application but I learned from it and did recover in time. Sometimes it can be that something gets found and major corrections have to be done. I've been in that camp too where I had to sift through a bunch of VBScript to reduce the string concatenations that were causing memory issues where I worked once. I can even remember writing code vulnerable to SQL injections back in 1998 when I was writing a find a customer piece of code that had to dynamically generate the SQL since I had ~20 optional fields in that part of the application.


Perfectionism can be a bit of a two-edged sword here which is how I see that 3rd comment as well as being a way that I am at times too. The bad is seeing that there are all these mistakes and nothing is ever just right. The good is that in getting the best you can, you could well be meeting if not surpassing others' expectations of you. Continuous improvement could well be the PC way to see perfectionism and if kept in moderation, I do see this as a good thing. For all the mistakes made, does your code get into production? Does it get the job done? Those are points to ponder as well as if someone is always fixing something on it or is it good that you want to be great so badly that you'd rather not get anything else done until that is perfect? Practice can be useful to help find the patterns to do the job better. However, there is something to be said for understanding the cost-benefit analysis on going back to make minor tweaks when there are other fires to handle first.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.