Master Technical Writing: 7-Day Workflow to Accelerate Your Data Science Career | Eugene Yan
Listen to or watch on your favorite platform
Show Notes
How can technical writing accelerate your data science career in just one week? In this episode, Eugene Yan — an Applied Scientist at Amazon who previously led data science teams at Lazada and uCare.ai and writes about ML in production and career growth — walks through a practical, repeatable 7-day workflow for technical writing tailored to data scientists.
We cover Eugene’s career transition and first public writing, motivations for sharing work, and how to target readers (peers, future teammates, and hiring managers). He frames writing as a product with a weekly shipping cadence, explains the outline-first method for filtering ideas, and outlines a realistic time budget and editing limits. You’ll get concrete guidance on idea sourcing, title crafting, article length, blogging tools (Medium, Substack, WordPress, Jekyll), writing habits, distribution via Twitter and LinkedIn, and writing at work (press releases, design docs, decision logs). Practical portfolio advice — clear README, quick start, repo tour — and tips to iterate outlines and ship weekly round out the episode.
Listen to learn a concrete 7-day workflow, documentation and portfolio best practices, and distribution tactics to boost your technical writing and advance your data science career
Today we’re discussing technical writing, logging, documentation, and more. Our special guest is Eugene Yan. Eugene works at the intersection of machine learning and product, building pragmatic ML systems while writing and speaking about effective data science, ML in production, and career growth.
Here’s what we covered:
- Eugene’s journey from psychology to Amazon Applied Scientist
- Why technical writing matters for career growth
- Eugene’s proven 7-day writing process
- How to find ideas and craft compelling titles
- Practical advice for starting your own blog
- Writing strategies for work documentation and portfolios
From Psychology to Data Science: Eugene’s Writing Journey
Q: Before we dive into technical writing, can you tell us about your career journey? How did you transition into data science and tech?
Eugene: It’s a bit unusual. I graduated about ten years ago with a psychology degree and spent a few years in investment policy. I didn’t enjoy it—I was writing a lot of contracts and agreements—and wanted to work more with data. I took 20-30 MOOCs, interviewed, and was fortunate to join IBM. While there, I entered a product-classification competition; my team placed in the top 3% and we shared our approach at a meetup. An e-commerce startup with a similar problem was in the audience and invited me to lunch to discuss solutions across multiple languages (Vietnamese, Indonesian, English). The next day they offered me a job. I wanted startup experience, so I joined as their third data scientist. That startup was Lazada. A few years later, Alibaba acquired us. I then moved to a healthtech startup (which didn’t work out), and now I’m an Applied Scientist at Amazon in Seattle, working on recommendations and ML systems. So if anyone says Kaggle is a waste of time—well, I was very lucky, but it helped me.
Q: You’re known for publishing regularly on your blog. When did you start writing publicly, and what motivated you to begin?
Eugene: My first post was in September 2015—a report for DataKind, an NGO project accelerator. They asked for volunteer writers; I volunteered because I wanted to practice writing. That leads to the “why.” Early on, I interviewed data scientists and leaders I admired—people two to three steps ahead—and asked, “What skills make someone effective?” I expected answers like domain expertise, ninja hacking, or PhD-level research. Instead, ~80% said: communication—writing and speaking with non-technical stakeholders so things actually happen. I thought they were kidding, but I tried for a year: any chance to write, I wrote; I also gave my first meetup talk (on that competition). Many good things happened, so I kept going.
Why Write? Sharing, Learning, and Being a Lighthouse
Q: Writing consistently takes a lot of time and effort, and the rewards aren’t always immediate. What keeps you motivated to publish regularly?
Eugene: I reflected on this at the end of 2020 and realized my main reason is to share. I publish how I cleaned Amazon data, how I deployed an API, summaries of Georgia Tech OMSCS classes (people asked which courses and professors were good), and conference notes to spread learnings. When others find it useful, it motivates me. I also write to learn—you think you understand something until you try to explain it. Writing exposes gaps and consolidates knowledge. I’ve used this for topics like NLP surveys (from RNNs to BigBird), data discovery platforms, and real-time recommendations. Finally, I write to be a lighthouse—to broadcast what I’m interested in so like-minded people can find me, discuss, and learn together. Publishing draws thoughtful feedback and conversations—even with people I’ve long admired—which is humbling and energizing.
Q: You mentioned writing as a “lighthouse” and having specific readers in mind. Who is your target audience?
Eugene: The lighthouse is a signal—I’m broadcasting what I’m interested in, so if you’re interested in the same things, you can find me and we can talk. It’s about attracting like-minded people.
I write for three groups: myself (so I benefit even if no one reads), my wife (to explain what I do), and my current and future teammates and like-minded peers (people with technical or ML backgrounds who want to level up). Some pieces get less traction—like “writing vs. coding”—but I still publish them because they matter to that audience.
Q: Do you approach each article like you’re building a product?
Eugene: Absolutely. If readers don’t “get it,” the UX is bad; if there’s no substance, the backend is weak. I ship weekly to accumulate reps—50+ “product” iterations a year. In five–ten years, I hope to deliver the same clarity in five hours instead of twenty.
The 7-Day Writing Process
Q: Let’s talk about your actual writing process. How do you go from idea to published article?
Eugene: I’ll start with the wrong way I used to think about it: sit at the computer, type, and something beautiful appears; it must be 100% original and 100% useful. That mindset makes writing nearly impossible. Now I remind myself I write to share, to learn, and to be a lighthouse. Writing doesn’t start with writing—it starts with reading, thinking, and note-taking. It doesn’t have to be perfectly original or useful.
When an idea pops up—on a walk or from a tweet—I drop the title into my notes. That backlog has ~50 topics. Then I follow a simple weekly cadence: seven days, publish every week no matter what state it’s in.
- Day 1: Pick a topic and draft an outline—big sections and key points (e.g., for real-time recommendations: why not, when useful, what it looks like, and how to build an MVP). Takes ~2 hours.
- Day 2 (and maybe Day 3): Rewrite the outline from memory. This strips away weak ideas and keeps the best. If needed, repeat this outline-only iteration for a few days.
- Day 6 (Saturday): Write the prose from the detailed outline. It’s basically translating bullet points into readable paragraphs and adding images.
- Day 7: Sleep on it, then do a final pass: reorganize ideas, paragraphs, and sentences, add or adjust images, and publish. I might tweak on Monday or Tuesday if feedback comes in, then I stop.
The key is iterating on outlines, not prose. I’m slow with sentences and wordsmithing, so I spend 50–70% of the time on the outline where I focus only on ideas.
Q: You emphasize iterating on outlines rather than prose. Can you explain your outline technique—what does it look like, and why do you rewrite it from memory?
Eugene: Section headers plus a topic sentence for each paragraph, with supporting evidence bullets. In later stages, the outline is essentially the content—just not in paragraph form. That makes prose a straightforward translation step.
The memory rewriting is key—it’s like telling a friend what a book was about: you recall only the most important parts. This filters for the strongest arguments. Then I compare with the previous outline to see if I missed any truly essential points. If I couldn’t remember it, maybe it wasn’t essential. I don’t do this every day—if I didn’t finish the outline, I continue. If I finished but I’m not satisfied, I rewrite from memory. If I am satisfied, I start prose earlier and give myself a lighter weekend.
Q: You publish weekly, which seems like a fast pace. How much time do you actually spend writing each article?
Eugene: I’m actually a slow writer. Roughly: 1–2 hours each weekday morning (~7 hours), weekends ~13 hours, plus ~5 hours for final editing—about 25 hours a week. Iterating on outlines makes that feasible.
Q: With all that editing and iteration, is there a point where you can over-edit and actually make a post worse?
Eugene: Yes. My hard stop is Sunday night—I must ship. Over-editing can regress quality. That’s why I iterate on outlines, not prose. I compare outline versions side by side: which tells the story more clearly? For prose, I’ll rewrite a paragraph above the old one and compare. My success metric: is it shorter while preserving all key ideas? If the new version is longer and muddier, I revert. Think of it like regression testing.
Finding Ideas, Choosing Topics, and Crafting Titles
Q: Where do you get ideas for what to write about, and with a backlog of ~50 topics, how do you prioritize which one to write each week?
Eugene: Ideas come from three main sources:
- Frequently asked questions. If people keep asking—e.g., “How do you run Scrum for data science?” or “How did you move from psychology to data?”—I write it once so it can scale.
- Thoughtful disagreements. If I see a take I disagree with (e.g., hyper-fragmented data science roles), I’ll present an end-to-end perspective and explain why.
- Refocusing on what matters. People ask if coding is everything, or if reading papers is pointless; I argue that writing and reading matter more as you progress.
For prioritization, my simple trick: readers of my site love ML, but I can’t (and don’t want to) write only ML every week. So I aim for one or two ML posts a month, then mix in pieces I feel are important—for example, why you shouldn’t default to online courses and what better learning paths look like. I picture specific readers—my teammates and mentees—and ask: what message would help them become more effective data scientists? That becomes the priority.
Q: Do you aim for a specific article length? Many people say attention spans are short nowadays.
Eugene: I’ve heard ~1,500 words (≈10 minutes) is “ideal,” but I don’t optimize for a number. I write just enough to communicate the message. Some posts are 600–1,000 words; others (e.g., real-time recommendations) need 4–5k to preserve the big picture. I assume my core readers are genuinely interested and will read or revisit as needed. I still try to be as concise as courtesy allows—and weekly deadlines help constrain scope.
Q: How do you approach titling your articles?
Eugene: Like naming functions: the clearest title that no one can misunderstand. By Sunday night I rarely have energy for clever titles, so clarity beats clickbait. That said, framing for the audience matters—e.g., “The Importance of Writing in a Tech Career” beats “Blogging and Technical Writing” because it speaks to why the audience should care.
Getting Started: Tools, Habits, and Building an Audience
Q: For someone who wants to start writing but hasn’t yet, what should they do? Should they find their niche first or just start writing?
Eugene: Start writing. Brutal truth: almost no one will read your first post, so write like nobody’s reading. You’re writing for yourself—to practice. What to write? What you’re thinking about now—work, gardening, recipes—anything. Don’t obsess over “finding your niche” first; you discover it by writing a lot and then looking back at what resonated.
It’s useful to have a niche, but you won’t find it before doing reps. Patrick McKenzie (patio11) wrote hundreds of pieces before recognizing his sweet spot at the intersection of engineering and marketing. You connect the dots retrospectively. Also, writing the same narrow thing forever is boring; I can’t do ML every week. I rotate topics that matter to me and my audience (career, process, ML production, etc.).
Q: What blogging platform or tools do you recommend for someone just starting out?
Eugene: Use whatever is easiest so you remove friction. Writing is already hard—don’t burn cycles on CI/CD and theme yak-shaving. Start with the lowest setup: Medium, Substack, or WordPress. I began on WordPress; when I needed more customization, I moved to Jekyll on GitHub Pages—but only after publishing 50–60 posts. The tool is the least important decision; hitting “publish” weekly is the most important. For what it’s worth, I currently use Jekyll on GitHub Pages.
Q: You work full-time and write a lot. How do you fit writing into your schedule?
Eugene: From 2017 to 2019 I was doing an online MSCS while working part-time—20–40 hours a week. After graduating, I redirected that energy into writing: 1–2 hours every morning as a daily habit (like exercise or meditation). Saturdays I hammer out the prose; Sundays I edit. You don’t have to spend that much—start with short snippets, even 500 words. Tweets and threads can work too, though the constraints can make them harder.
Q: What’s your advice for growing a blog and building an audience? Is there a secret to success?
Eugene: No secret sauce. I just try to be transparent about my process. If anything, the “iterate on the outline” approach is my closest thing to a secret.
For distribution, I publish, then share a short note on Twitter and repost it on LinkedIn. That’s it. Over time, like-minded people find and share it. I’ve hit the Hacker News front page a few times—often when a post invites thoughtful disagreement. But the real lever is consistency: last year I “shot 55 arrows”; a few hit. Consistency beats tricks.
Writing at Work: Design Docs, Documentation, and Portfolios
Q: Let’s talk about writing at work—documentation, design docs, etc. Why is internal writing important, and how does Amazon’s “working backwards” approach work?
Eugene: Writing lets you test ideas at scale before coding. At Amazon, we use the press release (PR/FAQ) before a project: does this excite customers (and internal stakeholders)? If yes, we write a design doc with requirements, latency, throughput, cost, training and serving plans, and trade-offs—then circulate it for feedback.
The “working backwards” process means starting from the customer problem and working back to the solution. The initial press release tests whether it’s worth investing. Writing is central: Amazon largely avoids slides; documents scale your message without you in the room.
Documentation also serves your future self and your team: decision logs (e.g., why DynamoDB over Redis, why Flink over Spark), code notes, and rationales you’ll forget six months later.
Q: What about writing for a technical portfolio, like documenting a Kaggle competition or personal project? What should a good README include?
Eugene: Think of the hiring manager. Clear quick start instructions, requirements, and a repo tour: where to find data prep, training, validation, and serving. Show you can document as well as code. A concise decision log (assumptions, trade-offs) helps your credibility.
Timestamps
Transcript
The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.
DataTalks.Club intro
Alexey: Well hello everyone, thanks for coming today to our event. This event is brought to you by DataTalks.Club, which is a community of people who like to talk about data. We have regular events like this one and two types of events. (0.0)
Alexey: Usually on Tuesday we have more technical events with presentations like technical talks. This week we had a talk about data versioning. Next week we will talk about model monitoring. The week after we will probably talk about how you can deploy a chatbot, which is a complex system. (19.0)
Alexey: In February, the first Tuesday we will talk about Feast, a feature store from TFX. We also have events like today, which are less technical, with no slides, just people talking. Today we will talk about writing. Next Friday we will talk about the role of a developer advocate for data science. We will also talk about open source, which will be on Thursday instead of Friday. Then we will talk about TFX, what it is, and what MLOps engineers do. (44.0)
Alexey: At any point, if you have any questions, you can ask through Slido. That will probably be the most convenient way. You can go there, put your question, or upvote a similar question. I will share this link in the chat. (1:31)
Alexey: Okay, let me pull my notes and we will start. (1:59)
Eugene’s background
Alexey: Today we will talk about technical writing, logging, documentation, and more. We have a special guest today, Eugene Yan. Eugene works at the intersection of machine learning and product. He likes building pragmatic machine learning systems and writes and speaks about effective data science, machine learning, production, and career growth. (2:20)
Alexey: If you follow Eugene, you know he writes a lot every week on his personal blog. Sometimes he posts more than once a week. It was difficult to think of anyone more suited for this episode. Thank you, Eugene, welcome. (2:43)
Eugene: Thank you, Alexey. It's a pleasure to be here. (3:03)
Alexey: Before we go into the main topic of writing, let's start with your background. Could you tell us about your journey and career, how you started? (3:10)
Eugene: It's a bit of an unusual journey. I graduated with a psychology degree about 10 years ago. I spent a few years working on investment policy, but I didn’t really like that. I was writing a lot of text, doing contracts and agreements, and wanted to work more with data. I took about 20 to 30 MOOCs and interviewed at a few places and was lucky to get accepted at IBM. (3:25)
Eugene: While at IBM, I did a competition on product classification. My team managed to get into the top three percent. We shared our attempt at a meetup. An e-commerce startup facing a similar problem invited me for lunch the next day to discuss how I would solve it for them. They offered me a job, and I joined as their third data scientist. That startup was Lazada. (3:52)
Eugene: A few years later Alibaba acquired us. I moved on to a health tech startup, which didn’t work out very well. Now I am an applied scientist at Amazon in Seattle, working on recommendation and machine learning systems. (4:38)
Alexey: If anyone says Kaggle is a waste of time, you’re living proof. There is an article about your career journey, one of your most viewed. I will post the link later. It is a detailed and awesome read. (4:50)
When and Why Eugene started writing
Alexey: Since we are talking about writing, I’m curious, when did you start writing externally, like blogging? Not internal documentation, but external writing. (5:24)
Eugene: My first post was in September 2015, a report for DataKind, an NGO. They asked for volunteers to write, so I volunteered. I admit my reason wasn’t entirely altruistic. I wanted to practice writing. (5:46)
What skills need to be effective in DS
Eugene: When I started, I interviewed data scientists and leads I admired, a few steps ahead of me. I asked what skills make someone effective. The answers surprised me: anyone could learn technical skills, but what made someone stand out was communication, the ability to write and speak with non-technical people. (6:54)
Eugene: I decided to try it for a year. Any time someone needed something written, I would do it. In that same year, I spoke at my first meetup about a Kaggle competition. Many good things happened, and it became a habit. So I started writing about five years ago because people told me it’s important to be effective. (7:47)
What keeps Eugene motivated
Alexey: That is a long answer, but I get it. Why did you keep writing? (8:35)
Eugene: At the end of 2020, I reflected on my posts and realized the main reason I write is to share. I share projects, how I clean Amazon data, how I deploy APIs, class summaries for Georgia Tech online masters, and conference notes. Sharing motivates me to write more. I also write to consolidate knowledge. Sometimes I think I know a topic, but when I write, I realize I need to learn more. Finally, writing connects me to people online. They give feedback and ideas, inspiring me. I call this being a lighthouse. (8:40)
Eugene: I write to share, to learn, and to be a lighthouse. (12:03)
Alexey: I remember the first time we spoke on Twitter. My first question was whether you reached out to me or I reached out to you. (12:28)
What Eugene uses for blogging
Eugene: You reached out and asked about my blogging setup. I use a very simple Jekyll framework hosted on GitHub pages. (12:40)
Alexey: That is amazing. Learning is a big part of it. Technical posts take time because frameworks evolve, and things break. (13:32)
Alexey: Can you repeat the three reasons why you write? (13:38)
Eugene: I write to learn, to share, and to be a lighthouse, signaling to like-minded people that I am interested in this topic. (13:44)
The writing process (iterating outlines)
Alexey: How do you write? Do you have a process or approach for articles? (14:24)
Eugene: When I first started, I thought sitting at a computer and typing would produce something beautiful. I also thought it must be 100 percent original and useful. That high bar made it very difficult to write. (14:59)
Eugene: And so how I write, I realize it’s not about having that mindset first. My mindset now is I write to share, to learn, to be a lighthouse. I realize that writing doesn’t start with writing; you start with reading things you’re interested in, learning things you’re interested in, and then you write notes. Viewed this way, my writing doesn’t have to be original, perfect, or 100% useful, which makes it a lot easier to write. (15:29)
Alexey: Do you mean how you select topics or how you craft a post? (16:05)
Eugene: Both. (16:11)
Alexey: Let’s say you want to write about something. Then an idea occurs to you, maybe from a walk or a tweet about real-time machine learning in China. What happens next? (16:16)
Eugene: When I see topics, I put a title in my notes. Right now, I have about 50 possible topics. I go through them week by week to pick one. (16:39)
The timeline of 7 days
Alexey: How do you write? (16:57)
Eugene: My process is straightforward. I set a timeline of seven days to publish every week. On day one, I pick a topic and write an outline of how I want to structure it. For example, for real-time machine learning, I want to write about why you should not do real-time recommendations, why it could be useful, how real-time recommendations look, and how to do an MVP yourself. That’s the big picture. Then I start bullet points, which takes about two hours. (17:02)
Eugene: On day two, I rewrite the outline from memory. All the bad ideas go out, new ideas go in. On day three, I check if the outline is okay. If not, I iterate again. I repeat this until satisfied. By day six, when I have no more time to iterate, I write the prose. Writing the prose is just taking the outline and writing it in proper human language instead of bullet points, and finding images. This sometimes takes six to twelve hours. (17:41)
Eugene: By day seven, after a night of sleep, I read through the post again, organize ideas, paragraphs, sentences, images. By the end of day seven, I must publish. I may tweak it on Monday or Tuesday if I get feedback, but usually, I stop. (18:43)
Eugene: Iteration is key. I iterate on the outline because iterating on the prose takes too long for me. I care about language, sentence structure, and the right words. By focusing on ideas in the outline, I improve it and leave little time to iterate the prose. (19:01)
The outline structure
Alexey: So most of the time goes to the outline? (19:21)
Eugene: Yes, at least 50–70% of the time. (19:40)
Alexey: How does the outline look? I imagine just a few bullet points. (19:52)
Eugene: The outline has key section headers. For each section, each paragraph has a key topic sentence and supporting evidence. At later stages, the outline almost becomes the content itself, just not in paragraph form. Writing in bullet points makes it easier because I don’t focus on connecting words. (20:18)
Alexey: So by day six, you just translate bullet points into natural language? (21:00)
Eugene: Exactly. (21:12)
Alexey: I usually write prose first, then edit heavily. It’s very slow and ineffective. (21:33)
Eugene: Writing bullet points is much easier. You don’t care, because you will rewrite it anyway. (22:08)
Alexey: Why do you reconstruct an outline from memory? (22:26)
Eugene: It’s like telling a friend about a book. You recall the best parts. Reconstructing the outline from memory filters only the important parts. Afterward, I compare with the original outline to see if I missed key evidence. (22:37)
Alexey: Do you do this every day? (23:49)
Eugene: It depends. If the previous day I finished the outline but am unsatisfied, I rewrite. If satisfied, I start writing the prose earlier. (23:56)
Alexey: Having a break is important. (24:18)
Eugene: Yes. I am a slow writer and thinker, so I need to spend time iterating. Iterating the outline helps a lot. (24:24)
Alexey: If we estimate your weekly writing time, it’s about 25 hours a week including research, writing, and editing. (25:05)
Where to take ideas from
Alexey: You mentioned having a backlog of topics, around 50 ideas. Before you start writing, how do you put things on that backlog, and where do you take ideas from? (25:45)
Eugene: I often write in response to questions people ask. For example, many people ask how my team uses Scrum. Others ask how I transitioned from a psychology degree to data science. When enough people ask, I write about how it scales indefinitely. (25:55)
Eugene: Sometimes I also write about topics I want to disagree with. For example, a Reddit post listed ten roles in data science: data scientists, decision scientists, product data scientists, AI engineers, ML engineers, AI product managers. I disagree. I think data scientists should be more end-to-end. Alexa agrees, but I think a full-stack approach isn’t ideal. (26:31)
Eugene: That opinion was initially unpopular, but Netflix and Stitch Fix adopt the same approach, and it turned out to be surprisingly popular. I also see people focusing on the wrong things. Many ask if coding or writing is more important, and they say writing documentation takes too much time. I disagree writing becomes more important as your career progresses. (26:58)
How to prioritize the topics from the backlog
Eugene: Sometimes people ask, “What’s the point of reading papers?” I disagree—you need to read papers to keep up in your field. I write to answer questions, and occasionally, once I build trust with the community, I share differing opinions. (27:56)
Alexey: How do you prioritize these topics for the week? (28:16)
Eugene: For example, next week I want to write about why people shouldn’t do online courses in 2021. Many ask me, “Is this course good?” I want to share better ways to learn. My only real prioritization is one or two ML topics a month; the rest are messages I want to get across. I imagine writing for my teammates and mentees to help them become better data scientists. (28:23)
The target audience
Alexey: So you have an image of your target audience in mind. How do you use that when preparing an outline? (29:37)
Eugene: I write for three groups. First, myself writing for yourself is always beneficial. Second, my wife, to help her understand what I do. Third, my current and future teammates, and like-minded friends in the community. I assume these readers have some technical or ML background and are motivated to learn. (29:54)
Eugene: Some topics don’t get much traction. For example, writing versus coding is important, but it wasn’t popular at first maybe the community isn’t ready. So yes, I have a specific audience: current teammates, future teammates, and industry peers. (30:53)
Do further iterations make a text worse?
Alexey: Okay, can I ask a question in the meantime, please? You have a very, very detailed workflow for reviewing drafts and concepts. Does it ever happen that editing more makes your text worse, or is it always linear? Do you see any non-linearities in your writing process? (31:13)
Eugene: The tipping point is usually Sunday night. I must release it by Sunday night. Further iterations can make it worse. That’s why when I iterate on outlines, I compare them side by side to see which one communicates my story and message better. When editing paragraphs, I type a new paragraph above the old paragraph and compare the two. My metric for success is if it’s shorter and conveys all key ideas. If it gets longer and messy, it’s worse, so I delete it. You should always do some kind of regression analysis to check if it’s better. (32:06)
Seeing the result as a product
Alexey: Seeing the result as a product? (33:11)
Eugene: Yes. I imagine everything I write as a small product with design, product life, and versioning. When I write about something, I want people to understand it. If they don’t, I fail. If the substance isn’t useful, the back end is bad. It’s very difficult, and I don’t think I will ever get perfect at it. The way to improve is to write every week. Every week there are 50 iterations or 50 different “products,” and maybe in five to ten years I would be good enough. (33:18)
Alexey: Five to ten years if your articles are already that good, what will happen then? (34:09)
Eugene: In five to ten years, I could write the same thing in five hours instead of 20. (34:15)
Trying to control the length
Alexey: Do you try to control the length? I personally have the problem that I have ideas, but elaborating takes too much space. People won’t read very long articles. (34:22)
Eugene: Ideal length is about 1,500 words, about ten minutes read. But honestly, I don’t strictly think about that. I just write enough to communicate the substance and the message. Sometimes it’s 600 words, sometimes 4,000–5,000 words, like my real-time recommendations article. Cutting any paragraph would lose the big picture, so I leave it. I assume my audience is highly interested and can read it anytime. I don’t have a maximum length but try to be concise for the reader’s time. The weekly deadline helps me avoid putting too much information. (34:51)
How to come up with a title
Alexey: How do you come up with a title? Do you do it before writing or after finishing the draft? (36:19)
Eugene: I name my posts like I name functions: clearly so no one would misunderstand. I try to create a sentence that explains what the post is about, like documentation or code. I know there are SEO considerations and clickbait strategies, but by Sunday night, I don’t have energy to overthink the title. (36:45)
Alexey: When we were planning this event, I suggested “Blogging and Technical Writing,” but you suggested “The Importance of Writing in a Tech Career,” which is more compelling and attracted more people. (37:25)
Eugene: I wanted to make the audience care. Tech people focus on their careers. I wanted to show why writing is important in a tech career and convince them to practice. That’s the essence of the title. (38:15)
How to start blogging
Alexey: If everyone on this call decided to start writing, what should they do next? (39:01)
Eugene: Just start writing. First, don’t worry about online visibility. Your first article won’t be read, so write for yourself to practice. Second, write about what’s on your mind now. It could be anything gardening, recipes, hobbies, not necessarily career-related. (39:18)
Eugene: Many people worry about finding a topic. Patrick McKenzie (patio11) wrote about whatever was on his mind for years. After hundreds of posts, he discovered which topics resonated with his audience. You cannot find your niche before writing; only after writing a lot can you reflect and see your niche. (40:28)
Finding a niche
Eugene: Repetition can be boring. I can’t write about machine learning every week, so I mix in other interests like career advice and data science processes. I haven’t found a single focus, and that’s fine. I write for myself, and my topic is whatever I’m thinking about. (41:23)
Alexey: What tool would you recommend? Medium, WordPress, Jekyll? (42:35)
Eugene: Use whatever is easiest. Don’t spend too much time on domains or frameworks. Writing is already hard. I started on WordPress because it was easy. Later, I switched to hosting my own site when I wanted customization. The tool is the least important concern. Reduce barriers and just write. Medium, WordPress, Substack all are fine. (42:49)
How to schedule the writing into the daily routine
Alexey: How do you schedule writing into your daily routine? (43:57)
Alexey: How do you schedule and prioritize this writing work into your daily routine? (44:03)
Eugene: I am busy, but let me share a bit. From 2017 to 2019, I was doing an online Master’s of Computer Science, spending 20–40 hours a week while working part-time. After graduation, I had more time, so I decided to pour this energy into writing 1–2 hours a day early in the morning. It’s just a daily habit, like exercise or meditation. Saturdays I focus on drafting the prose, Sundays on editing. I make time to go out, and thankfully I have a very understanding wife. (44:08)
Eugene: You don’t have to spend that much time. You can write short snippets, maybe 500 words. Start small, start with whatever you’re comfortable with, even tweets. Tweets are actually more difficult because of the character limitation or the need to use threads. (44:08)
Eugene: By the way, I posted a tweet yesterday saying, “You will tell us the secret sauce of writing. What is it?” I have no secret sauce. When I woke up today, I realized I have no secret sauce, but I hope I’ve been transparent and honest enough. Maybe the outline iteration approach is my closest secret sauce. (44:08)
Making the blog popular
Alexey: How did you make your blog popular? (46:01)
Eugene: I don’t know. I wish I had a formula so I could repeat it. I would write, then tweet about it, and post the same tweet on LinkedIn. People who saw it would maybe circulate it. That was my only distribution channel because it’s already a lot of effort to compose tweets just write 200 characters and post it. Eventually, I found like-minded people who read my stuff and engage with me. I didn’t put a lot of effort into that, and I don’t think it’s very popular, but I am thankful to find people with the same interests. (46:12)
Eugene: Hacker News is different; it likes disagreements. One post was “Stop taking regular notes, use a Zettelkasten instead,” and people debated it. Another post about end-to-end data science also reached the front page. The real secret sauce is shooting many arrows consistently. Last year I shot 55 arrows, three hit the mark. Consistency matters. (47:22)
Internal writing (at work)
Alexey: Writing internally at work is also important. How do you approach that? (48:33)
Eugene: Writing is a form of communication. When writing documentation, always think about the reader. Writing at work tests your ideas before coding. For example, Amazon uses the press release before a project. S3’s press release explained a highly scalable, low-cost storage solution. Internal stakeholders react to see if it’s exciting before coding. (48:46)
Eugene: Then comes the design document: how to train the model, serve the model, business and technical requirements in terms of latency, throughput, cost. Circulating it allows peer review and feasibility checks. Writing helps test ideas at scale and document them for future reference. (48:46)
Eugene: Documenting code is like sending a note to your future self: why a decision was made, constraints, optimizations, rationale. Writing prevents forgetting and allows knowledge sharing. Writing at work scales knowledge and ensures you remember details. (48:46)
The Amazon working backwards process
Alexey: The press release and design document are part of Amazon’s Working Backwards process, right? (53:28)
Eugene: Yes. Working Backwards means starting from the customer: understanding the problem or demand, then building a solution. The press release solidifies the idea. For example, Alexa’s first press release was just “start music with your voice command.” Over time, it evolved into more complex functionalities. Writing is a critical part of this process. (53:44)
Eugene: Amazon doesn’t use slides much; writing documents allows scalable communication without needing to present. It saves time, and once written, doesn’t need repeating like presentations. This practice follows me wherever I go. (53:44)
Writing for portfolio
Alexey: Writing for a portfolio. So let's say you did an awesome project, for example a Kaggle competition, and you finished in, I don’t know, top 20 or top 30 with a medal. You want to put all your code on GitHub. What do you need to put in the README so people can immediately see the value of this work? (56:43)
Eugene: Let's think about it: if I'm searching on GitHub for a solution to some Kaggle competition, I would find hundreds of repositories. So what distinguishes one repository from another? I think a clear README is useful, one that explains how to start using this code, a quick start, and how to install it. If it has a requirements file, that’s really useful. Maybe it also explains the big processes, like the data prep step is in this folder, the machine learning step is in this folder, and the validation step is in this folder. (57:20)
Eugene: A basic README that explains this would be good enough. Now, if you think from a portfolio perspective to get a job, think from the manager’s point of view. Clearly, if they're going to hire you, you will be able to write code. But the question is, are you able to document code and explain it? When they read your code, does the README make sense? Does it explain well enough that they feel confident you can do the same thing at work? I think that’s something very helpful. (57:57)
Eugene: Am I audible? (58:44)
Alexey: I think yeah, yeah, audible. I can hear you here, but I can see the connection is a bit choppy. (58:49)
Wrapping up
Alexey: Yes, I guess actually now we are already at 6 p.m., so it means we finished. Maybe you have any last words? (59:20)
Eugene: No, not really. Oh, I do have one. If I had to share something, I’m going to paste a link in the chat. For those of you who are regular readers on my site, please go to that link and tell me what you would like me to write that will be useful for you. I’m always trying to figure out what my audience wants. This is a topic poll. There are a few topics already, you can thumbs up or thumbs down, or propose a new topic. (59:23)
Alexey: Why do some LinkedIn profiles only allow me to follow a person instead of connecting? I usually prefer asking for a connection. What's the main difference between the two? (1:00:13)
Eugene: That’s a good question. On LinkedIn, you can set the default to connect, but I set it to follow. Connections keep building up and can get a lot. However, if you click the small plus button, the ability to connect is still there. (1:00:52)
Alexa: But what’s the main difference between following a person and asking for a connection? (1:01:20)
Eugene: Following a person is like on Twitter; you follow them, but they don’t follow you back. A connection is a two-way follow; you both follow each other, showing a more formal connection. (1:01:27)
Alexa: Are there more questions? (1:01:55)
Eugene: I guess we’re running out of time. Probably need to wrap up. Thanks a lot for coming today, sharing your knowledge, and your secret sauce. (1:02:02)
Alexa: What you shared definitely deserves this name. Next time I write, I’ll try to follow your process and see how it improves what I wrote before. (1:02:08)
Eugene: I hope so. Thanks. (1:02:26)
About the Guests
Eugene Yan
Eugene Yan works at the intersection of machine learning & product to build pragmatic ML systems that serve customers. He’s currently an Applied Scientist at Amazon. Previously, he led the data science teams at Lazada and uCare.ai. He writes & speaks about data science, ML in production, and career growth at eugeneyan.com and tweets at @eugeneyan.
