When I was a jr engineer at AWS my PR’s went through 100+ comments and 7+ revisions due to poor code quality. The friendly, helpful feedback helped me improve.

Now as a mid-level I tend to ship code in <= 2 revisions with minimal comments.

Here’s how I’m doing it. 🧵👇
1️⃣ I understand why code quality matters.

We read code 10x more than we write it. Our code must be understandable so our team can maintain and add features.

Poorly written code causes PR churn, which results in delayed delivery and can block other team members.

2️⃣ I take on small tasks.

A good PR starts before any code is written. The task should be small, resulting in an easily reviewable PR.

Bad task: UpdateWidget API

Better: split into 4 separate tasks - UpdateWidget model; AuthN/AuthZ; input validation; implementation

3️⃣ I invest time up front to ensure my local development environment is ready to code effectively.

- Pull down the latest code.
- Ensure local builds and tests are passing.
- Configure my IDE to working smoothly.

This saves time and headaches while coding.

4️⃣ I read the existing code.

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

What design patterns are being used? Is there code from GetWidget or UpdateItem that should be reused? Will refactoring be necessary?

5️⃣ I plan my code.

I write skeleton interfaces, classes and methods for my code structure.

I realize I won’t get this perfect, and may need refactoring later. But it gets me started.

6️⃣ I write lots of ugly code.

I try to use decent names. This way I know where things are when I read, iterate and refactor later.

I write automated unit tests. Manual testing during this step is tedious, time consuming, and leaves the door open for bugs during refactor.

7️⃣ I refactor heavily.

This is where I name intelligently. I segment the code into small functions and finalize my class structure. If anything looks weird or awkward, I search for an elegant solution.

This includes the implementation *and* the unit tests.

8️⃣ I perform manual tests after refactoring.

I make sure all the classes are working together properly. I cover basic functionality. I don’t rely on catching granular edge cases with this step - these should be covered by the unit tests.

9️⃣ I prepare and review my own PR before sending it.

I hold myself to a relentless standard. I often discard and recreate the PR with even a single nitpick.

In the summary I include relevant Jira or trouble tickets. I document manual testing steps.

🔟 I listen to feedback with objective self criticism.

I make sure I fully understand a teammate's perspective before addressing their comments in a new revision.

Even if their comment is wrong, I understand that it’s likely due to a lack of clarity in my code.

The above steps will improve your code quality and drive down churn on PR’s. This allows you and your team to deliver software faster.

What are some of your tips to improve your own code quality?

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Curtis Einsmann

Curtis Einsmann Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @curtiseinsmann

12 Nov
From an Amazon tech lead: soft skills I’d tell my younger, jr software engineer self. 🧵 👇
1️⃣ Exude kindness.

The tech world is full of strong opinions. You may perceive people as mean. They’re not. They just want the best outcome.

Resist the temptation to become an unpleasant person. Radiate kindness while holding a high standard. You’ll go far.

2️⃣ Ask stupid questions.

There are a million technologies. You’re not expected to know them all.

Example question: “I don’t understand what those words mean. Can you explain them, or point me to a resource which does?”

Read 12 tweets
16 Oct
I’ve reviewed over 750 PR’s at AWS. As my team’s tech lead I provide insightful feedback and enforce a high code quality bar.

But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment.

Here’s how I review PR’s. 🧵 👇
1️⃣ I understand why code reviews matter.

They're an excellent coaching opportunity. Insightful feedback accelerates learning and growth.

Quality code strengthens readability and system understanding. This is a force multiplier for the team’s long term feature velocity.

2️⃣ I’ve taken the time to learn programming best practices.

I understand principles like SOLID, DRY and KISS.

I’ve read the Clean Code book. I understand the importance of naming, small functions and logical control flow.

Read 11 tweets
31 Aug
My first ever Medium story got 22.5k views in its first 3 weeks.

What I did right ✅ and wrong ❌.

THREAD. 🧵 👇🏽 Image
✅ I had a story to tell.

I did something cool in real life. This is important.

I had a unique journey at Amazon. I overcame my technical incompetency to achieve success.

I wanted to help people overcome similar challenges.
✅ I told the whole story.

People read stories to apply experience to their life.

I was vulnerable. I used quantitative metrics (“80+ comments”). I showed my feelings (“face turned red”).

I provided the mindset I used to overcome struggles. Specific and actionable.
Read 13 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!