Style Guide
This guide defines the writing style, formatting standards, and content guidelines for the johnoct.github.io blog.
Writing Style
Tone and Voice
Personal and Authentic
- Use first-person narrative throughout (“I discovered”, “I ran into”, “I learned”)
- Share genuine experiences and real-world challenges
- Be honest about mistakes and what didn’t work
- Avoid corporate or overly formal language
Conversational yet Technical
- Write as if explaining to a colleague
- Balance accessibility with technical depth
- Use industry terminology but explain complex concepts
- Maintain professional credibility while being approachable
Action-Oriented
- Focus on practical solutions and implementations
- Provide actionable steps readers can follow
- Include specific commands, configurations, and examples
- Emphasize what to do, not just what happened
Content Structure
Standard Article Format
- Personal Hook (1-2 paragraphs)
- Start with a real situation you encountered
- Describe the context and why it mattered
- Set up the problem or challenge
- Problem Definition (1-2 paragraphs)
- Clearly explain the technical challenge
- Provide enough context for understanding
- Mention what you tried initially
- Solution Presentation (2-4 sections)
- Break down your approach into logical steps
- Include code examples and configurations
- Explain the reasoning behind decisions
- Show the implementation process
- Key Learnings (bullet points)
- 3-5 concise takeaways
- Focus on what you’d do differently
- Highlight important gotchas or insights
- Include broader lessons applicable to similar situations
Example Structure
I recently ran into an interesting challenge while optimizing costs for a multi-account AWS setup. We were seeing unexpected charges that didn't align with our resource usage, and traditional cost analysis tools weren't giving us the granular insights we needed.
## The Problem
Our monthly AWS bill had grown by 40% over three months, but our application usage remained relatively stable. The Cost Explorer showed general trends but couldn't pinpoint exactly where the extra spending was coming from...
## The Solution
After digging deeper, I discovered the issue was related to data transfer costs between regions. Here's how I solved it:
### Step 1: Identify Cross-Region Traffic
First, I enabled VPC Flow Logs to track network traffic patterns:
```bash
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-12345678 \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name VPCFlowLogs
Key Learnings
- VPC Flow Logs are essential for understanding network costs
- Data transfer charges can be significant but are often overlooked
- Cost optimization requires both tooling and architectural changes
- Regular cost reviews should include network-level analysis ```
Language Guidelines
Preferred Patterns
Use:
- “I discovered that…” (personal experience)
- “This approach works because…” (explanation)
- “Here’s what I learned…” (insight sharing)
- “The key insight was…” (highlighting important points)
Avoid:
- “You should always…” (prescriptive without context)
- “Best practices dictate…” (generic advice)
- “It’s important to…” (obvious statements)
- “Let’s explore…” (academic tone)
Technical Specificity
Good Examples:
I configured the ECS service with a target tracking scaling policy:
```json
{
"TargetValue": 70.0,
"ScaleOutCooldown": 300,
"MetricType": "ECSServiceAverageCPUUtilization"
}
This kept CPU utilization between 60-80% during peak hours.
**Poor Example:**
```markdown
I set up auto-scaling for better performance. It's important to configure the right metrics and thresholds for your use case.
Formatting Standards
Headers and Structure
Hierarchy
#
- Article title (automatic from front matter)##
- Major sections (The Problem, The Solution, etc.)###
- Subsections within solutions####
- Rarely used, only for complex nested content
Consistent Section Names
- “The Problem” or “The Challenge”
- “The Solution” or “My Approach”
- “Key Learnings” (always plural, always last)
Code and Technical Content
Code Blocks
Always specify language for syntax highlighting:
# Shell commands
aws s3 sync ./build s3://my-bucket --delete
# YAML configurations
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
Inline Code
Use backticks for commands, filenames, and technical terms:
- Use
kubectl get pods
to check status - Edit the
docker-compose.yml
file - The
AWS_REGION
environment variable
Command Context
Provide context for commands:
# Install dependencies
npm install
# Start development server
npm run dev
# Build for production
npm run build
Links and References
Link Text
Use descriptive link text that indicates the destination:
Good:
Poor:
External References
- Link to official documentation when available
- Reference specific versions when relevant
- Include publication dates for time-sensitive content
Lists and Bullet Points
Key Learnings Format
Use parallel structure and action-oriented language:
Good:
- VPC Flow Logs provide granular network visibility for cost analysis
- Data transfer costs compound quickly across regions and services
- Automated cost alerts prevent budget surprises
- Network architecture decisions have direct cost implications
Poor:
- Flow logs are useful
- Costs can be high
- You should monitor spending
- Architecture matters
Technical Lists
Use consistent formatting for step-by-step instructions:
- Configure the load balancer
aws elbv2 create-load-balancer --name my-lb --subnets subnet-12345
- Create target group
aws elbv2 create-target-group --name my-targets --port 80 --protocol HTTP
- Register targets
aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:...
Content Guidelines
Technical Accuracy
Verification Requirements
- Test all code examples before publishing
- Verify commands work in the specified environment
- Include version numbers for tools and services
- Note any prerequisites or dependencies
Error Handling
Address common issues and edge cases:
## Troubleshooting
If you encounter permission errors:
```bash
# Check current IAM permissions
aws sts get-caller-identity
# Verify required policies are attached
aws iam list-attached-user-policies --user-name your-username
Common issues:
- Missing IAM permissions for CloudWatch Logs
- VPC endpoint configuration blocking API calls
- Region mismatch between resources ```
Scope and Focus
Article Length
- Minimum: 500-800 words for substantial technical content
- Optimal: 800-1500 words with practical examples
- Maximum: 2000 words (break into series if longer)
Topic Depth
- Focus on one main problem or solution per article
- Provide enough context for understanding
- Include implementation details but avoid unnecessary complexity
- Link to related concepts rather than explaining everything
SEO and Discoverability
Title Guidelines
- Include primary keywords naturally
- Be specific about the technology or problem
- Mention the outcome or benefit when relevant
Good Titles:
- “Reducing AWS Data Transfer Costs with VPC Endpoints”
- “Troubleshooting ECS Task Startup Issues in Production”
- “Automating SSL Certificate Renewal with Let’s Encrypt and Terraform”
Poor Titles:
- “A Quick Tip About AWS”
- “Working with Containers”
- “My Experience with DevOps”
Tag Strategy
Use 3-6 relevant tags per post:
- Primary technology: aws, kubernetes, docker, terraform
- Secondary tools: ansible, jenkins, grafana, elasticsearch
- Concepts: devops, automation, monitoring, security, cost-optimization
- Patterns: troubleshooting, best-practices, lessons-learned
GitHub Stars Content
Daily Posts Format
Automated posts should maintain consistency:
## 1. [Repository Name](https://github.com/user/repo)
**Author:** username | **Language:** Go | **Stars:** ⭐ 1,234
_Repository description from GitHub API._
**Topics:** topic1, topic2, topic3
---
Weekly Roundups Enhancement
Add personal commentary to curated collections:
## 1. [Repository Name](https://github.com/user/repo)
**Author:** username | **Language:** Go | **Stars:** ⭐ 1,234
_Repository description from GitHub API._
**Why it caught my attention:** This tool solves a specific problem I've encountered with Kubernetes networking. The approach to service mesh integration looks particularly promising for our use case.
**Topics:** topic1, topic2, topic3
---
Quality Checklist
Before Publishing
Content Review
- Starts with personal experience or context
- Clearly defines the problem or challenge
- Provides actionable solution with examples
- Ends with specific key learnings
- Uses first-person narrative throughout
Technical Review
- All code examples tested and working
- Commands include necessary context
- Version numbers specified where relevant
- Prerequisites and dependencies mentioned
- Common troubleshooting issues addressed
Formatting Review
- Proper header hierarchy maintained
- Code blocks have language specification
- Links use descriptive text
- Lists follow parallel structure
- Images have descriptive alt text
Metadata Review
- Title is descriptive and includes keywords
- Date is correct in YYYY-MM-DD format
- Category is appropriate (blog or github-stars)
- Tags are relevant and consistent with other posts
- Front matter syntax is valid
Post-Publication
Performance Check
- Page loads quickly on mobile
- Images are optimized for web
- Code blocks are readable on small screens
- Links work and point to correct destinations
Content Validation
- Article appears in correct category listing
- Tags display properly
- RSS feed includes the new post
- Social sharing works correctly
Remember: The goal is to share genuine technical insights that help other practitioners solve similar problems. Focus on practical value over completeness, and personal experience over generic advice.