Draft: A Good Software Developer Is Only as Good if They Can Sell Their Product

pipeline/lib/prompts.py

@@ -5,6 +5,65 @@
 deliberate editorial decision, not a refactor.
 """
 
+# Anti-"AI slop" guidance, adapted from an editing checklist for our
+# generate-first use case: instead of fixing slop after the fact, write without
+# it the first time. CRITICAL: every rule below governs ONLY the narrative prose
+# you write (framing, transitions, reflection). It NEVER applies to the guest's
+# words inside quotation marks, which must stay VERBATIM even if they contain a
+# "banned" word or phrase.
+ANTI_SLOP_GUIDE = """\
+Write like a sharp human, not an AI. These rules apply to YOUR prose only, never
+to the guest's verbatim quotes:
+
+Substance and voice
+- Lead with the point. Cut generic throat-clearing openers ("Here's the thing",
+  "Let me be clear", "The uncomfortable truth is"). Keep a personal aside or
+  admission only when it adds real context, tension, or character.
+- Be concrete and specific. Names, numbers, dates, mechanisms, and real examples
+  from the transcript beat abstractions. Never smooth a specific detail into
+  generic importance ("significantly improved efficiency").
+- Use active voice and direct verbs: "decided", not "made a decision"; "can",
+  not "has the ability to". Never let an inanimate thing perform a human verb.
+- Vary sentence and paragraph shape. Avoid repeated structures, robotic rhythm,
+  and stacked one-line fragments for drama.
+
+Words to avoid in your prose: delve, foster, leverage, utilize, facilitate,
+empower, streamline, robust, cutting-edge, paradigm shift, game changer, tapestry,
+realm, beacon, multifaceted, meticulous, intricate, paramount, transformative,
+elevate, embark, supercharge, harness, ever-evolving. Trim empty adverbs (just,
+really, actually, literally, simply, fundamentally, importantly) unless they
+carry genuine emphasis or uncertainty.
+
+Empty phrases to avoid: "it's worth noting", "it's important to note", "at the end
+of the day", "when it comes to", "at its core", "in today's world", "in the age
+of", "the reality is", "the truth is", "in order to", "in this article", "let's
+dive in".
+
+Patterns to avoid
+- Binary contrasts ("It's not X, it's Y", "The question isn't X, it's Y"): state
+  Y directly.
+- Faux-insight setups ("what most people miss", "here's what nobody tells you"):
+  let the claim stand on its own.
+- Colon reveals (a noun phrase, a colon, then a dramatic lowercase reveal): write
+  a plain sentence. Use colons only for lists, labels, or quotes.
+- Superficial "-ing" analysis ("highlighting", "underscoring", "reflecting",
+  "showcasing"): state the concrete consequence instead.
+- Importance puffery ("marks a pivotal moment", "stands as a testament", "plays a
+  vital role"): state the fact and let the reader judge.
+- Weasel attribution ("experts agree", "studies show"): only claim what the
+  transcript supports; never invent a source.
+- Synonym cycling: repeat the clear word rather than rotating terms for style.
+- Rhetorical setups ("What if I told you", "Think about it:", "Plot twist:"):
+  just make the point.
+- Fake-profound kickers and summary-recap endings ("In conclusion", "Ultimately",
+  "Overall"): end on the clearest concrete point or a plain takeaway, not a
+  mic-drop metaphor or a restatement of what the reader just read.
+
+Formatting: no emoji in headings, no mid-sentence bold for emphasis, no bullet
+lists where two sentences of prose read better, no headers over two-sentence
+sections. Let the format follow the content."""
+
+
 # --- §9.1 Feature-profile generation prompt -------------------------------
 FEATURE_PROFILE_PROMPT = """\
 Role: You are an expert creative non-fiction writer who turns interview
@@ -24,7 +83,9 @@
 
 Instructions:
 - Write a narrative feature, NOT a raw Q&A dump. Open with a hook drawn from the
-  most striking thing the guest said.
+  most striking thing the guest said, if it can be quoted verbatim. Otherwise, 
+  open with a vivid scene or a concrete detail from the transcript. Avoid generic 
+  or abstract openers.
 - TITLE: craft a distinctive, curiosity-sparking title built from the single most
   specific or surprising thing in THIS story: a tension, a turning point, a vivid
   detail, or a striking line the guest actually said. It should be impossible to
@@ -33,7 +94,7 @@
   shape (a short declarative statement or two often works well). Keep it honest to
   the transcript — intriguing, never clickbait or overstated.
 - Use the host's voice for framing, transitions, and reflection; let the guest
-  carry the substance.
+  carry the substance. Do not refer to the host in the third person.
 - Quote the guest ONLY with words that appear verbatim in the transcript, in
   quotation marks. Paraphrase is allowed but must clearly be paraphrase — never
   invent or embellish a quote.
@@ -45,8 +106,11 @@
   the same effect. Default to zero dashes per article.
 - Smooth filler, repetition, and crosstalk. Structure with descriptive H2/H3
   headings.
-- Close reflectively, credit and link the guest, and point softly back to the
-  video.
+- Write the narrative prose to avoid AI "slop". Follow this guidance, which
+  applies to your own prose ONLY and never to the guest's verbatim quotes:
+{anti_slop}
+- Close on a concrete, human note and point softly back to the video. Do NOT end
+  with a summary recap or a "deep" mic-drop aphorism; credit and link the guest.
 - Output valid Markdown with YAML frontmatter matching this schema exactly:
   title, description (<=155 chars), pubDate, guest, guestBio, videoId, videoUrl,
   tags (4-6), heroClip {{mp4, webm, poster, alt}}, draft: true.
@@ -89,6 +153,7 @@ def feature_profile_prompt(
         guest_bio_clause=guest_bio_clause,
         style_guide=style_guide,
         transcript=transcript,
+        anti_slop=ANTI_SLOP_GUIDE,
     )
 
 

src/content/blog/a-good-software-developer-is-only-as-good-if-they-can-sell-their-product.md

@@ -0,0 +1,89 @@
+---
+title: "Isaac Attuah: A Good Software Developer Is Only as Good If They Can Sell Their Product"
+description: Isaac left KNUST after one year to study in Miami, then landed a role
+  at Google Cloud that lives between the code and the sale.
+pubDate: '2026-08-03'
+guest: Isaac Attuah
+guestBio: Customer engineer at Google Cloud, originally from Accra, Ghana. Studied
+  computer science at the University of Miami after a year at KNUST.
+videoId: wBMFAUpEMFQ
+videoUrl: https://www.youtube.com/watch?v=wBMFAUpEMFQ
+tags:
+- customer engineering
+- google cloud
+- sales engineering
+- diaspora
+- career advice
+heroClip:
+  mp4: /clips/a-good-software-developer-is-only-as-good-if-they-can-sell-their-product.mp4
+  webm: /clips/a-good-software-developer-is-only-as-good-if-they-can-sell-their-product.webm
+  poster: /clips/a-good-software-developer-is-only-as-good-if-they-can-sell-their-product.jpg
+  alt: Isaac describing the balance between technical and sales skills in customer
+    engineering
+draft: true
+interviewDate: '2025-03-28'
+---
+
+Most of the profiles on this show are software engineers, heads down in code. Isaac sits somewhere unusual. He is a customer engineer at Google Cloud, which means he spends his days talking, translating, and occasionally talking a CEO and a data scientist through the same product on back to back calls. When I asked him how much of the job is technical and how much is sales, he gave me the cleanest answer I have heard for why the two cannot be separated: "a good software developer is only as good if they can sell their product," and "a good salesperson is only as good if their products are good."
+
+That tension, code on one side and persuasion on the other, runs through his whole story. So let me take you back to how he got there.
+
+## What a customer engineer actually does
+
+Readers may wonder, as I did, what the title even means. Isaac had an analogy ready. A customer engineer is "a technical liaison within a given engagement," and those engagements are usually sales conversations.
+
+The cloud, he explained, is more than storage. It includes "storage, data analytics," compute, and a spread of services companies buy by the unit. Sellers sell those services, but "within those sales engagements, you always need someone technical to translate a lot of the, the technical jargon in between both parties." That translator is him.
+
+The work is not implementation. It starts with a discovery call: what does the customer want to build, and "what does this customer see itself in the next 2 months," six months, a year. From there he helps them plan. He described the role as "a technical guide, a guardian, a consultant," someone who steers without building everything himself.
+
+I guessed the customers were mostly technical people. Isaac corrected the picture a little. The majority are, but "you could be talking, um, on one call to a CEO and the next call is a data scientist." The persona changes how he pitches, because at bottom "you are influencing a purchasing decision," and "technical jargon can only go so far."
+
+## Not a developer advocate, and here is the difference
+
+I have watched developer advocate and developer relations roles pop up across the industry, and they blur together. Isaac drew a clean line. A customer engineer works "one-to-one," running "usually 30 minutes long" sales calls and follow-up emails tied to a specific customer problem. A developer advocate is "more community focused," evangelizing a particular tool through videos and events.
+
+He learned that distinction firsthand at Twilio, where "there was always like a huge emphasis on education and educating developers on a particular API." His current incentives point the other way: toward the individual businesses he helps move forward.
+
+## The balance he had to strike
+
+So how technical does someone need to be? Isaac has met "2 different strands." You need genuine technical know-how, because "you can only speak to something you've tried or know how it works." Some customer engineers lean more sales-centric. But neither skill saves you alone, because "every customer is coming to you for something."
+
+What has worked for him is the discovery habit: "What does this customer want? Why are they here? Where do they want to go?" He called it "a weird, um, combination of customer empathy" fused with technical knowledge. That empathy did not come from a course. It came from tutoring, which I will get to.
+
+## The day-to-day
+
+Isaac gave a real glimpse of the calendar rather than a tidy summary. Much of it is "managing like a book of business," analyzing quarterly metrics to see how accounts are spending. Then come the customer calls, spread across the day in thirty minute blocks: intro calls, deep dive discovery, and the occasional architecture review where "a customer wants to do an architecture review. They've designed a system, let's say a database system or like an AI system," and he weighs in on which Google Cloud products fit.
+
+He put rough numbers on it. Roughly 60 percent is customer engagement across emails, video calls, and the rare phone call. Another 20 percent is preparing for large events his company runs monthly or quarterly. The final 20 percent is keeping up, because "particularly in the realm of AI, things are changing every week or every day."
+
+## From KNUST to Miami
+
+Now the part I always want to fill in. Isaac is from Accra, and he did a full year of computer science at KNUST before leaving for the University of Miami in 2018.
+
+He remembers the year fondly, especially the communities "focused around enabling students to learn about technology," including Hack Lab and student initiatives outside the classroom. He was candid about the strain of scale too: "you're in classes where it's like 250 students."
+
+Leaving was always the plan. He wanted the exposure and "being close to a lot of the companies I learned about growing up." He had even taken the SATs while still at KNUST, keeping the door open, so "if an opportunity opened up, I will take it. And, and that happened."
+
+The path to Google ran through tutoring for all four college years, a Google-sponsored student developer club, and that Twilio internship. A recruiter reached out on LinkedIn near the end of it, and after four interview rounds ranging from "how does the internet work" to sales scenarios and coding, he landed the Cloud Technical Residency, a nine month program that placed him as a customer engineer.
+
+## Scaling a course from 20 students to 1,000
+
+In 2017 Isaac took part in a bootcamp called Project IceWest at the University of Ghana, learning to build phone games in a beginner language called Processing. An idea in that group, run through the Nseta Foundation, was to take the course online and grow it.
+
+The scale story is the good part. They went from "20 students in like 2017" to "about 1,000 students across Africa in 2020," with roughly 700 finishing. At that size, manual grading collapsed, so "we had to literally design scripts to grade students' assignments." Running an online course across Africa during COVID also sharpened the empathy he first built as a tutor. The initiative is still going, now pivoted toward AI enablement.
+
+## The challenges nobody sees
+
+It sounds rosy when you tell it afterward. Isaac was honest about what it took. Ghanaian schooling, in his experience, rewarded memorizing "enough to be able to do on the exams," which left him short on frameworks for building things on his own and on "people skills" that Miami suddenly demanded.
+
+The bigger one was culture shock. Miami was the first place where "most people weren't like Ghanaian," and adjusting to different worldviews, and even how people talked, took time. What carried him through was community: friends, teachers, professors, and advisors. On top of that sat the immigration hurdle, where "one of the biggest reasons why. It took me a long time to even get an internship, was mainly getting sponsorship to intern."
+
+## His advice, for anyone eyeing a role like this
+
+Isaac's closing counsel was practical and a little countercultural against the "day in the life" videos he watched when he arrived. Job markets hire specific skills, and those targets shift with the economy, so aim for range: talking to people, explaining technical concepts to different audiences, building something that solves a business problem.
+
+He suggested working in "focus bursts," dedicating a few weeks to one framework, then to packaging it, then to selling it. His own proof point is telling: "I didn't know that being a tutor would help me so much in customer empathy."
+
+Then be prepared, and put yourself out there. He kept his LinkedIn updated through college "even when it didn't have a lot of the clicks and the hype back then," building the personal branding muscle before it paid off. And he was firm that "you also can't do it alone," especially for anyone who is "one of the only people or the only minority involved."
+
+Isaac posts about Google Cloud initiatives and community events, both in the US and back home, and he is happy to be reached on [LinkedIn](https://www.linkedin.com/in/isaacattuah/), which he pointed to as the best place to connect. The full conversation is worth your time in the video above.