Skip to content

Code Review #6 – ‘Too smart’ aka scared of being dumb

One of the biggest failing junior developers have is that they are too ‘smart’. ‘Too smart’??? How can someone be ‘too smart’? Actually pretty easily.

‘Too smart’ is when the person spent hours looking at a problem. And the next day she/he

  • realizes the specs would require violating the speed-of-light;
  • or has the product manager come up to them and say, “Oh yeah, there was a typo in the spec and it should have said ‘… NOT …'”;
  • or the product manager/tech lead (when asked) says, “that’s not what I meant”;
  • or the product manager/tech lead (when asked) says, “I didn’t consider that case” (or don’t worry about that case now);
  • or is told by a fellow developer, “oh I ran into that problem last week and on the 3rd page of the documentation, a workaround solution to that problem is described.”;
  • or discovers they were working on an old version of the code and upgrading to the latest version of code or libraries, solves the problem;
  • or finally another developer looks at the problem and points out a simple condition that has been reversed;
  • or…

In all cases, the person (doesn’t have to be a developer) violated the 20-minute rule. Quite simply the 20-minute rule says

“If you are stuck for more than 20 minutes, and you are no closer to understanding the source of the problem – then ask for help”

Yes, it could be something ‘stupid’ but it could also be something else. Sometimes you will be told to keep on looking because the person in question wants you to learn something. But sometimes there is a fundamental misunderstanding.

So to make sure that you are not asking for help too easily there is the corollary to the 20-minute rule, the 10-minute review rule.

Spend 10 minutes reviewing, how you got to this situation.

  • Describe why the previous code is written the way it was. Notice this is not a ‘what’ question. So do not answer ‘what the previous code was doing?’ Answer why did the previous developer did the code this way – do you know how the code is being used? Are you breaking those assumptions?
  • Describe why the previous code is now incorrect. List the changed assumptions or requirements.
  • Describe what your solution is going to accomplish.
  • Describe why your solution is the minimal solution.
  • Describe why your solution is the correct choice.
  • Describe the single problem that if solved would make your solution work correctly.

At this point, one of these choices is the path that needs to be taken:

  • Fundamental misunderstanding about existing code. You realized your initial assumptions were wrong and that your solution is the wrong path. Solution: STOP and look at reevaluate problem discarding old assumptions.
  • Missing information. The problem was not specified clearly enough. There are multiple possible problems that are being asked to be solved. Solution: get clarification. Do not proceed until the problem has been clarified.
  • Reinventing wheel. Has this problem already been solved somewhere else in the code? If so, refactor so the already created/tested solution can be used.
  • Rathole. A simple problem is becoming more and more complex. Are you fixing the problem of the problem of the problem that you started off solving? Are you making changes all over the place? If you are in a rathole, this is a sure sign of Doing-the-wrong-thing. Solution: STOP!
  • I don’t know If you don’t know, then you need to ask for help. Solution: Swallow pride and ask for help.

Posted in code review, management, technical.

One Response

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Konstantin says

    Very very useful. Thanks.

Some HTML is OK

or, reply to this post via trackback.