A Review of My First Project Review

A Review of My First Project Review

code_review.png Recently, I underwent my first project review at Flatiron School and I wanted to write
about what I thought, what I learned and what I would have done differently. I got
together with one of the bootcamp's cohort leads (not mine) on, you guessed it, Zoom.
The review lasted for a little over an hour, but it felt like one of the most productive hours
I ever had as a developer.

Like many others, I was very nervous at first because I had never been in a situation
where someone is there solely to talk about my project- and code-quality. However,
as you'll see in this post, the review turned out to not be scary. Actually, it was really
relaxed and fun.

I'm gonna talk about what I did to prepare, how the actual project review went and what
I learned from it (and would do differently the next time). Hopefully, for any of you have
haven't had an opportunity like this, this post will be helpful for you.

How I Prepared

"I will prepare and someday my chance will come." -Abraham Lincoln

Preparation is the one piece of time-tested advice that will always maximize your chances
of success. Some of the things I did to get ready included:

  • "Rubber-ducking" through my code
  • Mock-code review with someone else
  • Create "elevator pitch" for my project
  • Treat this review like it's an actual job interview (really important)

The first three points are all related in that they are me going over my project and
understanding it well enough to demonstrate and explain well. "Rubber-ducking" is a
time-less coding technique that I used to help me get a better sense on how things were
flowing in my project. Doing a mock-code review is also invaluable because it is like a
"test-run" of the actual project review. This, along with crafting the "elevator pitch" of my
project, would help me DRY out any code smells and separate any concerns.

I will talk more about the last point a bit later when I talk about what I learned.

How It Went

When the day came and I was finally on the Zoom call with an instructor from Flatiron School,
all the nervousness I had felt up to that point melted away. One of my fears is that I have a
tendency to ramble and go off-topic. This was why I "rehearsed" the review so frequently. I
wanted to shake off any doubt I may have had about my own code because I knew it would
show in my voice and demeanor. I knew my stuff.

The instructor was incredibly kind and was such a pleasure to work with. He was so down-to-
earth that I would sometimes forget I was in a project review. This also helped to calm my
nerves.

There were times when he would ask me why I made choice A vs. choice B in "this part" and
"that part" of the code. He would ask me to purposefully enter invalid data to see how my
project would handle it. (prior experience has taught me to know better than to overlook
error-handling)

One of my favorite moments of the review was when he pointed out a potential bug in my code
as it relates to the class-variable @@all. Though we could see it with our own eyes, he noticed
that if the user wanted to go back to a previous list of options (provided by a mix of method calls
to an API), that option class's @@all variable wasn't resetting to original list of options; it was
bloating and causing the list to be put out to the console multiple times instead of one time.

He showed me how to use various tools to inspect and understand this anti-pattern he was pointing
out. When I realized what he was saying, I was amazed at how remarkably improved my project
was.

By the end of the review, we had gone way over time. But I guess that's what happens when you
have two people highly engaged in something; time goes to the wayside. Anyways, he said I did
really well and had no big issues with my code or my project.

What I Learned

Going back to when I was talking about what I did to prepare for the project review, one of them
was:

Treat this review like it's an actual job review.

Given that this review was done virtually and in the comfort of my apartment, I knew treating this
review like a job interview would help me overcome any potential distractions from home.

At Flatiron School, I get to have each of my 5 projects reviewed by one or more instructors who
are there to help me become marketable in the tech industry. In the tech industry, at an actual tech
job, I'd imagine that there will be time where I'm assigned to work on a project and the day comes
for me to present it to my project manager, the department manager and/ or maybe even the CEO.
One of the most invaluable lessons I learned from this was that if I treat these reviews as seriously
as a job, then I will become job-ready.

In terms of learning anything constructive, here were some things I picked up on:

  • Speak up more clearly so I can be heard and understood
  • Be respectful and let the instructor finish their point (instead of guessing and finishing
    it for them)
  • Keep my points simple and plain; don't overcomplicate
  • If I don't know, say so; honestly is the best policy

I wanna make the most out of my bootcamp-experience and that means getting as much value out
of these reviews as possible. It's not everyday I get to sit down one-on-one with someone else
so they can look at my code and help me improve my skills. Hopefully, given all I've done to prepare
and all I've learned afterward, the second time will be more rewarding than the first.

I hope you all found this helpful. Especially if you haven't done a project review before.

Happy Coding!