Forem: Martin Arista

4 Ways to Review a Pull Request

Martin Arista — Sun, 10 Jan 2021 17:33:17 +0000

Generally, I review pull requests twice¹ a day. Once when I sit down to start the workday and after lunch. I do this because, as a coworker, I don't want to be a blocker for anyone. Also, it gets me back into the work groove when starting my day and coming back from lunch. Lastly, and my personal favorite, I can procrastinate a bit starting my work.

I do get excited to review others' work to see how they solved a problem; I get to learn something new while I'm at it. Here are the top four things I'm doing and looking out for during a review.

The "Just going to throw this out there..." Comment

We all have our own opinions on what the code should do and the correctness. We've all given a "nit" comment but, I want to make sure I'm giving feedback and not telling others my way or the highway.

Always call out your nit
What you'd like to see updated
Why you want it updated

These are the softest of my comments during a review, very take it or leave it.

Were you done with that?

I try to frame my comments as questions rather than direct statements. There could be a requirement I'm unaware of or some bug they were working around. Again, maybe I'll learn something. This could be one of those moments.

Ok, now do it again

We all strive for 100% code coverage, and most times that's a lofty goal that only sets you up for failure². There are two things I expect with new code, anything else is just extra gold: were tests added, and are they more tests than we previously had. It's simple and one of the most effective ways to get people writing tests.

What does this button do?

I am not, and no one should be, a coworker who takes work, tosses it to QA for review, and waits for feedback on bugs. We are a team, right? The last thing I do is walk through the testing steps in the PR description, leave any weird finds I have in the review box. Something a la this:

Image courtesy of Github

✨BONUS APPROVALS✨

Ok so, approvals to me are just as important as reviewing. I like to leave more than just the green check we all are waiting for. Sometimes it's an emoji, like this one 🌭, and other times it's a gif like this one:

i will always celebrate a win for anyone #personalcheercaption

Those are always a favorite and I use gifs more than I'm willing to admit.

What's your Process?

Here is my process and I hope you're able to take something from it. How do you review work? What do you find the most encouraging when receiving feedback? Let me know in the comments!

Footnotes

Anyone can message me and ask for a review. Twice a day, I have a dedicated time to look and check.
One day I'll write something about having tests that cover every single line only ends up meaning you miss more than you intended. It's a hot take, I know. That doesn't mean you shouldn't write tests, please, write your tests.

Goals and More in 2021

Martin Arista — Sat, 02 Jan 2021 19:00:27 +0000

A goal I’ve had for a long while was to write one post every week. It didn’t have to be long or something profound, just something. Anything.

The Challenge

The #challenge I have for myself, write one thing a week, about anything, published every Friday(or Saturday, Sunday, or any day that ends in y. Just get it out!).

My Ideal Outcomes

The big mental hurdle I’ve had with this is what do I write about? Anything. I’ve had a few years of mishaps and broken code that I’ve fixed and maybe someone else could learn from my mistakes? No pressure honestly, I’m not perfect, no one is. Half the time, like when I’m onboarding new coworkers, I wince at my old work and mutter “Do as I say, not as I do.” (Small secret, I make a note to go fix whatever I did wrong and loop it into my next PR.)

This is me now and forever.

Hey, that’s not a bad idea actually. My next post can be about how I handle pull requests, from both myself and from coworkers. It will mostly be an ode to smaller PRs and my awkward OCD.

If anyone wants to follow along, or get started yourself, I'm tagging all these posts with the hashtag #52postproject for easy tracking. And on that note, I’ll end it here (I did mention these might be short didn’t I?).

What are you plans for the New Year? Big or small, what would you like to check off your list of things?

Strongly Typed Identifiers

Martin Arista — Tue, 03 Apr 2018 00:29:30 +0000

This post originally appeared on my blog mrtnrst

Have you ever typed a word so many times it looks misspelled? As someone who types for a living, I tend to have trouble with this. The beauty of a misspelled word in programming is consistency. If it’s wrong everywhere, it’s right- right? However, loosely typed identifiers can lead to problems down the road for both our future selves and other code maintainers.

Starting with Colors

With most UI/UX programs, we tend to work with color, generally stemming from a style guide. Let us consider this function:

This color view can be anything we want it to be but our guide says we can only use the colors given to us. Rather than having to remember an RGB value to create each time, let’s make it easier on ourselves.
With a small bit of setup, we can fix something that is prone to errors. We can utilize structs to achieve this.

This is one of the simple use cases of a strongly typed identifier. The goal of this is to make sure we keep avoidable errors to a minimum.

Graduating to Strings

Another pain point and source of frustration is when strings are used all willy-nilly. For instance, this function here:

A few things could happen when using this function. To name a few: misspelling of the id parameter, finding a different object with the same id or causing a crash when inside the function.

So let us take a second and strongly type these functions. We want to create a struct so we can be explicit and readability is at the highest.

Generics, Structs, and Strongly Typed Identifiers

More wisdom from Edna.Even with the extra struct, both uses still pass the compiler. Do you know why our function still accepts these values? As with all types, a String is a String no matter the alias. How about we change the type alias into something that is unique to that struct?

This is when we implement the protocols RawRepresentable and Equatable and sprinkle in Generics to create this:

As for the usage of this new and improved function:

Voila!

We have now locked up our function and kept the errors at bay. There are many different ways you can keep function associations close and organized. My advice to you is to start with low hanging fruit and keep building.