How I craft beautiful code that gets approved on the first review

Photo by Johnny Magrippis on Unsplash.

I understand why code quality and fast review cycles matter.

We read code many times more than we write it. Our code must be functional and readable, so our team can better maintain it and add features.

I take on small tasks.

The process starts before any code is written.

  • UpdateWidget API
  • ✅ Database model
  • ✅ API request model
  • ✅ Data Access Object (DAO) implementation
  • ✅ Auth
  • ✅ API implementation

I prepare my local development environment.

I pull down the latest code. I ensure the tests pass. I configure my IDE to work smoothly, without false warnings.

I read the existing code.

Before implementing UpdateWidget, I observe the codebase to understand the current paradigm.

  • What design patterns are present? Can they be leveraged?
  • Are there any important conventions I should uphold?
  • Is there code from GetWidget or UpdateItem that should be reused?

I plan my code.

I write skeleton interfaces, classes and methods for the abstractions that define my code structure.

I write lots of ugly code.

I try to use decent names, but only spend a few seconds on them. They help me keep track of things when I refactor later.

I refactor for readability.

This is where I finalize my class and function abstractions.

I perform manual tests after refactoring.

I make sure all the classes and functions are connected properly.

I review my own draft code review before opening it.

Not in my IDE — in an internet browser. This gets me into “review mode.” The change of environment helps me read my code with more scrutiny.

I include the why in the code review description.

This describes the problem solved by the change.

  1. Why is the problem worth solving?
  2. Why did I choose to solve it this way?
  3. Why did I choose the tradeoffs I did?

I include the what in the code review description.

The what describes the enhancement or fix introduced by the change.

  • Related tickets, PRs, issues
  • Test coverage
  • Screen captures
  • Rollback safety
  • Backwards compatibility

I listen to code review comments with a radically open mind.

Feedback is inevitable. I embrace it from my peers — including the nitpicks.

Bottom line: I take pride in my code.

I focus on what I can control: writing great code, and opening a clear and unambiguous code review.

Like this article? It started on Twitter. Follow me for more! Here’s an example of what to expect:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Curtis Einsmann

Curtis Einsmann

Software engineer; solopreneur. Writing to help developers level up. All stories free. Follow me on Twitter for more: