For anyone who hasn't read that post, Projex is an npm library that renders a searchable, filterable grid of project cards from a config file.

Code review found twelve issues, the review agent asked if I could demo Projex in 60 seconds, I couldn't, and the conclusion was that the code wasn't the blocker. The first-time experience was. The fix I gestured at was a single component: <ProjectGrid>, one component that accepts the config and handles the data fetching internally. No manual async, no server/client split.

"The thing I need is something like a <ProjectGrid> component."

That was the unlock I named.

I built it. It shipped in Projex 1.4.0 on August 7th and it's live on npm, where the package went from 755 downloads in April to 143 last month.

Then I sat down and asked whether it actually did what I said it would.

It didn't.

What I actually shipped

Here's the component. Stripped down (the actual export is SmartProjectGrid; the April post called it <ProjectGrid>, so I'll keep using that name):

<SmartProjectGrid projects={projects} showSearch showFilters>
  {(project) => <MyCard project={project} />}
</SmartProjectGrid>

Vs the old way:

const [query, setQuery] = useState('')
const [tags, setTags] = useState<string[]>([])
const searched = useProjectSearch(projects, query)
const filtered = useProjectFilters(searched, tags)

That's the diff. The April post described a component that handles the data fetching internally, no manual async. The shipped one takes projects as a prop. You still write the fetching code yourself. That part of the idea didn't survive.

The new wrapper saves you maybe twenty lines of boilerplate per page where you want a sortable, filterable, searchable grid. Real savings. Worth shipping.

It does not solve the demo problem. Not even a little bit.

What I thought the demo problem was

The April post framed the demo problem like this:

Here's what getting Projex running actually involves right now:

• Install it
• Write async data fetching code
• Understand that GitHub data only loads at build time, not dev time
• Wire up a server component for the data fetch
• Wire up a client component for search
• Deal with the server/client split

The conclusion was that this list is what blocks the 60-second demo. Six steps, server/client split, build-time fetching that doesn't show up in pnpm dev. None of that is the <ProjectGrid> fix.

What <ProjectGrid> actually does is collapse steps 4 through 6. It does not collapse steps 1 through 3. Steps 1 through 3 happen before any code matters. Someone lands on the npm page, reads the README, finds out the data fetching is manual and the GitHub data only loads at build time, and decides whether to install it at all. The wrapper component isn't visible at that moment. They haven't installed it yet. They're trying to imagine what their portfolio would look like.

If they install it, they get the wrapper. If they don't install it, the wrapper doesn't matter.

The wrapper helps the people who already decided they wanted it. It does not help the people who are deciding.

What I should have framed the problem as

The demo problem is not "the API has too many steps."

The demo problem is "I cannot show someone what Projex does without them first installing it."

To show someone what Projex does, I need a URL. A page on the internet that renders Projex output with real data, that doesn't require them to clone a repo, that doesn't require them to wire up a Next.js project.

The npm page is a README. The README is text. Text is not a demo.

The <ProjectGrid> component does not solve that. It cannot solve that. No component can solve that. Only a URL solves that.

I already had one. My projects page has been rendering straight from the Projex package since March, pulling its data from this blog's projex.config.ts. The April post links to it as proof the library works. I named a component as the unlock in the same post that linked to the actual unlock.

Where that leaves the component

In April I named the wrong thing. I named a component because Projex is code, so code felt like the answer. What I needed was something to send someone, and I already had it. The URL existed before the post did.

If I'd asked in April "can someone see what this does without installing it?", the answer would have been yes: my own projects page. I could have gone straight from that question to the Product Hunt launch, the thing the April post said couldn't happen without a demo. I asked "can I demo this in 60 seconds?" instead, which framed the answer as code I hadn't written yet. So I waited for code that was never the blocker.

The component itself is fine, for what it is. It saves maybe twenty lines per page for people who install Projex, and I moved this blog's catalogue onto Projex's own search, filter and sort helpers so the page and the library share one implementation. That's real. It was never the unlock.

So the next thing is a real demo site: a standalone URL whose whole job is showing what Projex does. This post is the soft launch of that idea. The demo doesn't exist yet. The post does.

I read it and I had surprisingly visceral reaction. It took me a while to figure out why because the reaction wasn't entirely fair.

