After 2 spending 2 years in an enterprise software firm, I left for a startup. The new gig is an eye opener. I get a LOT of code review comments. While some were about styling and conventions and I no longer make those mistakes, others are more about design/bugs. I'm glad that I have someone who reviews them and gives me constructive feedback. What concerns me is that I repeat some mistakes and I often get the feeling that I'm not careful/diligent enough and let things slip through - this is after my 'careful' self review of my pull request.
Some of the issues I struggle with:<p>1. Missed use cases. Goal was to do X when Y is the input. But I forgot that Z also could be an input.<p>2. Passing around entire objects between methods instead of just their id in the db<p>3. Not using existing util function. I either forget that there's a util function for this, or I'm not aware that there's a util function for this.<p>4. General lousiness. Missing to mention all params in the docstring, and similar stuff<p>5. Desire to be regarded as fast. I see an existing method that could be refactored - I skip refactoring it because my priority is to ship my feature <i>right now</i>. In another instance, I copied a few existing methods to my new class because moving them to an abstract class and then re-using them would have been too much work, since I might have to fix the tests as well. There's no pressure on me to work faster from any stakeholder<p>6. A general tendency to minimize work. Refactor existing methods even though I'm not touching them? Work. Read up on how our deployment works even though I don't really have to know it? Not today maybe tomorrow. I love being a programmer so a lack of interest or an 'I don't care' attitude is not likely to be the problem here.<p>Have you gone through similar experiences? How can you be a more 'careful' programmer? Any systems that you use? How do you review your own code?<p>Thanks a lot for your time<p>Context: 2 years of java/JS. 2.5 months at new job - python + django
<p><pre><code> ... Desire to be regarded as fast. ...
</code></pre>
I assume you work with sprints and some points have been assigned to some user story. In my opinion it's good to generally first find the quickest solution that gives the expected result and then, if time is left, improve the code quality. If there is not enough time to properly finish a feature (i.e.: write good quality code), with good quality code, add a user story in the back log that explains the refactoring to be needed.<p>I guess in general this is also the way to go when you see other code, unrelated to the feature you are working on, that needs some major refactoring. Because at the end of the sprint you still want your own user stories completed.<p>You need your PM to understand the need for the refactoring, so you can dedicate the right amount of time and it gets a high enough priority in the backlog (some PM's might only want to focus on new features).
A lot of this comes with experience. 2 years is not a very long time to have been doing this. The longer you spend time in this sort of environment, the more things you'll learn and start to pick up on without necessarily needing to be told.<p>This goes for missing things as well as seeing refactoring etc as "work" - I used to think that too, but I've seen that as people gain more experience, that mindset tends to shift. Over time, you'll realize that it's better to refactor now than later when it will be much more painful. And if you're anything like most devs I know, you'll eventually begin to really enjoy refactoring because of how much more elegant you can make the code. There's something so rewarding about seeing a spaghetti string of code turn into a beautiful work of art before your eyes.<p>Another thing I'd like to note that I think is really important here is that having others review your code is a powerful tool. Even after many years of experience, I still get lots of comments on some of my PR's and you know what? That's my favorite thing to see! It took me a few years to realize that getting comments didn't mean that I was doing a bad job, it just meant that someone had caught something and there was something I could learn! In fact, I start to get nervous when I don't see people commenting on my PR's because it means that I'm shipping code that could have probably been improved.<p>It's also not just "smarter" or "better" programmers who are able to leave good, thought-provoking suggestions/thoughts on a PR that help the author learn something and improve their code. I've had juniors leave comments that taught me something or reminded me of something that I've missed, and I've also reviewed my manager's code many times and explained something that he didn't know - and he's told me the same thing about having reviewed HIS manager's code years ago.<p>The fact that you're already trying to be careful and diligent is awesome, keep that up. Just don't feel like you're not doing a good job just because you're not catching everything - that's the whole point of the code review.