DEV Community: B Donald Harris

What Building a Social Platform Taught Me About Software Discovery

B Donald Harris — Sun, 27 Sep 2026 20:46:52 +0000

When I started building BitVoices, I knew why I wanted it to exist before I knew exactly what it needed to be. The idea grew naturally out of the mission behind NotableBIT: amplifying Black excellence in tech. I wanted Black technologists to have a place where we could be visible, share what we were building, celebrate achievements, publish articles, make connections and see more of ourselves represented in technology.

At the time, my mental model for an online community was pretty straightforward. A social platform seemed like the natural way to create that space, so the first version of BitVoices took shape around profiles, posts, comments, reactions, follows, notifications, videos, news and a feed. It looked like a social network because that's what I understood an online community platform to be at the time. What I didn't understand yet was that building the software would become part of discovering what the software was supposed to be.

When the software doesn't feel right

The more I built BitVoices, the more it started to feel like everything else. One of the things that really started bothering me was the news feed. I found myself spending time every day curating articles about Black people in technology so there would be fresh content on the platform, but almost nobody was reading them and, realistically, they probably weren't going to. I could continue finding more content and adding more features, but neither answered the question that had started bothering me: What is BitVoices actually supposed to be?

I started asking more fundamental questions. Why am I building this? What am I expecting builders to actually do when they get here? What should they get from being here? What should happen because BitVoices exists that wouldn't otherwise happen?

I spoke with people about it. Low Key, my ChatGPT agent, and I had many conversations about it. I also started looking at other modern platforms to understand what they were doing and how they were thinking about community. I wasn't necessarily looking for features to copy. I was trying to understand what fit what I was building and, probably more importantly, what didn't.

As I got clearer about the purpose, I started seeing possibilities that weren't obvious when I was thinking primarily about building a social network. The question was becoming less about what content should be in the feed and more about what a builder should be able to accomplish by being part of BitVoices. That distinction changed the software.

The product changed as my understanding changed

Builder HQ began shifting the center of BitVoices away from the feed and toward the builder. I had started moving away from the "feed-first" assumptions behind the original platform and thinking about a different set of questions. Instead of primarily thinking about what someone wants to post or consume, I was thinking about what they're building, what they need, what they can offer another builder, what needs their attention and who in the network might be able to help them.

I was also thinking more deeply about what community could actually mean in this context. What could builders offer each other beyond reading and reacting to one another's posts? What relationships could form because two people found each other here? Could builders with complementary skills decide to work together on something? Could a team form? Could a company eventually come out of a relationship that started because two builders met on BitVoices? I didn't know what would happen, and I still don't, but those possibilities were much closer to what I wanted the platform to enable.

The original social features didn't need to disappear. Posts, comments, reactions, articles and connections still serve a purpose. What changed was my understanding of their role. They were no longer the organizing idea behind the product. The network itself, and the relationships that could develop within it, had become much more important.

That also changed how I thought about Hubs. Builders don't only need a network of people. Sometimes they need a place to gather around a particular interest, technology, business model or geography. That thinking eventually led to Hubs such as AI Builders, SaaS Builders and Tulsa Builders.

Even there, the discovery continued. The interesting problem wasn't simply how to add groups to the platform. It was understanding what gives builders a reason to participate once they're there. That has led me to think about things like prompts and Hub Check-ins that can create rhythm, accountability and collaboration without turning every community into a formal program.

Somewhere through this process I arrived at a phrase that now influences how I think about BitVoices: Community is culture, not features. That's different from saying features don't matter. Obviously they do. I'm still building software. But I can build profiles, feeds, messaging, reactions, groups and every other feature we associate with online communities and still not create a community worth participating in. The features have to support the culture, relationships and purpose of the community rather than becoming substitutes for them.

I was listening to the software

Months later, I finally found language for what had been happening. I had been listening to the software. I don't mean that in some mystical sense where the application suddenly developed an opinion about its product roadmap. 😂 I mean that the process of building, operating and observing the software was producing information that I didn't have when I started.

The news nobody was reading was information. My frustration with spending time curating it was information. Conversations with people were information. Watching how the platform was being used was information. Even the fact that I kept returning to the same questions about BitVoices' purpose was information.

Building in public amplified that process because BitVoices was publicly live in both forms. People saw the earlier feed-centered social platform, and they've been able to watch it change as my understanding of the product has changed. I've been talking about what I'm building while simultaneously building and operating it. I didn't disappear for a year, figure everything out and then unveil the answer. I was discovering BitVoices while BitVoices was already alive. That's what I've started thinking about as software discovery.

We usually put discovery before implementation. We gather requirements, understand the problem, make architectural and product decisions, and then build the software. I still believe that work matters. Software discovery isn't an argument for skipping it and figuring everything out while you're coding. It's an acknowledgement that discovery doesn't necessarily stop when construction begins.