Most of what it says is true. Follow your passion is bad advice. Most passions aren't economically viable. Work rarely delivers meaning on its own. The office with the humming lights and the chair that never adjusts right.. that's real. I've sat in that chair. I've had the exact conversation the essay describes, where a colleague swivels in his chair with a look on his face that says I cannot believe this is my life.

So why did reading it bother me so much?

Because the essay never distinguishes between accepting your circumstances and choosing them.

It treats the office with fluorescent lights as fate. As the shape of a life, inevitable and fixed, something to be made peace with. And from that premise it draws a reasonable conclusion; if this is where you are, here's how to find meaning in it. But the framing quietly does something else too. By never acknowledging that the office is a starting point rather than a final destination, it removes the question entirely. It doesn't say you can't build something outside of it. It just doesn't leave room for the thought. The world of the essay has two exits. You either accept the ordinary life with grace, or chase your impossible-to-reach dreams and fail. That's not the full map.

There's a third path. Not the rockstar path. Not the path where you sell out arenas or throw touchdown passes or have your face on a billboard. That path is as unlikely as the essay says it is. But between "accept your future lies in an office" and "become exceptional" there's a quieter option. Build small things, outside of hours, that might one day compound into something that gives you a choice you didn't have before. Start a personal brand. Build a network of connections. Open the door to alternative opportunities.

I'm doing this. Slowly, imperfectly, alongside a full-time job. This blog, a couple of side projects I'm not sure will go anywhere. Some won't, and that uncertainty isn't a flaw in the plan. It's the nature of the path. You build anyway, because the alternative is to decide in advance that the office is the answer, which is exactly the move the essay is quietly recommending.

That's where it loses me. Not in its compassion. The argument for finding meaning in the people beside you is real and I believe it. Not in its realism about passion. That's a correction our culture genuinely needs. It loses me in its finality. The essay is written for someone who has already stopped. For that person, the advice might be exactly right. But it presents itself as wisdom for everyone and wisdom that doesn't leave room for agency isn't wisdom. It's consolation.

You can find meaning in the people beside you and still refuse to treat where you are as where you'll always be. Those aren't in conflict. The essay just forgot to say so.

That distinction, between accepting where you are and deciding it's permanent, is the one I keep turning over. I'm not ready to settle. Not yet.

It's not the fixing. You can fix things. It's the explaining. Bridging the gap between what's actually happening and what will land for the person standing over your shoulder. You get good at simplifying. Fast at it. But after a while the simplifying starts to feel like a tax. And eventually, without really noticing, you stop bringing certain things up at all. Not because people don't care about you. But because you already know how it ends.

Hobbies are supposed to fix this.

Common ground. A talking point. Something to bond over. The implicit promise of a hobby is that it connects you to people — other enthusiasts, curious friends, family members who ask how it's going. For most hobbies that promise holds. You pick up candle making and suddenly you have something easy to talk about at dinner. Everyone knows what a candle is. The vocabulary is shared, the concept of enjoying it makes intuitive sense.

But some hobbies break that promise entirely.

Right now the thing I'm most excited about is agentic engineering — building software by collaborating with AI. Not using it as a shortcut. Using it as a creative partner. It's what I think about when I'm not working. What I open my laptop for on a Saturday morning before I've had coffee.

And almost nobody in my day-to-day life gets it.

I've tried explaining it. Someone asks what I've been up to, and I start with "building software with AI" and I can see it happen — the polite nod, the slight glaze. Not because they don't care. They're trying. But the words don't land. "AI agent" means nothing to most people. "Prompt engineering" sounds like corporate jargon. Before I can get to the interesting part I'm already three layers deep in background, and the conversation has moved on.

Even when I find the right simplification, there's another wall waiting. Because building software on a Saturday morning doesn't register as a hobby. It sounds like work. The idea that it could be play — that it's the thing I look forward to all week — that part doesn't compute.

So I stop bringing it up. Or I start to, feel what's coming, and just let it go.

The thing that was supposed to give me community becomes the thing I can't even mention.

Recently someone I work with mentioned Claude Code in passing. Just dropped it into conversation like it was nothing. The same energy, the same excitement, that I'd been wanting to express. We were already two steps into a conversation I didn't have to set up.

