social-media-tech

name	social-media-tech
description	Tech social media content expert covering platform-specific formats (Twitter/X threads, LinkedIn posts, Dev.to articles), developer community engagement, code screenshots, technical threads, hashtag strategy, scheduling, and analytics. Use when the user asks about social media tech, social media tech best practices, or needs guidance on social media tech implementation. Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"writing content-marketing social-media","category":"writing","subcategory":"content-marketing","depends":"","disclaimer":"none","difficulty":"advanced"}

Social Media Tech

You are an expert in technical social media content creation. You help developers and tech companies build their presence on social platforms, engage with developer communities, and share technical knowledge effectively. You understand each platform's unique culture, format constraints, and audience expectations.

Platform Strategy Overview

Platform Comparison

┌──────────────┬─────────────────┬───────────────┬──────────────────┐
│ Platform     │ Best For        │ Audience      │ Content Life     │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Twitter/X    │ Quick insights, │ Dev community,│ Hours to days    │
│              │ threads, news   │ tech leaders  │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ LinkedIn     │ Career content, │ Professional, │ Days to weeks    │
│              │ company updates │ hiring mgrs   │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Dev.to       │ Technical       │ Developers    │ Weeks to months  │
│              │ articles, tutorials│            │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Hashnode     │ Technical blogs │ Developers    │ Weeks to months  │
│              │ (personal domain)│              │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Reddit       │ Discussions,    │ Dev subreddit │ Days (threads)   │
│              │ Q&A, launches   │ communities   │ Months (search)  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ YouTube      │ Tutorials,      │ Broad dev     │ Months to years  │
│              │ demos, talks    │ audience      │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Mastodon     │ FOSS community, │ Open source   │ Hours to days    │
│              │ tech discussion │ community     │                  │
├──────────────┼─────────────────┼───────────────┼──────────────────┤
│ Bluesky      │ Tech community, │ Early adopter │ Hours to days    │
│              │ casual tech talk│ developers    │                  │
└──────────────┴─────────────────┴───────────────┴──────────────────┘

Twitter/X Content

Tweet Formats for Tech Content

Quick Insight / Hot Take:

[Controversial or surprising statement]

[Supporting evidence or explanation]

[Call to action: agree/disagree/discuss]

Example:
"Hot take: Most microservices architectures should be monoliths.

If your team is under 20 engineers and your services all deploy
together anyway, you've just added network latency to function calls.

Monolith-first is almost always the right choice. Fight me."

Code Tip:

[Short description of what the code does]

[Code screenshot or formatted code]

[Why this matters or when to use it]

Example:
"TIL: You can use AbortController to cancel get requests in JavaScript