Once an idea becomes working software, you can interact with assumptions that previously existed only in your head, a document or a mockup. You can operate the thing. Other people can use it. You can see where you're spending effort that isn't producing value. You can notice where the software technically works but somehow doesn't fit the purpose you thought you understood.

The implementation itself becomes another source of information. That's what happened with BitVoices. I didn't discover that the original social features were bad ideas. BitVoices still has a feed, profiles, posts, articles, comments, reactions and many of the things I started building in the beginning. I discovered that I had mistaken some of the mechanisms of an online community for the community itself.

I'm still discovering what BitVoices is becoming. The difference is that now I recognize discovery as part of building it. Requirements, conversations and research can tell me a lot about what software should be, but sometimes I also need to build enough of it to hear what the software has to say.

Follow Existing Patterns” Is Not Enough Context for an AI Coding Agent

B Donald Harris — Tue, 28 Jul 2026 22:33:35 +0000

Many engineering teams give AI coding agents instructions that sound perfectly clear:

Follow existing patterns.

Do not introduce new abstractions.

Use the established architecture.

Follow project standards.

A human developer can usually interpret those instructions because the words are only part of the communication. The developer also brings professional experience, familiarity with the codebase, conversations with teammates, code-review feedback, and an understanding of how the organization makes engineering decisions.

The human fills in the missing context.

An AI coding agent does not necessarily make the same expansion. It may recognize the existing pattern in one layer while overlooking another place where the same principle should apply. It may reproduce the visible structure of a nearby implementation without understanding why that structure exists.

This does not mean general engineering principles are useless. It means they are incomplete when they stand alone.

A useful instruction must route the agent toward authoritative context. It should identify which architecture guide, repository standard, testing guidance, data-access convention, security requirement, or implementation example the agent must review before beginning the task.

The goal is not to copy every rule into every prompt. That creates duplication, contradiction, and drift. The goal is to maintain canonical engineering documentation and explicitly direct agents toward the relevant sources.

This is also why some criticism of AI-generated software misses part of the problem.

Critics are right to object to insecure code, fragile systems, unnecessary abstractions, inconsistent implementations, and applications that nobody can maintain. But many of those failures are not proof that AI has no useful role in engineering. They are signs that organizations are using agents without adapting how engineering knowledge is communicated.

Experienced engineers often carry large amounts of organizational knowledge implicitly. They know which patterns are intentional, which compromises are temporary, which architectural boundaries matter, and which production lessons must never be forgotten.

AI systems do not inherit that cultural understanding automatically.

Organizations have to digitize it.

That means turning tribal knowledge into explicit organizational intelligence that can guide both humans and AI systems. It means preserving not only what a codebase does, but why it works the way it does and which decisions should not be casually reversed.

The teams that do this well will not merely generate code faster. They will make the quality standards of experienced engineers available at the point where AI-assisted work actually occurs.

I explore the complete argument in:

The Myth of General AI Instructions

Originally published on bdonaldharris.com.

Why I’m Building BIT Voices in Public

B Donald Harris — Wed, 18 Mar 2026 13:36:24 +0000

After two decades working in software engineering, one thing became very clear to me:

There are incredible Black technologists building powerful things — but their stories rarely reach the broader tech conversation.

So I started building a platform to change that.

It’s called BIT Voices Network.

The goal is simple: create a place where Black technologists can share what they’re building, what they’re learning, and what they’re discovering.

In this article I want to share:

• why I decided to build the platform
• what I’ve learned so far
• what comes next

Black Tech Stories Deserve Their Own Stage

I Built a VS Code Extension to Simplify .NET Project Creation

B Donald Harris — Wed, 08 Oct 2025 18:55:10 +0000

I Built a VS Code Extension to Simplify .NET Project Creation

After years of typing the same dotnet new commands over and over, I finally decided to do something about it. Today, I'm excited to share .NET Scaffolder by NotableBit—a VS Code extension that makes creating .NET projects feel effortless.

🤔 The Problem

As a .NET developer, how many times have you done this?

dotnet new webapi -n MyProject -f net8.0
cd MyProject
dotnet new sln
dotnet sln add MyProject.csproj
git init
git add .
git commit -m "Initial commit"
# ... and so on

It's tedious, error-prone, and breaks your flow. You have to:

Remember exact template names (webapi, blazorwasm, xunit, etc.)
Type out full paths or navigate directories
Manually configure Git
Remember which .NET version you want

There had to be a better way.

💡 The Solution

.NET Scaffolder brings visual, intuitive project creation to VS Code. Instead of memorizing CLI commands, you get:

Tree View of Templates - Browse 12+ templates organized by category
Interactive Configuration - Fill out a form, not a command line
Browse Button - Click to select folders (no more typing paths!)
Hybrid Git Integration - Choose your workflow
One-Click Creation - Watch your project scaffold in real-time

