
Ask HN: How to make sure my code requires fewer changes when reviewed by a senior - juniorSE
I&#x27;m a junior SE at a startup;  most of the time, my code requires quite some changes during the code review process. It really frustrates me and make me feel like a fraud. 
From your experiences, how can I make sure that my code is solid enough that it does not require too many changes when reviewed by a Senior Engineer. Any advices, and book recommendations are welcome. Thanks
======
dozzie
> I'm a junior SE at a startup; most of the time, my code requires quite some
> changes during the code review process. It really frustrates me and make me
> feel like a fraud.

You're _junior_. You still learn. Your code is _not expected_ to be good until
you get more training, and then you'll no longer be junior.

> From your experiences, how can I make sure that my code is solid enough that
> it does not require too many changes when reviewed by a Senior Engineer.

This is something you should be asking your reviewers. We don't know what you
are lacking, as we haven't seen your code.

~~~
spoonie
Yup! You could also try asking your reviewers to write out some coding
guidelines. You can refer to these as a checklist before putting your code up
for review.

Or if you are really adventurous, start making this document yourself as you
get feedback. The guide can includes things like coding style as well as
mistakes to avoid "prefer do loops over while loops", "always check for nulls
after $API_CALL". (As a bonus here, you will make mistakes in your doc and
you'll get additional feedback: more learning opportunities.)

------
shubb
I don't think this is a problem you'll solve with books.

To some extent code is a matter of taste, and good taste is more important
than you'd think.

You need to talk about each change and figure out what is driving it. Why was
it wrong in that place when it was right yesterday. Figure out the general
rules they are trying to follow and try not to make the same mistake twice.

I know it's frustrating and demoralising but please view it as mentoring. In
this industry, so many juniors never get the experience your getting and never
learn how to code well. Please stop viewing changes as a personal failure.

If you are getting many corrections you might want to slow down a bit.
Properly test before committing and give the code a read through as if you
were reviewing it.

You don't say what kind of changes they are making. You need to figure out
patterns there.

If your senior is being an ass that's different. There are bullies in every
walk of life. If that's the case try to keep them sweet.

When I was younger and felt more experienced devs were getting at me, I often
realise they meant well but were bad at communicating and particularly
imagining the situation from my perspective on order to spot gaps in my
knowledge. Ask them to pick out and talk you through how they would improve
your code for an hour a week?

In terms of avoiding getting people mad, mistakes are fine but repeat mistakes
are not, so really focus on not needing the able correction twice.

------
gregjor
I've been reviewing code for a long time, and I've had lots of my own code
reviewed. You have to learn to accept code reviews as mentoring and learning
and striving for consistency across the team. If you think of reviews as a
contest of egos or a test to pass you aren't getting the most out of it. Most
juniors now days don't get the opportunity to have a more experienced
programmer review their code.

Main problems I see when reviewing code:

1\. Doesn't meet requirements, or requirements not understood. If you aren't
clear on what you're supposed to deliver before you start coding you need to
ask questions. Make a plan, identify intermediate goals, have someone else
validate your approach.

2\. Over-engineering. Solve the problem assigned. Don't create more problems
or try to plan for every eventuality. Prefer simple, understandable solutions.

3\. Not tested. Test carefully. Then test again. I don't mean just making all
the lights green in TDD. You should go test carefully and make sure you see
expected behavior according to requirements. Think about edge cases. Build
testability, logging, etc. in from the start.

4\. Sloppy work. Read your code. This is called desk checking. Review your
code before someone else does. It's surprising how many obvious errors you can
find just reading through code.

5\. Idiosyncratic style. If your team has written standards, follow them. If
not propose that the team define and follow some standards. In lieu of that
make your code look like what the senior devs produce. Lots of time is wasted
resolving disagreements over things like indenting and variable naming.

If you have the luxury of code reviews keep notes about what your reviewer
asked you to change. Determine if the issues are style, efficiency, lack of
testing or sloppy work, or misunderstood requirements. Change your approach,
and talk to the team if you think there's something everyone can do to address
the issues.

------
tedmiston
I've reviewed a lot of code. The three biggest things that help junior devs
(really every dev) produce better quality code for code reviews are:

1\. Use a linter. For example, eslint in JavaScript, and pycodestyle (formerly
pep8) in Python.

2\. Use an automated code quality service. Most have an open source free tier.
The ones I know of are: Landscape, Codacy, and Code Climate. You can see a
trivial example of their buttons (click through for reports) on my one-file
repo here [1].

3\. Read more advanced books to learn the more advanced patterns. Software
engineering quality is mostly about using abstractions and paradigms well.

Also, keep in mind: Always aim to be consistent with the existing codebase
even if it goes against your personal style or beliefs. Consistency makes it
easier for a team to actively develop together. If your team has a style
guide, know those conventions; if they don't, default to best practices per
your framework / language.

Another thing you can do is read and study code written by very experienced
devs. Think of things like your framework itself or the standard library of
your language. You'll learn more advanced features there as well. There is
plenty of role model code in the wild.

[1]: [https://github.com/tedmiston/tag-
brain](https://github.com/tedmiston/tag-brain)

------
bjourne
1) Never rush. Take as much time as you need to solve a task. Ensure that the
code you have written is as good as possible. It should be "almost perfect."

1b) You write "solid enough" which is the wrong goal if you want to improve.
You must strive for perfection because that gives you the most skill
improvement per unit of time invested.

2) Write down what criticism your code is getting. Try and extrapolate. For
example, if your code causes a NullPointerException on certain inputs, see if
you can figure out why you made that error and what you should keep in mind to
not make it in the future.

3\. Seek input from people more experienced. Like on Stack Overflow, the
sister site Code Review
([http://codereview.stackexchange.com/](http://codereview.stackexchange.com/))
or among colleagues.

4\. Never give up. And practice, practice, practice!

------
bbcbasic
You can't. I am a senior who still gets things flagged at code review. It's
not an exam, but a form of quality control. Best to ask the reviewer why each
time. Decide if you agree with them. Sometimes it is a matter of taste as
someone else said.

Learning SOLID etc will go some way to help.

------
budman1
Make a list of the things that are unacceptable. See if you can extract out a
few 'themes' that exist.

Are the problems in coding; like comments and spacing and variable names. If
so, make a check list for yourself and make sure that you correct these prior
to the review.

Are they design? Read up on doing design prior to writing code, and attempt to
create a design up front that is more palatable to those above you.

Is the problem requirements or domain knowledge? Look up "requirements
engineering", there are a lot of techniques to use to assist in understanding
the problem domain and the software requirements.

TLDR. write down the problems, identify the root cause, make that better.

------
psyc
Continue learning. There's nothing you can do _right now_ to stop seniors from
spotting problems in your code. That's completely normal. In the meantime, you
can change your attitude. It's not supposed to make you feel frustrated or
like a fraud. It's supposed to be both a quality gate and a learning
experience. Any ego on either side of a code review makes it a worse
experience.

------
bsvalley
There is nothing much to do besides leaving your current environment in order
to find a more flexible place, where you'd get more responsibilities even as a
junior. What they don't tell you in college is that the organization in a
professional environment has 2 extra layers of micro-management. It goes like
this:

1- CEO

2- Expensive Senior management

3- Useless Middle Management

4- Babysiter Managerment (your direct report)

5-- PM's (product and project managers)

6-- Annoying colleagues who grab whatever authority is left from the previous
layers

7- you

