Curtis Einsmann Profile picture
Aug 31, 2020 13 tweets 3 min read Read on X
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.
✅ I wrote the story well.

I established credibility within the first paragraph. I sprinkled credibility throughout.

I didn’t hire an editor. This damages authenticity. I used hemingwayapp [dot] com to ensure a 6th grade reading level.

Spent ~20 hours writing/editing/revising
❌ The story is too long.

Only 7k out of 22.5k people viewing the story actually read it. A 32% read ratio.

Too low. Could be better if the story was shorter. 7 minutes, not 10.
❌ The call to action is weak.

“Follow me on Twitter” isn’t until the end.

Gaining Twitter followers was not the primary goal, but I only gained 200. A horrible < 1% follower conversion rate.

I got 1k LinkedIn connection requests I didn’t want. 😅
✅ I used a strong headline.

“Amazon shouldn’t have hired me. Here’s how I became an SDE2.”

First sentence is controversial. It grabs your attention. It starts with “Amazon” - a well known brand.

Second sentence tells people they’ll be able to learn from my experience.
✅ I used captivating images.

The headline image is making the “Shh” symbol. As if I’m revealing a deep, dark secret. Goes well with the headline. Sparks curiosity.

Halfway, I used an image of myself. Shows humanity, after demonstrating humility and vulnerability in words.
✅ I leveraged existing networks for distribution.

I had < 500 connections/followers on every social. Views breakdown:

LinkedIn - 11k views
FB/IG - 850 views
Other - 6k views

Surprisingly there were 4.6k views from email/IM. I hadn’t emailed it to anybody.
❌ My distribution was not niche enough.

I am a n00b to niche platforms like HackerNews, Reddit and Hashnode. Posting there would increase exposure and read ratio.

Side note: I need to learn how to effectively deal with trolls on these sites. 😅
✅ I didn’t use the Medium paywall.

I wasn’t sure about this decision. It turned out to be a good one (I’m not monetizing).

I didn’t get curated. But this allowed more people access to the story.
✅ I had an incredible learning experience.

I’m incredibly happy I shared my story.

Hundreds of people messaged me across different platforms about how much I had inspired them.

Can’t wait to write again!
From Amazon impostor to leader, my story: medium.com/@curtiseinsman…

• • •

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!

PDF

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 @einsmanntech

Jan 8, 2023
Pull Request templates are useful: they set the expectation for how much context PR authors should provide in the description.

This simplifies code reviews and helps the team ship code faster.

Here's the one used on my current team, for example. Nice and simple: A screenshot of the Pull Request template used on my current
The WHAT should be a brief summary of the change at the *product* level.

The WHY should describe the problem, and why the change solves it. It can also be used to justify the chosen approach.

Each team is different, but generally, these two sections are essential. A screenshot of the PR template used on my team, highlightin
Screenshots are optional. These are useful for showcasing changes that have an impact on the front end of the website.

Test plan is optional — contains manual procedure for testing scenarios that are difficult to cover in the automated tests. A screenshot of the Pull Request template used on my team, w
Read 5 tweets
Nov 29, 2022
Recently spent a week in Miami at Dev Writer's Retreat. Lead by @swyx (the legend!), ~40 developers came together to grow our writing and blogging skills.

🧵 of a few takeaways:

🔑 Illustrate your ideas
🔑 Leverage constraints for volume
🔑 Build trust with public narratives Me and Shawn
🔑 Illustrate your ideas.

As the saying goes, a picture is worth a thousand words. Visuals stick in your brain, and are easier to digest and share.

A lot of code reviewers got immediate, actionable value from this image on Twitter and LinkedIn:
🔑 Leverage constraints for volume

Shawn gave us a challenge: pick a prompt, and write a blog post in 15 minutes.

The time constraint:
- Removes writer's block
- Forces you to limit scope

I surprised myself with 233 words — could turn into a decent post, with minimal editing. A screenshot of an in-progr...
Read 6 tweets
Oct 18, 2022
Generally, you shouldn't make product decisions as a consequence of engineering decisions.

Business features and tech stacks don't always integrate smoothly. This creates constraints — and software engineering is about overcoming these constraints with creativity.
Often, creative solutions result in added complexity.

This complexity makes systems more difficult to maintain. Good engineers use abstractions to hide complexity behind a simple interface.
Though, we shouldn't embrace *all* complexity, and implement *all* features product managers push for.

Every feature has a cost, including complexity: time, maintenance, overhead

As engineers, we understand that cost better than others, and must transparently communicate it.
Read 5 tweets
Feb 15, 2022
A common mistake of developers new to a "tech lead" role: trying to perform every code review. They're concerned that something will break if they don't.

But reviewing every pull request isn't feasible, and doesn't scale.

What to do instead? Here's what I've learned: 1/8
Enhance your delivery systems outside of code review.

Strengthen your release pipelines with tests, monitoring and rollback. This will help to prevent, detect and mitigate defects. 2/8
Document code review processes.

Team members should be aware of the expected size, scope and structure for each PR. Add automated checks for testing and approval. 3/8
Read 9 tweets
Jan 18, 2022
Software engineers engage in code reviews daily.

But most developers can’t recognize a bad code review process. Even when they're right in the middle of one.

Thread: 3 signs of bad code reviews, and how your team can ship faster. 🧵
🚩 If code reviews make you, or other developers, anxious.

Likely, reviewers aren't prioritizing kindness. Or they're on a power trip, gatekeeping over minutiae.

Result? Deteriorating relationships.
🚩 If it's common for one pull request to go through many review cycles — maybe even 7 or more.

Likely, reviewers are giving ambiguous feedback. Authors don't have a clear path forward, and go down rabbit holes between reviews.

Result? Discouragement, and wasted time.
Read 14 tweets
Jun 17, 2021
I’ve authored over 550 Pull Requests at Amazon Web Services.

In the past year, I shipped 90% of my PRs in 1 revision. 5 years ago, it often took me 6+ revisions to address peer feedback.

Here’s my step-by-step process to author and ship a quality Pull Request. A thread:
1. I understand why fast PR cycles matter.

PR churn can cause delayed delivery.

It can block my teammates from being effective. If they have to review my PR through several revisions, they have less time to focus on their own tasks.
2. I understand that occasional PR churn is inevitable.

1-revision PRs won't always happen. Humans make mistakes. Peers have unique insights. That’s why code reviews exist.

Particularly, early-career developers at {BigCompany} often need coaching. Even the best programmers.
Read 17 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

Don't want to be a Premium member but still want to support us?

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

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(