✨ Key Features

📚 12+ Project Templates

All the templates you use regularly:

Console Apps: Console, Worker Service
Web Apps: Web API, MVC, Razor Pages, Blazor Server, Blazor WebAssembly
Libraries: Class Library, Razor Class Library
Tests: xUnit, NUnit, MSTest

🌿 Flexible Git Integration

Choose what works for you:

Local Only - git init + commit, no remote
GitHub CLI - Creates repo and pushes automatically
Custom Remote - Push to GitLab, Bitbucket, self-hosted
No Git - Skip it entirely

🎯 Framework Selection

Support for .NET 6.0, 7.0, 8.0, and 9.0—all in a dropdown.

📦 Solution Support

Automatically creates solution files and adds your project to them.

🔒 Privacy First

Telemetry is anonymous and respects VS Code's telemetry settings. No tracking, no surprises.

🛠️ How It Works

Here's the full workflow:

1. Open the Extension

Click the .NET Scaffolder view in your VS Code sidebar.

2. Select a Template

Browse categories and click any template to configure it.

3. Configure Your Project

Fill out the interactive form:

Project Name - Type it in
Project Path - Click "Browse..." to select a folder
Framework - Choose from .NET 6-9
Git Option - Pick your workflow
Create Solution - Toggle on/off

4. Watch It Build

Real-time progress tracking shows each step.

5. Start Coding

Your project opens ready to go—everything configured!

🤖 Full Transparency: AI-Assisted Development

Before diving into the technical details, I want to be upfront: I built this extension with AI assistance (Claude/ChatGPT). This was a collaborative effort where:

I provided:

The vision and requirements
Architecture decisions
Feature specifications
Testing and validation
Final code review and approval

AI helped with:

Code generation and boilerplate
TypeScript implementation
VS Code API integration
Documentation writing

This is increasingly how modern development works—AI as a powerful co-pilot, but human judgment driving the ship. Every line of code was reviewed, tested, and understood before making it into the extension.

Why share this? Transparency matters. AI-assisted development is a tool, not a shortcut. The extension is no less valuable because AI helped write it—just like using Stack Overflow, libraries, or frameworks doesn't diminish a developer's work.

🎓 What I Learned

Building this extension taught me a lot:

TypeScript & VS Code API

Working with webviews, tree views, and VS Code's extension API was challenging but rewarding. The documentation is excellent once you understand the patterns.

Cross-Platform Considerations

Making sure Git integration works on Windows, macOS, and Linux required careful testing. The gh CLI made GitHub integration much simpler than I expected.

User Experience Design

Balancing power and simplicity was key. I wanted advanced features (like 4 Git options) without overwhelming users. Radio buttons and conditional fields solved this nicely.

Privacy Matters

Developers care about privacy. Making telemetry opt-in via VS Code's settings was non-negotiable.

🚀 Technical Stack

For those interested in the implementation:

Language: TypeScript
Framework: VS Code Extension API
UI: Webview API with HTML/CSS/JS
Build Tool: TypeScript Compiler
Version Control: Git + GitHub
Publishing: vsce (VS Code Extension Manager)

Key APIs used:

vscode.window.createTreeView() - Template browser
vscode.window.createWebviewPanel() - Configuration forms
vscode.window.showOpenDialog() - Browse button
child_process.exec() - Running dotnet and git commands

📈 What's Next?

The roadmap is already filling up! Here's what's coming:

v1.4.0 (Planned)

Add to Existing Solution - Create a new project and add it to an existing .sln file
Detect workspace solutions automatically
Maintain consistent project structure (src/ folder patterns)

Future Ideas

Custom template support
Project preview before creation
NuGet package addition during setup
Docker configuration generation
Template favorites

🎯 Try It Out!

Ready to scaffold your next .NET project in seconds?

Install via VS Code:

ext install notablebit.dotnet-project-creator

Or search: .NET Scaffolder in the Extensions marketplace

Links:

🌐 VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=notablebit.dotnet-project-creator
💻 GitHub Repository: https://github.com/bdonaldharris/dotnet-project-creator
📋 Documentation: https://github.com/bdonaldharris/dotnet-project-creator#readme

💬 Feedback Welcome!

This is my first published VS Code extension, and I'd love to hear your thoughts:

What features would make your workflow smoother?
What templates are you missing?
Any bugs or issues to report?

Drop a comment below or open an issue on GitHub!

Building tools that developers actually want to use is incredibly rewarding. If this extension saves you even 30 seconds per project, it's worth it.

Happy scaffolding! 🚀

Follow me for more developer tools and open-source projects. More extensions coming soon!

Connect:

GitHub: https://github.com/bdonaldharris/dotnet-project-creator
Marketplace: https://marketplace.visualstudio.com/publishers/notablebit