How to get new Motivation after a bad code review

Question

So i presented my code yesterday...after a lot of hard work i was happy to show it to my colleagues. After presentation all that was left was my projects name. Everything else has to change...

They took a lot of time to explain their point of view but after getting back in my place i was really disappointed.

I read mostly all "motivation" related Questions here on Stackoverflow because it is one of my favorite Tags. So my question is...

How to get new Motivation after a bad code review?

Edit: I use Stackoverflow for various questions etc. Not just for "Motivation" Questions and Answers :-)

Answer 1

Post your code as a StackOverflow question, and let some total strangers slap you around instead.

Update: OK, what I initially said was harsh for a joke. In reality, you should consider yourself lucky. For the first 5 years or so of my career, I was the best programmer everywhere I worked, even though I totally sucked as a programmer. Because I was never exposed to any sort of code review by knowledgeable and experienced peers, I constantly went off on ridiculous programming tangents, producing one absurdly overcomplicated, unworkable mess after another. And I did not really get better; if anything, I got worse over time. There is nothing more dangerous and ineffective than a self-styled genius programmer with no one around to tell him what an idiot he is.

By bearing up to a single harsh code review, you probably just saved yourself 5 years of wandering in the desert. Congratulations! You're now ahead of at least half of the programmers out there, and someday soon you'll be able to belittle and embarass junior developers yourself.

And on the bright side, at least they liked the project name. Remember, just like any landing that you walk away from is a good landing, any code review that leaves you still in possession of your job is a good code review.

Answer 2

My motivation is to get rid of the bad code and the thoughts that lead to it. Improving my style of coding is some sort of motivation for me. I feel like I want to prove that I'm better than the result of a bad review.

I think the "Now I'll do it even better" - strategy might be a good way to keep your head up.

Answer 3

It depends partly if you understood and agreed with what was said. If this is the case, then you just got pure honest feedback which isn't often available, you can learn from it, and next time will be able to highlight improvements. A bad review is there to make you better, not grind you down.

Answer 4

Everyone at that code review has been through the same thing: had their code picked apart, had their mistakes held up for scrutiny. It's probably a part of what made them the coders they are. Chances are some of them once made the same mistakes you made and had it pointed out at a review. Someday you'll be reviewing someone else's code and find a problem or two that look rather familiar. Welcome to the club.

I'll leave you with this thought from The Tao of Programming.

There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, "What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure."

Answer 5

It sounds like someone didn't like your implementation rather than the code. There's often no correct answer or best design, so everybody feels like theirs is best.

In any profession, your boss could believe in doing things "his way". Programmers are humans too, and their egos get ahead of them. In your career you will often have good ideas shot down by someone with more seniority. It sucks, but management is not just about talent, as any Dilbert reader knows.

Regarding code, the picture perfect code you see in books and in the various "clean code" manifestos is something that exists in places with enough programmers, relaxed deadlines, and a dash of obsessiveness. Don't get me wrong, clean code is great, and I have worked with programmers quite capable of producing one - if they didn't have to do the job of five people.

Programmers make mistakes. Either their code is ugly or imperfect, or they introduce a bug. Accept the fact that in the next few month you are going to introduce a really evil bug into your codebase. And someone is going to find it. And you're going to catch hell. And the following month, the guy who gave you hell is going to introduce a bug and you'll give him hell, etc. Nature of our profession. Accepting criticism (ideally constructive) is part of programming.

Of course, it's possible that your code was just bad. I look today at code I wrote at 19 and wish my name wasn't on it.

Answer 6

I think it was Tyler Durden who said: "You are not your code."

Answer 7

If your peers showed you real defects and drawbacks in your code - that's alright, it means that someone cares that you do your job well, not just don't break the daily build. In this case apply their suggestions to improve both your present and future code and try not to make the same mistakes again. In fact it's one of the best ways to learn.

Answer 8

Look on it as a learning opportunity. You colleagues probably don't mind pointing out things you could do better once, or maybe twice, but if you keep on producing code which calls forth the same criticisms again & again they will get kinda tired of it...

