
Ask HN: How to be a more diligent programmer - lonesword
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&#x2F;bugs. I&#x27;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&#x27;m not careful&#x2F;diligent enough and let things slip through - this is after my &#x27;careful&#x27; 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&#x27;s a util function for this, or I&#x27;m not aware that there&#x27;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&#x27;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&#x27;m not touching them? Work. Read up on how our deployment works even though I don&#x27;t really have to know it? Not today maybe tomorrow. I love being a programmer so a lack of interest or an &#x27;I don&#x27;t care&#x27; attitude is not likely to be the problem here.<p>Have you gone through similar experiences? How can you be a more &#x27;careful&#x27; 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&#x2F;JS. 2.5 months at new job - python + django
======
wsc981

      ... Desire to be regarded as fast. ...
    

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.

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.

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).

~~~
lonesword
But if something is flagged in code review, it is expected to be fixed if it
concerns code quality. I think as an organization we don't have a habit of
adding code review chores to our backlog

------
mengledowl
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.

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.

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.

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.

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.

~~~
lonesword
"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"

That seems true. Thank you for saying that

