Tech IndustryJun 14, 2019
Newgooglelee

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

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

Add a comment
Facebook hurrah Jun 14, 2019

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.

Oracle sofakinghi Jun 14, 2019

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.

Amazon Waze Jun 14, 2019

Do you still do this if the diff is huge?

Oracle sofakinghi Jun 14, 2019

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.

GoDaddy Ofj47e Jun 14, 2019

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

Facebook hurrah Jun 14, 2019

That's true. You have to pick your battles, sometimes lint errors and refactoring are things you compromise on

Rally Health PWcK47 Jun 14, 2019

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.