Also I'd say try to review a little and often, especially if previous reviews have gone badly. Get input as early as you can, and try not to take major design decisions by yourself. It's that old thing that it costs £1 to fix a defect in a specification but £ks to fix it when it's been implemented & found wanting: get the design right before you hit the code & save yourself a lot of work.

And just remember everyone has that sort of day from time to time!

Answer 9

Also there are also some tools that help determine how good (or bad) your code is.. You would still need a good code review by a human :) who obviously has some good experience in developing good software solutions. It is important to remember that these tools are guidelines..

I remember doing a presentation to senior management 3 years back on using these tools. You can find more about it here: link text Most of the tools are code generic (Java, .Net) or have a counterpart ( cruiseControl <--> CruiseControl.Net)

With some good tools and practices (test driven design, unit testing) it will become easier for you to improve your code :)

Of course you are also constrained by what you are working on (like SharePoint makes it difficult to do unit testing and has a server 2003 dependency), deadlines, egos, politics, colleagues (bad ones) etc etc.

It is the intention that counts and as long as you want to develop better and learn from your colleagues and admit your mistakes, you should do very well!

Answer 10

I'd suggest taking their feedback and putting it into various buckets:

• Improvements - What did you do that someone else suggested a better way and backed that up?

• Style - This is where the changes are just, "That's how it is here," type of stuff. How many spaces is a tab? How are variables named? How long can a method be?

• Entertainment - Maybe some of the feedback were wise cracks that should be taken as something humorous to remember and possibly prepare something similar for when you review someone else's code.

I feel like I should give this little story about getting a bad code review as it may help show that you aren't alone. A couple of times now I've had interviews at Microsoft. The first time was horrible. I froze at the white boards and couldn't put 2 lines of code together and after going through 3 different people I interviewed with I feel like I was maybe an inch tall. It was so horrible but what came from that was that I was able to find someone at a recruiting company that gave me some tips and practiced a few whiteboard problems so that the next time, while I still didn't get the job, I could tell that I was much much better than that previous time. We all make mistakes, the question is what do you do when faced with adversity? Do you accept the challenge and improve to conquer it, or do you fold things up and change your career?

Answer 11

The simple answer is to enjoy having your faults pointed out. You now have a wonderful opportunity to improve.

It sounds to me like you are the type of person to prefer the illusion of his own skill, rather than the step-by-step realization that you have much to learn and improve.

Seek out those better than you and if they tell you your code needs work. Then it does. So get back to the drawing board.

That's motivation enough for me.

Answer 12

All of the above - and then some.

Yes, look at it as a learning experience. Just tell yourself, I learned X new things today. Feels good, huh? So long as your peers review the code, not the coder, then np.

But what were they pointing out? Coding style? If so, what? Code didn't match coding style guidelines? Not enough comments? If they complain about speed or wrong algorithm - if it's that important, was it in the design doc?

A lot of people do that and seem to forget that the prime goal of a code review is to ensure that the code implements the design (oh, yes it is!! Let's not have arguments here ;-).

Maybe you got handed a bad design? Gigo? If you did the design, then maybe it was bad system level design?

You don't mention if this is your first ever review (with this company), but it sounds like your problem was leaving it all to the review & having a big bang.

You could have used Splint as you went along (but that doesn't check that code matches design). You probably ought to have discussed it with others, not worked in isolation.

Hmmm, can you ask your boss if you can try pair-programming on your next assignment?

Chin up; it happened to us all, and we are all better developers for it.

Answer 13

What this incident shows to me is that perhaps you should do design with others, and do that before starting to code.

Please correct me if I am wrong, but I would expect that the opinions expressed at the code review, would also have been said at a design meeting much earlier in the process, and would have saved you from quite a bit of coding work.

Also, you may suggest to your peers that code review should be done more frequently, not less. This will make the amount of work to undo smaller and less devastating.

By making the steps smaller, you will have less motivation loss.