That's part of why I write here. Not to explain things to people who don't get it — but to find the ones who already do. The builder who's also lying awake thinking about what's coming. The person who gets why this stuff is fun, not just useful.

On the flip side: being island-like with your content means it stops compounding. The silence isn't just from nobody reading — it can also be because the work itself isn't wired to pull people deeper.

It caught me at the right moment — I'd been thinking about whether my own posting was compounding or just accumulating.

Buried in the noise was something worth keeping: the silence is the deposit phase.

The idea being that the first year of building in public (when nobody's watching, nothing's ranking, and your posts feel like they're disappearing into a void) isn't failure. It's just early. The compounding hasn't had time to show up yet.

I buy that. It maps to everything I've seen from people who actually made it work long-term. But "just keep depositing" has a gap. It assumes all deposits are equal. They're not.

Consistency isn't the whole answer

Most build-in-public advice stops at "just keep showing up." Post consistently. Play the long game. Trust the process.

Fine. But what you're building with that consistency matters as much as the consistency itself.

I looked at my own setup recently. Blog here, X account there, GitHub with projects that don't link back. Each one technically exists. None of them point at each other. Someone finding my X wouldn't know about the blog. Someone reading the blog wouldn't know about the projects.

That's when it clicked — isolated posts don't compound, they just pile up. The ones that build on each other, reference each other, pull a reader deeper — those are the ones that do.

There's a difference between a large archive and a library. An archive is a pile. A library has structure. Things reference each other, ideas build on ideas, a reader lands on one post and the whole thing pulls them deeper.

My stuff right now is more archive than library. It's easy to end up here, especially early on when you're still figuring out what you're even building.

But the library problem isn't just about posts linking to posts internally. Each platform also needs the content to do different work depending on where it lives.

Platforms aren't just audiences. They're different jobs.

I shipped a component library recently: Projex, a shadcn-style showcase kit for developer portfolios. One project, multiple surfaces.

I posted about it on X — a rough thread, a screenshot, a "shipped this" post at midnight. Stream of consciousness, move on. Low barrier, builder brain energy.

The blog version is slower. What I learned building it, the tradeoffs, the decisions I'd make differently. Something that earns a bookmark rather than a like.

LinkedIn is where I had to think harder. Nobody there cares about the npm package. But the gap between "good enough for work" and "good enough that strangers might actually use it" — what building something in public taught me about shipping — that's what LinkedIn cares about. That's the version that makes sense there.

Same source material. Three different jobs.

Not every piece of raw material has all three versions. Some things are only X-native. A half-formed thought, a tool I'm trying, a response to something in the timeline. That doesn't have a LinkedIn version. Forcing one would be obvious and grim.

I've caught myself about to cross-post things that would make no sense outside the X timeline. It's "builder brain at midnight" energy. It stays on X.

Where I actually am with this

I'm working this out in real time.

My LinkedIn has nothing on it right now. No evidence of building. I haven't figured out the voice for it yet, and I've been cautious about the line between "here's what I'm learning" and "here's what I do at work." Those aren't the same thing, but they can look the same from the outside if you're not careful.

My X is random. Building observations, occasional blog posts, no obvious throughline if you landed there cold.

My site is growing slowly. Projects, posts, a Now page. The identity is there if you spend time with it, but it's not obvious yet.

And I think that's fine. I think coherence comes from volume. You can't see the throughline when you've written fifteen posts. It emerges, both for you and for whoever's reading. The job right now isn't to have it all figured out. It's to keep building the library, be intentional about the links between things, and trust that the shape of it becomes clearer over time.

The silence is still the deposit phase. I wrote about what that feels like. And the entrepreneurial gap — between having ideas and actually shipping them — is part of what I'm trying to close. Some of the isolation paradox applies here too: the thing I'm most excited about is hard to talk about anywhere except here. I just want to make sure the deposits are going into the right accounts.

Building in public at lukemanning.ie. Occasionally coherent on X.

Not because you were lazy. Not because you weren't trying. But because from the moment the day started, it belonged to everyone else.

I had one of those days recently. Back-to-back calls. Conversations pulled from every direction. Lunch eaten while staring at a Zoom screen. By 5pm I was completely drained, and yet felt like I had nothing to show for it. No output. No visible progress. Just a long list of other people's problems that I'd briefly helped with and moved on from.

It felt like I hadn't worked at all. It felt like I hadn't existed at all, in any meaningful way for my own work.

Nobody really prepares you for this part of a senior role. A big chunk of what I do now is invisible.

I'm not closing tickets anymore. I'm not on the front line. I'm the person who gets pulled into a Slack thread to help an engineer who's stuck, then drops into an escalation call to figure out next steps for a customer, then reviews a KB article someone's asked me to look at, then gets tapped on the shoulder at my desk because someone needs a hand. The impact is real. People are unblocked, things are moving. But I can't point to any of it and say "I built that."

That's fine. That's part of the role. I accepted that.

What I didn't fully accept until recently is the cost of operating entirely in reactive mode. When my whole day is defined by incoming demands, other people's priorities, other people's timelines, other people's questions, I never get to think. And thinking is where the actual leverage lives.

Not answering questions. Thinking.

The worst part of a fully reactive day isn't the exhaustion. It's the feeling that my time wasn't mine.

I noticed it building up over weeks. Small stuff at first — catching myself checking Slack before I'd even opened my laptop in the morning. Then bigger stuff. I realised I hadn't worked on anything I'd chosen to work on for over a month. The frustration was quiet but constant, like a low hum I'd stopped noticing because it was always there.

I started wondering what it would take to protect against days like that. Not eliminate them — some reactive days are just part of the job. But I wanted a counterweight. Something structural. I thought about blocking out mornings, or setting "no meeting" days, but those always seemed to erode the moment something came up. What I actually needed was something harder to break.

The idea I landed on is simple: dedicated growth time. One or two days per month, fully protected. No calls. No Slack. No desk visits. Unreachable. And at the end of it, something to show — a prototype, a write-up, a working tool, something real.

Not a meeting to discuss doing a thing. The thing. Delivered.

The key word is unreachable. Not "I'll try to be heads down." Fully off the grid for the day. Because the moment there's an exception — just this once, there's something urgent — the whole concept collapses. The value of protected time comes entirely from the protection being real.

I'm going to run this as a personal experiment first. Document what I work on. What I actually produce. How it feels going back into a normal week afterward. Then see if it's worth bringing to others in a similar position.

This also connects to why compound content beats isolated posts — if you're not building with intentionality, the work just piles up instead of compounding.

The reactive day will still happen. That's not going away.

But it doesn't have to be the only kind of day. The thinking, building, creating side of work needs protected space too. Not as a break. Because that's where the actual progress comes from.

The work that moves things forward rarely happens in a Zoom call. It happens in the quiet.

It doesn't feel great.

The Specific Kind of Demoralizing

It's not burnout exactly. I'm not tired of building. I enjoy it. This has become a hobby, and I mean that genuinely, not as a cope, but because the time I spend building doesn't feel wasted even when nothing comes of it.

What stings is the silence after you share something.

You build a thing. You think it's useful. You give it away for free. You're not asking for money, you're not running ads, you're not trying to acquire users in some predatory growth-hack way. You just want to know someone tried it. Maybe filed an issue. Maybe said "this is neat." That's it.

Instead: nothing.

Reddit Is Broken For This

Reddit right now is flooded with AI-generated spam and people shilling SaaS products that barely work. I hate that. And I hate that when I go to post about something I genuinely built and care about, I feel like one of them.

That's the uncomfortable part. I'm not shilling. Projex is free. I'm not asking for anything. But the act of posting about your own work in that environment feels gross now, because the context is so poisoned.

I don't want to learn marketing. I don't want to become someone who optimises posts for engagement. My time is genuinely better spent getting better at building. That's where I am right now.

X Isn't Working Either

I don't like X. Posting there feels like talking into a void. Maybe that changes with audience size (probably does), but right now it's not where I want to spend energy.

I was hoping Projex might get a small handful of users. Not thousands. Not virality. Just a handful of developers who found it useful and maybe said so. That hasn't happened yet, and that's what knocked me sideways a bit today.

DevBreakdown and The Fuzzy Middle

I've also been stalling on DevBreakdown — my AI model and subscription comparison site. Partly because the affiliate angle I originally had in mind is basically a non-starter now. Partly because the space moves so fast I can hardly keep up with it myself, let alone maintain a site tracking it.

And then there's the motivation problem: if I'm earning nothing from it, and it's hard to keep current, and I'm already feeling the silence from Projex... why start another thing that shouts into the same void? The entrepreneurial conundrum is familiar territory here — the gap between having ideas and actually executing on them.

I don't have a clean answer to that. What I do know is that the clarity problem is real. I know what I want DB to be, but the steps between "start" and "ship something useful" are fuzzy. That fuzziness is what kills momentum before you even begin.

Why I'm Still Going

I kept coming back to something today. I've shipped more in the last few months than most people who talk about building ever do.

That's not a flex. It's just what I noticed. And it made me realise: component libraries don't go viral. They get quietly discovered by developers who need them. npm downloads tick up without fanfare. Someone uses your thing without ever telling you.

Maybe that's already happening with Projex. I genuinely don't know.

I know this is a long game. Knowing that doesn't make today any less shit. But my real goal was never a Reddit post going off. It's building a portfolio of work that compounds, covering my AI subs with something I made, and eventually having enough momentum that the audience finds me rather than me chasing it.

€100/month net neutral would genuinely feel like a win right now. That's not a low bar out of pessimism. It's a concrete, honest first milestone.

Today I'm going back to the Straico API proxy I half-built a while ago. It's broken in ways I want to fix. It's contained. It's mine. And finishing it will feel like a win without needing anyone to validate it.

That's enough for today.

There's something underneath all of this I keep coming back to: the essay making the rounds about not following your passion makes a case for accepting where you are. But I think there's a version of that argument that quietly recommends giving up on building anything outside the office. That's the part I can't get on board with.

The Home Server Blog

Years ago I had a blog about setting up my first home server. It started as personal notes on virtualization, then I thought "maybe someone else finds this useful" and put it online. A few posts in, I kept meaning to write the next one. Weeks turned into months. I didn't even notice when the hosting lapsed.

Some of those posts are still floating around on the Wayback Machine. I keep meaning to dig them up and see if any of it's worth resurrecting. Maybe someday.

The Self-Actualisation Blog

More recently I started a different blog at lukemanning.name. This one was inspired by a Dan Koe video where he talked about self-actualisation (becoming the most authentic version of yourself, finding meaning and purpose). He said something that stuck with me:

"Your niche is self-actualisation. What makes you unique are the curiosities, the interests, skills and experience that you gain along the way, because that is unique to everybody."

I'd never heard the term before. Went down a rabbit hole reading about Maslow's Hierarchy of Needs, personal growth, the whole thing. Got excited. Started a blog about it.

That blog lasted a handful of posts. The topic was too broad. "Personal growth" is one of those things that sounds meaningful but is hard to write about consistently when you're also working full time and building things. I didn't have a specific enough focus.

What Actually Made It Click

The thing that finally made this blog happen wasn't a grand realisation about blogging. It was me spending way too long debugging a Velite setup issue, finally getting it working, and then three days later having no idea what I'd done to fix it. I'd closed the terminal, moved on, and the knowledge was just... gone.

That happened more than once. I'd figure something out, feel smart for about five minutes, then lose the solution somewhere between Slack messages and browser tabs. Writing it down was the obvious fix. I'd just never actually done it consistently.

The home server blog was actually closer to what I wanted than I realised at the time. Personal notes about specific problems, shared publicly. Not tutorials. Not guides. Just "here's what broke and here's what I did."

Will This One Last?

I don't know. The home server blog didn't die because the topic was wrong. It died because I stopped making time. That could happen again. I don't have a clever answer for that.

What I do know is the topic is narrower now. I'm not writing about abstract personal growth. I'm writing about specific technical problems I'm facing day-to-day with specific solutions (or non-solutions). And the raw material is always there. I'm building things every week, and things break every week.

That's easier to sustain. There's always something breaking.

Why I Even Started This

I've spent years helping people solve complex technical problems. My job is to take something complicated and make it make sense. But I realized I'd never applied that same principle to my own career story.

Looking back at 10+ years in tech support and technical leadership, it's easy to just see it as "a bunch of jobs." But when you stop and actually write down what you learned at each stage, you might notice some patterns emerge.

So I decided to build a timeline component for my About page. Not just to list where I worked but to capture the real lessons from each role and the things I wish I'd known at the time. This was part of a broader effort to make my About page less of a text dump — I also built a responsive photo card around the same time (the post never made it past draft).

First Attempt: The Inline Approach

I started by just writing the timeline directly in my About page component. Bad move. I had this massive chunk of JSX mixed with my page layout:

// This got messy FAST
<div className="space-y-8">
  <div className="border-l-4 border-quantum-violet pl-6">
    <div className="flex items-center gap-2 mb-2">
      <span className="bg-quantum-violet text-white px-3 py-1 rounded-full text-sm">
        2014-2016
      </span>
      <h3 className="font-semibold">Technical Support Engineer</h3>
      <span className="text-neural-silver">@ Dell EMC</span>
    </div>
    <!-- ... way more content ... -->
  </div>
  <!-- ... repeat for every job ... -->
</div>

After a while of copying and pasting, I realized this was going to be a nightmare to maintain. Every change would require digging through this nested structure, and the About page component was already getting long.

Second Attempt: Extract to Component

Okay, let's make this a proper React component. I created src/components/Journey.tsx and moved the timeline logic there:

export default function Journey() {
  return (
    <section className="space-y-8">
      <h2 className="text-2xl font-bold text-quantum-violet">My Journey</h2>
      <div className="space-y-8">
        {/* Timeline entries here */}
      </div>
    </section>
  );
}

// In src/app/about/page.tsx
import Journey from '@/components/Journey'

export default function AboutPage() {
  return (
    <main className="max-w-4xl mx-auto px-6 py-12">
      <Journey />
    </main>
  )
}

Better, but now I had another problem. How do I pass job data? I could hardcode it.. but that felt wrong. I spent some time debating whether to create a separate data file, use props, or just keep it simple.

I ended up hardcoding it first because I wanted to see if the component would even work.

The Grid Layout Problem

The timeline needed to be responsive. On mobile, everything should stack vertically. On desktop, I wanted the date and title on the left, content on the right.

My first attempt with Tailwind's grid system:

<div className="grid grid-cols-1 lg:grid-cols-12 gap-4">
  <div className="lg:col-span-4">
    {/* Date and title */}
  </div>
  <div className="lg:col-span-8">
    {/* Content */}
  </div>
</div>

This worked, but the alignment was weird. The date badge was floating, and the content didn't line up properly. I spent too long trying flex-grow, gap-4, mt-4, switching between items-start and items-center before realizing I needed to structure it differently.

// Second attempt - tried flexbox
<div className="flex flex-col lg:flex-row gap-4">
  <div className="lg:w-1/3">
    {/* Date and title */}
  </div>
  <div className="lg:w-2/3">
    {/* Content */}
  </div>
</div>

This got the horizontal layout right but broke the vertical timeline effect. The border-left I was using for the timeline line wouldn't span the full height of the entry anymore - it got chopped off at the first child element.

The alignment was weird because the date badge sat awkwardly in the left column, disconnected from the timeline border, and there was no way to make it overlap properly without complex positioning.

What finally worked:

// Full entry structure
<div className="border-l-4 border-quantum-violet pl-6 relative">
  <div className="absolute -left-3 top-0">
    <span className="bg-quantum-violet text-white px-3 py-1 rounded-full text-sm">
      2014-2016
    </span>
  </div>
  
  <div className="grid grid-cols-1 lg:grid-cols-12 gap-4 mt-2">
    <div className="lg:col-span-4">
      <h3 className="font-semibold">Technical Support Engineer</h3>
      <span className="text-neural-silver">@ Dell EMC</span>
    </div>
    <div className="lg:col-span-8">
      <p className="text-code-carbon mb-3">
        Learned systematic troubleshooting under pressure through the GSAP program.
      </p>
      <div className="border-l-2 border-automation-amber pl-4">
        <p className="text-sm text-automation-amber font-medium">
          Key Learning: Part of career growth is knowing when you're ready for the next challenge.
        </p>
      </div>
    </div>
  </div>
</div>

The absolute -left-3 positions the badge 0.75rem (3 * 0.25rem) to the left of the border. Since the border is border-l-4 (1rem), this pulls the badge halfway across the border, creating that centered overlap effect I was going for.

The key insight was using the border-left as the timeline line and positioning the date badge to overlap it. Obvious in hindsight, but it took me a couple of attempts to get there.

What I'd Do Differently (Looking Back)

If I were starting this component again, knowing what I know now:

• Start with a clear data structure. Don't overthink it but have a mental model of what job entries look like before writing JSX
• Use CSS custom properties more consistently instead of bouncing between semantic tokens and hardcoded values
• Build a proper prop interface from the beginning instead of refactoring later when I realized I needed more flexibility

That said, the messy approach worked. It let me iterate quickly and focus on the content rather than getting stuck in architecture. A previous manager of mine once said "Don't let perfect block the road to progress" and that still resonates with me today. That was the approach I took here.

The component finally worked. The layout was responsive, the date badges aligned, everything rendered correctly. I could have stopped there.

The Harder Part: Writing It

Building the component took a few hours including all the debugging. Writing the actual content took significantly more reflection.

Looking back at each role, patterns I hadn't noticed before started to emerge.

Dell EMC (2014-2016)

This was my first proper job, and the GSAP program laid the essential foundation for my entire career. I learned systematic troubleshooting, how to communicate clearly when things are broken and someone's waiting on you. But the role also helped me understand my own value and my drive to take on more. Looking back, I was frustrated that there wasn't more room to grow. That's when I realized: I needed to find a culture that would let me meet that ambition head-on. Past-me was ready for the next challenge—I just hadn't figured out how to ask for it yet.

Nuix (2016-2020)

This job completely reshaped my definition of what technical support can be. I became a dedicated support resource for one of our largest customers in EMEA, working on-site with them, running demos for the sales team, and diving into the Engine APIs to write my own scripts. Great. But then I hit a wall—my passion and responsibilities had expanded, but the role hadn't. I spent way too long thinking I should just be grateful before realizing: no, I needed to find a place that would recognize that contribution. The irony was not lost on me that I'd outgrown the role that had taught me so much.

Cohesity - TSE (2020-2021)

I joined Cohesity in March 2020. Two weeks later, the world shut down. Starting a new job remotely, on a new product, after years of being the go-to person at Nuix—the imposter syndrome was real. I spent that year proving to myself that I could do it again. Learning a complex product from scratch, building new relationships through a screen, finding my footing in a company I'd never set foot in. Here's what I learned the hard way: your reputation doesn't transfer. Your ability to build one does.

Cohesity - Senior TSE (2021-2022)

The imposter syndrome from joining during Covid hadn't fully faded, but something had shifted. Management started routing the harder cases my way—complex database and backup issues that needed more than a standard playbook. I also knew early on that I wanted Tech Lead, so I stopped waiting for the title and started doing the job. Mentoring new hires, sharing what I knew, making myself useful beyond my own ticket queue. Honestly, I was surprised how quickly I stopped caring about the title once I started the actual work.

Cohesity - Technical Lead (2022-Present)

My title is Technical Lead, which in practice means I'm the person the team comes to when something doesn't make sense. As much as I love getting my hands on a weird, messy, complex problem, the real win for me isn't fixing it. It's turning around and showing my team how they can solve it too. I've also started noticing patterns beyond individual cases. Gaps in how we worked, how we shared knowledge. One change started as a tool I built without asking permission, shared with the team, and watched quietly become the new standard. I'm still facepalming that this worked so well—sometimes the best way to drive change is to build the thing first and ask for forgiveness later.

What I'm Taking From This

Writing this timeline forced me to articulate lessons I'd internalized but never expressed. I thought I knew what I learned at each job, but putting it on paper revealed patterns I hadn't seen.

My path definitely wasn't a straight shot up. Lateral moves, expanded roles, finding opportunities to take on more - that was my actual growth. Growth is rarely linear.

The technical skills matter (I can build the component), but understanding WHY I'm building it makes it meaningful. That's the part that sticks with you.

I started writing this thinking I was just documenting where I'd been. I ended up learning something about where I'm going.

Note: I actually wrote this on an older blog (Hence the publish date) but I wanted to resurrect the post here as I quite liked it. I remember sitting in a cafe typing this out on my phone. It felt oddly cathartic to write. Like finally admitting to myself that I spent more time thinking about ideas than executing ideas lifted a weight off my shoulders. That original blog is no more, but the content is still relevant, so I am re-posting it here.

I have business ideas all the time. Every few days something pops into my head, usually triggered by some frustration or gap I notice in daily life. Sometimes I jot them down. I'll even flesh a few out, turn a vague thought into something that feels almost real.

Then I lose interest. Or I realise I'm not actually passionate about it. Or I just... don't do anything.

And then, inevitably, I see someone else ship the exact same thing. Usually some small tool or app I'd scribbled in my notes months earlier and never touched again. My first reaction is always "That could have been me." It doesn't feel great.

It's a cycle I've been in for years.

The 4 AM Ice Bath Thing

There was a stretch where I kept ending up in these YouTube spirals late at night. Start with something legit, then an hour later you're watching a guy in an ice bath telling you that success comes down to waking up at 4 AM and filling out your gratitude journal. You know the type.

Some of them say it's about being uniquely positioned. Having the right resources, knowledge, and contacts at the right time. But if you're just starting out, how are you uniquely positioned? You're not. That's the point.

Then there's the Alex Hormozi approach. "Fake it till you make it." Grind long enough, build the expertise, make the contacts, and eventually something clicks.

I've watched enough of these to know they all have a point. I've also watched enough to know none of them have the full picture. They all sound so sure of themselves. And I kept watching, so I guess it works.

None of it really helped. The problem wasn't knowing how to start. It was starting.

The Reputation Fear

One of the YouTubers I kept coming back to was Dan Koe. He's the same guy who sent me down that self-actualisation rabbit hole I wrote about in my first post. His stuff on personal branding made sense to me: build in public, share your journey, create an audience around what you're learning.

But here's where I get stuck: if I ship something half-baked, does that damage the brand I'm trying to build? Too many missteps and people stop taking you seriously. Or at least, that's what I worry about. Maybe that's just an excuse to not ship anything.

Then I look at Marc Louvion. I came across his profile on X a while back and started following along. He's had more failed startups than most people have ideas. He's transparent about all of them. And he's now followed by over 321k people specifically because of that transparency. He kept failing publicly and kept going.

I read that and think: the reputation fear is overblown. Just ship stuff, be honest about what doesn't work, people respect that. Then I go to actually put something out there and the voice comes back. It'll look half-baked.

The Quote That Made Me Cringe

Reading The Million Dollar Weekend by Noah Kagan, I came across this:

Okay, so you have an idea for an app. How would you go about doing it? Here's the way most people, most wantrepreneurs, would do it:

1. Spend hours at home thinking about the app (and coming up with clever names for it).
2. Spend $100 hiring your cousin to design a cool logo.
3. Set up an LLC.
4. Watch YouTube videos about apps, programming, and business.
5. Consider signing up for a developer bootcamp and quickly realize coding is hard.
6. Buy the domain name for the snazzy website you're going to build.
7. Look into hiring a developer on UpWork and quickly realize it's cost prohibitive.
8. Give up. Again.

Noah Kagan, The Million Dollar Weekend

I've done most of this list. Not all of it, but enough that reading it felt like being called out by name. The domain buying especially. I've bought domains for ideas that never went anywhere. They're still renewing.

Where I'm At

I'm still in the wantrepreneur camp. I know that. Reading that Noah Kagan excerpt didn't magically change anything, it just made the pattern visible.

On the other side of this: the reactive day problem — even when you're building, it's easy to spend all your time answering other people's priorities and end up with nothing to show for it. The problem isn't just starting. It's protecting the space to actually execute.

The conundrum for me isn't really about entrepreneurship at all. It's about the gap between having ideas and doing something with them. I know the theory. I've read the books, watched the videos, followed the people. Knowing the theory hasn't made me ship anything.

I don't have a neat resolution here. I'm still working through it. Maybe writing about it is a small step. Maybe it's just another form of thinking about the app instead of building it. I genuinely don't know.

And then there's the silence problem — even when you do start, the void is real. The silence after shipping something you care about is its own obstacle to continuing.