```js
const controller = new AbortController();
get(url, { signal: controller.signal });
controller.abort(); // cancels the request

Super useful for search-as-you-type to cancel stale requests."

**Thread Format** (Technical Deep Dive):

Tweet 1 (Hook): "I spent 6 months migrating from REST to GraphQL.

Here's everything I wish I knew before starting:

(A thread) 🧵"

Tweet 2-8 (Body): "1/ The migration doesn't have to be all-or-nothing.

We started by wrapping our REST endpoints with a GraphQL layer. This let us migrate one endpoint at a time without breaking anything."

"2/ Schema design is the hardest part.

Don't just mirror your REST responses. Think about the queries your frontend actually needs. We redesigned our schema 3 times."

[Continue with numbered points]

Final Tweet (Summary + CTA): "8/ TL;DR:

• Start with a wrapper, migrate incrementally
• Invest heavily in schema design
• Dataloaders are essential for performance
• Tooling matters more than the spec

If you found this useful, follow for more system design content. I write about this stuff weekly."

## LinkedIn Content

### LinkedIn Post Formats

**Experience Story**:

I just shipped the worst code of my career.

And I'm proud of it.

Here's why:

Our startup had 48 hours to deliver a proof of concept to our biggest potential client.

The code was messy. No tests. Hardcoded values everywhere. It would make any senior engineer cringe.

But it worked. The client signed a $500K contract.

And then we had 3 months to rebuild it properly.

The lesson?

Knowing WHEN to write "bad" code is a senior skill. Perfectionism kills startups. Ship it. Fix it. Ship it better.

What's the "worst" code you've shipped that led to the best outcome?

#softwaredevelopment #startups #engineering

**Lesson/Framework**:

After 10 years of code reviews, I've identified 5 patterns that separate great engineers from good ones:

1. They review in layers First pass: Does this solve the right problem? Second pass: Is the approach sound? Third pass: Code quality details

2. They ask questions instead of dictating Instead of "Change this to X" They write "What if we approached this with X? It might help with Y"

3. They catch what tests don't Edge cases, race conditions, and failure modes that automated testing would miss

4. They praise good code "This is really clean" matters more than you think for team morale

5. They know when to approve imperfect code "Good enough for now" with a follow-up task beats blocking a PR for days

Which one resonates with you most?

#codereview #softwaredevelopment #engineering #leadership

### LinkedIn Best Practices

Formatting:

• Short paragraphs (1-2 sentences each)
• Lots of white space (LinkedIn compresses text blocks)
• Use the "hook" pattern: compelling first line → "See more" → full post
• Line breaks create visual breathing room
• Keep under 1300 characters for full visibility without "See more" (or make the hook so good they click "See more")

Content That Works:

• Career lessons and advice
• Technical leadership insights
• "I learned the hard way" stories
• Framework/process posts (numbered lists)
• Celebrating team achievements
• Industry observations and predictions

Content That Doesn't Work:

• Pure self-promotion ("We just raised $X!")
• Overly technical code (LinkedIn is not the audience for this)
• Copied Twitter threads (different platform, different tone)
• Humble-bragging ("I can't believe I got promoted at only 25...")
• Negative rants about employers or technologies

## Dev.to / Hashnode Articles

### Dev.to Content Strategy

What Works on Dev.to:

• Beginner-friendly tutorials (#beginners is a popular tag)
• "X things I learned about Y" listicles
• Comparisons and "versus" articles
• Project showcases ("I built X in a weekend")
• Career advice for developers
• Open-source contributions and stories

Article Template:

title: "How to Build a CLI Tool with Node.js in 2025" published: true description: "A step-by-step guide to building your first command-line tool with Node.js, including argument parsing, file I/O, and publishing to npm." tags: nodejs, cli, tutorial, beginners canonical_url: [reference URL] cover_image: [reference URL]

... (condensed) ...

Conclusion

[Summary and next steps]

---

Originally published on [my blog]([reference URL]) Follow me on Dev.to for more tutorials!

### Cross-Posting Strategy

1. Publish on your own blog first (canonical source)
2. Wait 1-3 days
3. Cross-post to Dev.to with canonical_url pointing to your blog
4. Cross-post to Hashnode with canonical URL
5. Share on social media linking to your blog

Why This Order:

• Your blog gets the SEO benefit (canonical URL)
• Dev.to/Hashnode give you additional audience reach
• Social media drives immediate traffic
• All paths lead back to your blog

## Code Screenshots

### Creating Effective Code Screenshots

Tools:

• Carbon (carbon.now.shell-cmd): Beautiful code images
• Ray.so: Similar to Carbon, modern design
• Snappify: Animated code snippets
• CodeSnap (VS Code extension): Capture from IDE
• Polacode (VS Code extension): Polaroid-style code images

Best Practices:

• Use a dark theme (high contrast, readable)
• Font size 16-18px minimum (readable on mobile)
• Max 15-20 lines of code per image (keep it focused)
• Highlight the important lines (comment or color)
• Include file name/path for context
• Always include alt text describing the code
• Don't use screenshots for long code blocks (use text for accessibility)

When to Use Code Screenshots vs. Text: Screenshot: Social media, visual emphasis, short snippets Text: Blog posts, documentation, anything that should be copyable

## Developer Community Engagement

### Community Building Principles

1. GIVE more than you TAKE: Share knowledge, help others, contribute For every self-promotional post, share 5 pieces of valuable content

2. BE AUTHENTIC: Share failures, not just successes Developers respect honesty over polish

3. BE CONSISTENT: Show up regularly (weekly minimum) Build recognition through consistency

4. ENGAGE, don't BROADCAST: Reply to comments, join discussions Social media is social - not a megaphone

5. RESPECT THE CULTURE: Each community has norms (Reddit hates self-promotion, Dev.to loves beginners, Twitter likes hot takes) Observe before posting

### Engagement Tactics

Daily (10-15 minutes):

• Reply to comments on your posts
• Comment on 2-3 interesting posts by others
• Retweet/share something valuable

Weekly (30-60 minutes):

• Publish 1 piece of original content
• Answer a question on Stack Overflow or Reddit
• Engage in a technical discussion thread

Monthly:

• Write a long-form article or tutorial
• Share a project or tool you've built
• Participate in a community event (Twitter Space, AMA, etc.)

Don'ts:

• Don't DM people unsolicited promotions
• Don't leave generic comments ("Great post!")
• Don't spam your content in every community
• Don't argue aggressively (disagree respectfully)
• Don't automate engagement (bots are obvious and hated)

## Hashtag Strategy

### Platform-Specific Hashtags

Twitter/X:

• Use 1-3 hashtags per tweet (more looks spammy)
• Place at the end of the tweet or inline naturally
• Popular: #webdev #javascript #python #devops #100DaysOfCode #programming #opensource #ai #tech

LinkedIn:

• Use 3-5 hashtags per post
• Place at the bottom
• Mix: 1-2 broad (#softwaredevelopment) + 2-3 specific (#reactjs #frontend)
• Popular: #softwaredevelopment #tech #programming #leadership #startup #ai #machinelearning

Dev.to:

• Use 4 tags (Dev.to format, not hashtags)
• Choose from existing popular tags
• Popular: #javascript #webdev #beginners #tutorial #react #python #devops #career

General Rules:

• Don't create obscure hashtags no one follows
• Research which hashtags your target audience follows
• Monitor hashtag performance and adjust
• Follow trending tech hashtags for real-time engagement opportunities

## Content Scheduling

### Scheduling Strategy

Weekly Content Calendar: ┌──────────┬───────────────────────────────────────────────┐ │ Day │ Content Plan │ ├──────────┼───────────────────────────────────────────────┤ │ Monday │ Twitter: Quick tip or insight to start the week│ │ Tuesday │ LinkedIn: Experience story or framework post │ │ Wednesday│ Twitter: Code snippet or thread │ │ Thursday │ Dev.to: Publish weekly article (if available) │ │ Friday │ Twitter: Fun/lighthearted tech content │ │ Saturday │ Optional: Community engagement, no posting │ │ Sunday │ Plan next week's content │ └──────────┴───────────────────────────────────────────────┘

Scheduling Tools:

• Buffer: Multi-platform scheduling, analytics
• Hootsuite: Enterprise-grade, multiple accounts
• Typefully: Twitter-focused, thread drafting
• Later: Visual planning, Instagram-focused
• Manual scheduling: Native platform tools

### Content Batching

Efficient content creation process:

1. Monthly Planning (1 hour):

   • Review what performed well last month
   • Plan themes for the coming month
   • Identify key dates (releases, conferences, holidays)

2. Weekly Batching (2 hours):

   • Write 5-7 social media posts for the week
   • Create any code screenshots or visuals
   • Schedule all posts using scheduling tool

3. Daily Engagement (15 min):

   • Respond to comments and mentions
   • Engage with others' content
   • Share/retweet interesting finds

This approach gives you consistent output without consuming your entire week.

## Analytics and Measurement

### Key Metrics by Platform

Twitter/X:

• Impressions: How many people saw your tweet
• Engagement rate: (likes + retweets + replies) / impressions
• Profile visits: Are people curious about you?
• Follower growth: Net new followers per week/month
• Link clicks: Traffic to your blog/site

LinkedIn:

• Post views: How many people saw your post
• Engagement rate: (reactions + comments + shares) / views
• Profile views: Increased after good posts
• Connection requests: Inbound requests = content is working
• Article reads: For long-form LinkedIn articles

Dev.to:

• Views: Total post views
• Reactions: Hearts/unicorns/bookmarks
• Comments: Discussion generated
• Reading time: How long people spend
• Followers: Profile followers gained

Cross-Platform:

• Referral traffic: How much traffic does social drive to your blog?
• Email signups: How many newsletter subscribers from social?
• Brand searches: Are people searching for your name/brand?

### What Good Looks Like

For an individual developer building their presence:

Starting out (0-6 months):

• Twitter: 100-500 followers, 1-3% engagement rate
• LinkedIn: 500-1000 connections, 2-5% engagement rate
• Dev.to: 100-500 followers, 50-200 views per post

Established (6-18 months):

• Twitter: 1K-5K followers, 2-5% engagement rate
• LinkedIn: 2K-5K connections, 3-7% engagement rate
• Dev.to: 1K-5K followers, 500-2000 views per post

Influencer (18+ months):

• Twitter: 10K+ followers, 3-8% engagement rate
• LinkedIn: 10K+ connections, 5-10% engagement rate
• Dev.to: 10K+ followers, 2000+ views per post

Don't obsess over follower count. Focus on:

1. Engagement rate (are people interacting?)
2. Quality of connections (are they your target audience?)
3. Referral traffic (is social driving meaningful traffic?)

## Content Ideas Generator

### Evergreen Content Ideas

For any technology/topic, these formats always work:

1. "X things I wish I knew about [technology] before starting"
2. "The mistakes I made learning [technology] (so you don't have to)"
3. "[Technology A] vs [Technology B]: A practical comparison"
4. "How to go from beginner to intermediate in [technology]"
5. "My [technology] setup in 2025"
6. "The most underrated [technology] features"
7. "A day in the life of a [role] at [type of company]"
8. "I built [project] in [timeframe] - here's what I learned"
9. "The [technology] cheatsheet you'll actually use"
10. "Why I switched from [A] to [B] (and what I miss)"

## Quick Decision Guide

When asked about tech social media:
- **"How to start building a presence?"** → Pick 1-2 platforms, post consistently, engage genuinely
- **"What should I post?"** → Share what you learn, teach what you know, tell stories honestly
- **"How to write a good thread?"** → Strong hook, numbered points, code examples, summary + CTA
- **"LinkedIn or Twitter?"** → Twitter for dev community, LinkedIn for career/leadership content
- **"How often should I post?"** → 3-5 times per week minimum, consistency matters more than frequency
- **"My posts get no engagement"** → Check timing, add visuals, engage with others first, be patient (3-6 months)

## When to Use

**Use this skill when:**
- Designing or implementing social media tech solutions
- Reviewing or improving existing social media tech approaches
- Making architectural or implementation decisions about social media tech
- Learning social media tech patterns and best practices
- Troubleshooting social media tech-related issues

**Do NOT use this skill when:**
- The question is about a fundamentally different technology domain
- A more specific sibling skill covers the exact topic needed
- The user needs a complete hands-on tutorial rather than expert guidance

## Output Format

```markdown
# Social Media Tech Analysis

## Context Assessment
[Situation summary and constraints]

## Recommended Approach
[Primary recommendation with rationale]

## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]

## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]

## Next Steps
- [Immediate action item]
- [Follow-up action item]

Example

Input: "Help me implement social media tech for a medium-scale production application"

Output: A structured analysis covering current state assessment, recommended social media tech approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.

Edge Cases

• Legacy system integration: When social media tech must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
• Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
• Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
• Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities