Twelve Weeks of Writing About Security: What I Learned

Twelve weeks ago, I published the first article in this series: a reflection on why supporting more than 1,200 users pushed me from IT support into cybersecurity. Since then, I've written twenty-four pieces covering networking fundamentals, security concepts, home lab projects, field lessons and career advice.

This final article in the series looks back at what I covered, what writing in public taught me and what's next. It also ends with an open invitation to ask me anything.

Why I started

When I set out to write this series, I had three goals.

To learn more deeply. Explaining a topic clearly is one of the best ways to find out whether you really understand it. Writing about DNS, VPNs, hashing and incident response forced me to revisit details I thought I knew.

To share practical knowledge. A lot of security content is either very basic or very advanced. I wanted to write for the people in between: help desk staff thinking about security, students, career changers and IT generalists who want clear, usable explanations.

To show my work. Resumes list skills. Articles demonstrate them. I wanted anyone reviewing my profile to see how I think, how I solve problems and how I communicate.

What the series covered

The articles fell into five themes.

Field Notes: lessons from real IT work

• Triage using urgency and impact
• Keeping downtime low when the fix belongs to a vendor
• Why documentation is a security control
• Asset inventory as the foundation of security

Network Basics: understanding how networks really work

• A five-check routine for DNS problems
• ping, traceroute and nslookup
• VPNs explained: WireGuard and IPsec
• Telling LAN problems from WAN problems

Security Explained: core concepts in plain language

• Phishing red flags for new hires
• Why forensics relies on hashes
• Least privilege from onboarding onward
• First commands on a new Linux server
• Holiday scams, for family and friends
• Patch Tuesday and patch management
• The incident response lifecycle

Lab Log: what I've built and broken

• My Pi-hole and WireGuard home lab
• A month of DNS logs
• Building Forensic Raptor, my Android forensics tool
• Docker mistakes that create security holes

Career Path: building a career in security

• Moving from IT support into security
• What studying for CEH taught me, and what it didn't
• Advice for students starting a tech program
• My learning plan for 2027

If you missed any, they're all on my profile, and I'd welcome comments on any of them, old or new.

What writing in public taught me

Clarity takes more work than complexity. It's easy to write something technical that sounds impressive. It's much harder to write something technical that a busy person understands on the first read. Every article went through several drafts, and most of the editing was about removing jargon and making steps clearer.

Explaining exposes gaps. More than once, I started writing about something I thought I understood well and realized I needed to go back to documentation, test something in my lab or check a detail. Those moments were some of the most valuable learning of the past three months.

Consistency beats intensity. Publishing twice a week on a fixed schedule was more sustainable than waiting for inspiration. A calendar of topics planned in advance made it possible.

Practical content connects. The articles built around real routines and checklists, the kind of thing people can use at work the next day, tend to spark the most useful conversations.

Comments are where the learning continues. Readers add their own experiences, alternative methods and corrections. Some of the best insights in this series came from people responding to it.

Experience is worth sharing, even early in a career. I'm not a veteran with decades in the industry. But my experience supporting a manufacturing plant, working at an internet service provider, building a forensics tool and running a home lab is real, and it turns out other people find it useful. If you've been holding back from writing because you don't feel expert enough, I'd encourage you to start.

How each article came together

People have asked how I approached writing alongside work and study, so here's the process I followed for each piece.

1. Start from the calendar. Every topic was chosen in advance, so I never sat down wondering what to write.
2. Write the outline first. A title, a one-sentence promise to the reader and five to eight section headings.
3. Draw on real experience. For each section, I asked what I had actually seen or done that related to it: a support situation, a lab project, something from my studies.
4. Check the facts. Commands were tested in my lab where possible, and technical details were checked against official documentation.
5. Draft, then cut. First drafts were always too long and too technical. The second pass removed jargon and tightened every paragraph.
6. End with something useful. A checklist, routine or summary that readers could take away.
7. Close with a question. Each article ended by inviting readers to share their own experience.

What I'd do differently

If I started the series again, I'd make a few changes. I'd include more diagrams and screenshots, since visual explanations often land faster than text. I'd write shorter companion posts for the busiest days, linking back to the full article. And I'd invite a few colleagues to review drafts before publishing, to catch mistakes and add perspectives I'd missed.

None of those would change the core lesson, though: the hardest part is starting, and the second hardest part is keeping going.

Tips if you want to write your own series

1. Plan your topics in advance. A list of twenty-four ideas removes the hardest part: deciding what to write.
2. Write from experience. Personal examples make technical content memorable and credible.
3. Pick a schedule you can keep, then keep it.
4. Make each piece useful on its own. A checklist, routine or clear explanation gives readers a reason to save and share it.
5. End with a question. It invites conversation and helps you learn from your readers.
6. Respect confidentiality. Never share details that identify an employer's systems, customers or incidents. Generalize and anonymize.
7. Reply to comments. Writing is only half the value. The conversation is the other half.

Why this matters for anyone in IT

You don't need to be a writer to benefit from sharing what you know. Writing about your work builds three things that matter in any IT career.

Credibility. Hiring managers and colleagues can see how you think, not just what's listed on your resume. A clear explanation of a troubleshooting routine says more about your skills than a list of keywords.

Communication skills. IT and security work increasingly involves explaining risks and decisions to people outside the field. Writing regularly is practice for exactly that.

Connections. Articles start conversations with people you'd never meet otherwise: practitioners in other companies, recruiters, students and people facing the same challenges you've solved.

Even one article a month, built from something you learned at work or in a lab, adds up over a year.

What's next

This series is finishing, but I'm not stopping. Next, I plan to:

• Keep writing, likely on a lighter schedule, with deeper write-ups of home lab projects as I add security monitoring, a small Windows domain and a dedicated firewall.
• Share progress on my certification goals for the year.
• Continue connecting with people working in security operations and network administration in the Toronto area.

I'm also actively looking for my next role in cybersecurity, security operations or network administration in the Greater Toronto Area. If your team needs someone who combines hands-on IT support and networking experience with security training, I'd be glad to talk.

Ask me anything

To close the series, I'd like to open the floor. Ask me anything in the comments about:

• Moving from IT support into security
• Networking and troubleshooting
• Home labs, Docker, Pi-hole or WireGuard
• Digital forensics and Forensic Raptor
• Studying at Seneca Polytechnic or starting a tech career in Canada
• Certifications like CEH

I'll answer as many questions as I can over the coming week.

Thank you to everyone who read, commented, shared or reached out during this series. What topic would you most like me to write about next?