I had the opportunity to attend KCDC 2019 for the first time as a Crema employee in July. I gotta say 1) I was stoked, 2) I was right to be stoked. It was great to experience being a part of the local development community. It's a supportive community with great people who keep it accessible and inclusive.

The conference itself was easy to navigate and well organized. It's a tech agnostic conference with something for everyone. For several of the time slots, it was hard to pick a single talk to attend! The conference also thoughtfully included a good number of quality human skills talks.

The human skills talk that I found to be the most relevant was "How to Have Code Reviews Developers Actually Want". The speaker, Cameron Presley, delivered the content in a practical and engaging way. His talk reiterated the idea that the goal of a code review is to assess quality, readability, and maintainability. Code reviews also should enforce style consistency. Remember though that the desired result is to solve the problem at hand, not to have everyone's code look the same. Differentiate between opinionated interjections and teachable, applicable moments.

The talk outlined that code reviews always should do the following:

They should be respectful. Keep in mind when commenting that someone worked hard on that code.

They should reinforce joint ownership. Go ahead and "we" all over yourselves.

Code reviews are an important part of ensuring code quality, and we're all responsible for quality, regardless of role or title. Code reviews also have great potential to be mentoring moments. You are not only preventing problems, you are also helping a developer improve their skills. So, when you provide comments, provide context. An example would be to say something like, "When X occurs, we should do Y, because Z."

Something that hadn't occurred to me prior is that you don't have to do a code review only when your code is complete. I tend to not want anyone to see my code before it's pretty and sparkly because, well, #impostersyndrome. In reality, sharing your code as it's written improves your code as you go, instead of requiring you to do a massive brain upload all at once at the end. You can also @ someone with specifics to point out exactly what you'd like them to provide feedback on.

Some other useful guidelines:

• Do no more than 60 minutes of code reviewing at a time.
• Try to keep reviews under 400 lines of code - anything more is hard to conceptualize.
• Try to spend about 30% of your time on code reviews.

Thanks to the organizers of KCDC, the speakers, and everyone who participates in the community for an incredible space to learn and get to know my fellow developers!

See you all at KCDC 2020!