Building an artefact portfolio: blogs, talks, and OSS contributions

Why artefacts matter

Your CV says “experienced in Proxmox VE”. A blog post shows you can articulate what you did, why you did it, and what you learned. A talk demonstrates you can teach. An open-source PR proves you can work with strangers.

Artefacts are the artefacts that:

• Outlive your memory
• Are easier to talk about than projects you can’t describe
• Compound over time (10 small posts > 1 big one)
• Demonstrate writing and teaching skills, not just technical
• Travel further than your LinkedIn profile

This lesson covers three artefact types: blogs, talks, and OSS.

Personal blog

A personal blog is the highest-leverage artefact. It:

• Costs $0 to start (GitHub Pages, Hashnode, dev.to, etc.)
• Compounds over time
• Is yours forever (no company controls it)
• Demonstrates writing, not just technical thinking

Picking a platform

The best choice is the one you’ll actually write for. For most people, personal blog on GitHub Pages with Hugo or Astro wins.

What to write

The most useful posts are:

• Bug post-mortems — “We had this weird bug, here’s what caused it, here’s the fix”
• Tooling deep-dives — “I tried X, here’s what I learned”
• Comparison posts — “X vs Y for our use case, here’s the data”
• Decision posts — “Why we chose Proxmox over VMware”
• Concept posts — “How corosync really works”
• Diary-style posts — “What I did this week to deploy Ceph”

A good rule: write the post you wish existed when you were learning this topic.

Length and frequency

• Length: 500-2000 words is the sweet spot
• Frequency: 1 post per month is sustainable; 1 per week is heroic and short-lived
• Cadence: pick a cadence and stick to it. “Every other Tuesday” beats “when I feel like it”

Workflow

1. Capture ideas in a note file as they come up
2. Pick one idea per month
3. Write a draft in a private Google Doc or local Markdown file
4. Edit ruthlessly (cut 30% in editing)
5. Publish on schedule
6. Share on social media once

Conference talks

A talk is a high-leverage artefact because:

• It forces deep understanding (you can’t hand-wave on stage)
• It travels (recordings live forever)
• It establishes you as an expert
• It builds your professional network

Finding a venue

• Local meetups — easiest first step, low stakes
• Regional conferences — bigger audience, more competitive CFP
• Big conferences — KubeCon, VMworld, FOSDEM — hard to get in, very valuable
• Internal conferences — within your company, also counts

CFP Land aggregates open CFPs.

Writing a good proposal

Most conferences ask for:

• Title: catchy, specific
• Abstract (~200 words): what they’ll learn
• Outline: what you’ll cover, section by section
• Bio: who you are, why you’re credible
• Audience level: beginner / intermediate / advanced

A good abstract:

“We migrated 800 VMs from VMware vSphere to Proxmox VE in 6 months. This talk covers what worked, what didn’t, and the playbook that emerged. You’ll learn: how to assess workloads for migration risk, the disk conversion tooling that worked, how we handled driver injection for Windows guests, and the project management patterns that kept us on track.”

A bad abstract:

“This talk will discuss Proxmox migration. We will look at various aspects of migration and how to do it well.”

The first has specifics (800 VMs, 6 months, tooling, Windows drivers). The second could be a placeholder.

Preparing the talk

• Outline first, slides second — slides are visual aids, not the talk
• Rehearse — at least 3 times, ideally to a friend
• Time yourself — most conferences cut you off mid-sentence if you overrun
• Have a backup — slides on a USB drive, second laptop if possible

The talk itself

• Start with the problem, not the solution
• Tell a story, not a feature list
• Use diagrams (drawn live if possible)
• End with takeaways the audience can apply tomorrow

Open-source contributions

OSS contributions demonstrate:

• Ability to read and understand others’ code
• Communication with maintainers and reviewers
• Collaborative discipline

For a Proxmox-focused career, contributing to:

• Proxmox VE itself (mostly Perl, with Python tooling)
• PBS (Rust)
• community-scripts.org (Bash, easy to start)
• terraform-provider-proxmox (Go)
• prometheus-pve-exporter (Python)

Starting

1. Find a “good first issue” label on the project’s GitHub
2. Read the contribution guide — many projects have specific processes
3. Open an issue describing what you want to fix before doing the work
4. Submit a small PR — first PR should be tiny (typo fix is fine)
5. Iterate based on review

What makes a good PR

• Small, focused, single-purpose
• Has tests if the project uses them
• Has a clear description (“Fixes #X” or “Adds Y”)
• Passes CI before requesting review
• Responds to review comments promptly

Building the habit

Artefact-building is a habit. Stack it onto an existing habit:

• “After every incident, I write a post-mortem”
• “Once a month, I write a blog post about something I learned”
• “Every quarter, I submit a talk proposal”

Track it. Visible progress motivates more progress.

Common mistakes

“I need to write something original”

You don’t. Most blog posts are “here’s what I learned trying X” — that’s original because it’s your experience. Synthesis posts (“I read N docs about X, here’s my summary”) are also valuable.

“I don’t have time”

You have time to read Hacker News. You have time to write 500 words about what you learned this week. It’s a priority problem, not a time problem.

“It’s not good enough”

Your first post won’t be good. Your tenth will be better. Your hundredth will be excellent. Ship the imperfect first post.

“I’ll do it once I get promoted”

Most senior engineers have artefact portfolios that caused the promotion. Build the artefacts first.

Key takeaways

• Artefacts compound: blog posts, talks, OSS contributions
• A personal blog is the highest-leverage artefact
• Talks force depth of understanding and travel far
• OSS contributions demonstrate collaboration
• Build the habit; ship imperfect artefacts; iterate

Knowledge check