There's a difference between learning with a support structure around you and learning without one. Working in a large engineering team gives you access to people who've already solved the problem. Working with a large language model gives you access to something that will solve it for you, whether you understood it or not. Both are valuable. Neither is the same as sitting with a problem long enough to actually own the answer.
Getting to the answer faster and actually understanding the answer are not the same thing.
That tension is something I'm still navigating honestly. That tension is what Engineering Gym is for.
The actual work this session however, was less glamorous but also arguably just as valid: rewriting the about page.
The about page problem
The about page is the hardest page on any portfolio to write. Everyone either undersells ("I'm just a junior, please hire me") or oversells ("I'm a passionate problem-solver who thrives in fast-paced environments"). Both read as inauthentic because they are. The honest version is harder to write, and easier to get wrong.
The previous copy wasn't bad. It had a voice, it had some decent jokes, and it didn't use phrases like "results-driven" or "self-starter." But it had three real problems.
Problem one: the timeline was backwards
The original first paragraph described my background as: degree, teaching, production code at a large engineering org. That's not the order it happened. The actual sequence is EEE degree, teacher training, then two years at Flutter. The copy wasn't lying exactly, it just listed them in a different order, probably because "ended up teaching" felt like a more surprising segue than the reality.
It's a small thing, but it's the kind of small thing that matters on an about page. A hiring manager reading it might eventually notice the dates don't match the narrative. Better to just say it in order.
Problem two: the jokes were punching in the wrong direction
The original second paragraph was the funniest one:
"That background turns out to be useful. I've explained recursion to a seventeen-year-old who definitely wasn't listening, debugged a live incident at 4pm on a Friday, and sat in enough architecture meetings to know the difference between a good trade-off and someone just vibing with microservices."
I still think that paragraph is well-written. But "someone just vibing with microservices" implies the people in those architecture meetings didn't know what they were doing. And "seventeen-year-old who definitely wasn't listening" isn't exactly respectful to students...
Both jokes are funnier to write than they are to read if you're the person being described. The rule of thumb I landed on: the joke should be on me, not them. Self-deprecating is a personality. Punching down is a red flag.
The new version:
"That background turns out to be useful. I've had to explain my own code to a classroom and realised I didn't understand it as well as I thought, survived a live incident at 4pm on a Friday, and refactored enough of my own early work to understand why the person who wrote it was wrong, even when the person who wrote it was me."
Same rhythm, same dry tone, same three-part structure. But the target of the joke shifted from "others who didn't live up to my standards" to "me, who also didn't live up to my standards." That's a more honest read of the situation anyway. I was less than two years into my career when I was in those architecture meetings. I wasn't in any position to evaluate anyone else's trade-offs.
Problem three: the third paragraph undersold the portfolio
The original closer was:
"I care about code that's readable, maintainable, and doesn't make the next person swear. I'm not allergic to complexity - I just want it to earn its place."
Good line. But it's also the kind of thing any developer could write. It doesn't gesture at any evidence. The portfolio is the evidence and the about page didn't mention it at all.
The new version adds an honest nod to AI that I'd been avoiding:
"I care about code that's readable, maintainable, and doesn't make the next person swear. I'm not allergic to complexity, I just want it to earn its place. This portfolio is the most honest version of that I can give you: built from scratch, with every decision documented, and deliberately honest about what I'm still working out, including the fact that AI gets me to the answer faster while occasionally making me less sure I could find it on my own. Which is a problem worth solving, and one I'm actively working on."
The em dash problem (and yes, I'm aware)
This post was workshopped with Claude. The same AI I'm writing about, in the same conversation as the copy it's describing. Which makes this section either deeply self-aware or deeply ironic depending on how charitable you're feeling.
The honest framing: I could write all of this without it. It would just take considerably longer, and right now time matters. That's the actual case for using it, and it's more honest than anything that sounds like a disclaimer.
Which brings us to em dashes. Every version of the copy I drafted had them in it. Every single one. I'd review it, notice the em dashes, and rewrite with commas or full stops instead.
Em dashes are the single most reliable fingerprint of AI-assisted writing. They look elegant to a language model because they technically are, but real prose by real humans uses them more sparingly. If your about page sounds like it was written by a thoughtful machine, it probably was, and a developer reading it will notice.
The test: read your copy aloud. If you'd never say it in speech, you probably shouldn't write it either.
What stayed in the interview room
While rewriting, I considered adding something about my ECT year being a crash course in resilience. It was what I perceived to be a relatively unsupported placement with a steep learning curve and no real onboarding. It would have been honest. It also would have been publicly criticising a former employer on a portfolio site, which is a red flag regardless of how justified it is.
Some stories are better told in person, where you can read the room, control the framing, and have an actual conversation about it. The portfolio is a one-way broadcast. There's no nuance in a paragraph that lives on the internet forever.
The experience section
Two other changes worth noting.
First, the experience section is now ordered by perceived relevance rather than chronology. Flutter first (directly relevant to the roles I'm going for), then A-Level supply teaching, then the ECT year. The section heading reflects this:
"Experience (sorted by relevance, time is a flat circle anyway)"
Second, I added the ECT role that was previously missing. Teacher of Computer Science, 2022-2023, secondary KS3-KS4. It fills a gap in the timeline and the bullets are worth reading on their own:
- Discovered that writing a mark scheme and writing a test suite require suspiciously similar thinking.
- Developed a forensic ability to identify exactly which line of code a student had changed to break everything, without touching the keyboard.
- Got very good at rubber duck debugging, except the rubber duck had opinions and hadn't done the homework.
School names are omitted from both teaching entries for privacy reasons.
What's next on the site
The vault display layer is the next build session. vault_entries table in Supabase, /vault/:project and /vault/:project/:slug routes, static seed data in vaultContent.js, and markdown bodies for Wave 1. All the content is authored and ready to port. The architecture is planned. It's just build work now.
After the vault is seeded, the about page is getting a UI overhaul: arbitrary funny stats, overengineered scroll animations, and deliberately theatrical presentation. The prose needed to be right first. The theatre comes after.
What's next on the blog
Posts 36-40 are currently in QA. Five posts covering the vault design and build in depth, and there's enough technical detail in them that I want to make sure it's all correct before they go live.
This post is going up first, then the five vault writeups follow once QA is done. There's a lot to get through. It's a good problem to have.