How to increase my sense for code quality during sprint (and in general)?

New / Eng googlelee
Jun 14 9 Comments

Once I finished a ticket , I'm eager to push it. I'll make small improvements here and there but the code is as it is. In a lot if cases though I get lots of improvement suggestions during code review (actually it's about two or three - but I feel it's two or three too many). And most of them I know myself and could have implemented like this if I had taken more time to consider my code.

It happened multiple times already. But it's like my mind shuts down and is this thinking about the next task already and forgetting everything about the current ticket once I created working ( but not optimal) code.

Why am I doing it and how can I help myself getting rid of the urge to push as fast as possible? I guess it's a psychological issue

comments

Want to comment? LOG IN or SIGN UP
TOP 9 Comments
  • Oracle / Eng sofakinghi
    I know personally I always check my diff in the terminal to see changes. A lot of times seeing it in different colors helps me distinguish where I could make changes or where I’ve missed something. Don’t know if it will help you but it seems to help in my case.
    Jun 14 4
    • Amazon Waze
      Do you still do this if the diff is huge?
      Jun 14
    • Oracle / Eng sofakinghi
      Yep. I try to push often to keep this problem at bay. However, isn’t always possible. Usually just take it a file at a time if it is larger.
      Jun 14
    • Expedia / Eng RslS72
      Yep. I do similar thing. I review my own code after PR generation as if I am reviewing someone else's. Helps me detect some of the quality points that I might have missed we earlier. And next time, the missed thing automatically becomes part of normal coding and it goes on
      Jun 14
    • Oracle / Eng sofakinghi
      ^this as you continue to do it you start to pick up on your habits and change them while they are happening.
      Jun 14
  • GoDaddy Ofj47e
    Above comments are good: awareness, pace yourself, mental checklist, looking at diffs (I generally diff before each commit, before push to branch, and before opening PR)

    This is gonna sound a bit of an unpopular opinion, but I generally allow my juniors to push not perfect code to prod (but if something is egregiously bad, I'll insist on it being fixed). Sometimes the best way to learn is fixing your own mistakes
    Jun 14 1
    • Facebook hurrah
      That's true. You have to pick your battles, sometimes lint errors and refactoring are things you compromise on
      Jun 14
  • Rally Health PWcK47
    You will see lot of comments on code review earlier but if you note them down most of them are cosmetic and you can create checklist of these and not repeat. Over the time you will see people who only look for particular cosmetic things disappear from commenting on your code and now they have to actually understand logic and make educated comment. Also if you receive good comment and design suggestions you should be happy because that's the true learning.
    Jun 14 0
  • Facebook hurrah
    It's good that you are noticing this about yourself. Admitting the problem is the first step.

    What I do to Pace myself and ship quality code is not send out a code review for 24 hours after I have finished coding. If gives me time to mentally review my code for bugs and quality.

    Another thing to do is to make a list of checks that you should do. Each company has a different set of lint rules and it takes time to actualize them.
    Jun 14 0