Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Comments on How should we approach a programming site or sites?
Parent
How should we approach a programming site or sites?
We have a suggestion for a site for professional coding, and software engineering and computer science also have some interest, and there are overlapping suggestions for cloud technologies and single-board microcontrollers. It seems likely that participants here have interests in other related areas too. How shall we approach this cluster of topics? Do we want one big tent -- a single programming site? Do we want a big tent and some specialized spin-offs -- what seems to have happened on SE? Do we want to plan for more focused communities from the start -- and, if so, what would they be?
I was an infrequent participant on SO; I have around 1200 rep after many years of passive, occasional posts. I don't have the right experience there to say with any certainty what worked well and what didn't. It appears to me that SO doesn't really have a community; it's too big for that. It might have sub-communities; I don't know how strong they are and how much they interact. And it might have had a community when it started; they're 11 years in now and things have changed. We'll be starting small; we are not operating at SO scale (yet). An advantage of a single site (or small number of clearly-differentiated sites) is that people know where to go; Balkanization where there are two-dozen different sites depending on which libraries or languages or tools you're using probably does not serve the programming community either.
I think a core diffentiator for Codidact is that we're putting community first from the beginning. We want to do what's best for the people participating here, whether that's one site or a handful or many (or one site and later spin-offs). We also have some tools they don't have over on SE, including categories and integrated blogs or wikis. And we're actively working on an open-source platform, so if it turns out there's something we need and don't have, we don't have to wait 6-8 years for somebody to consider the feature request.
It seems clear to me that there is interest in a place for questions about programming -- code, tools, design, and maybe processes. How shall we address that interest? What shall we build?
--
We resolved this by creating Software Development with broad scope. There's even a Code Review category. If the community grows to a size that's hard to manage and subsets want to spin off later, we can do that.
I've had some thoughts about this, which I'll try to coalesce into something resembling an answer. > Codidact is grow …
4y ago
Based on all the feedback here (and also on the related site proposals), I put forth this proposal: Create a single S …
4y ago
I don't know enough to have a full answer, but one differentiation that I think makes sense is for embedded systems prog …
4y ago
I want to offer a more community- and not topic-orientated answer to this question. Basically, you could rephrase the qu …
4y ago
Three problem is that a single supersite is a mess that is difficult to build anything other than a "codidact community" …
4y ago
I don't know about eventually, but while codidact is still getting started, it's better to not splinter communities. …
11mo ago
Coming at this from a totally different perspective here. I think all of the above mention many great points but I can't …
4y ago
Lessons learnt from the past I've been at SO pretty much from the start. It is true that SO has sub-communities in a …
4y ago
This is less than a proposal: merely an idea. That's because I've not used SO much and don't know what works and what do …
4y ago
To answer the original question of how to approach programmer sites, I think a number of important features should be co …
4y ago
Post
I don't know enough to have a full answer, but one differentiation that I think makes sense is for embedded systems programming versus more commonplace programming (desktop, web, server, ...).
The reason for that is that embedded systems programming often has very different constraints than what most programmers are used to working with. Very little memory (for both code and data), slow processor speeds, and extremely limited user I/O (a couple of pushbuttons and lights, maybe a few-digits seven-segment LCD display if you're lucky), are all common constraints that the typical web developer does not really need to contend with.
Granted, more and more systems that used to be truly embedded are now running some Linux variant on a single-chip (or even multi-chip) nearly-ordinary computer, just because that's available and easier to work with. But I do believe there's going to be a demand for true embedded systems programming for a long time.
On SE, this was solved by explicitly making bare-metal or RTOS firmware development on topic on Electrical Engineering SE. It's not off topic on SO, since it's still about programming, but if you're looking for an embedded systems developer expert answer, your chances have probably been better on EESE than on SO. (Note: My experience on EESE mirrors yours on SO, as mostly a lurker.)
I don't know if the best way to separate these is the way it's historically been done on SE, or if it would be better to separate based on available computing resources; with highly resource-constrained platforms having a specific place for their questions, and others having somewhere else.
It's reasonable to assume that any site that caters specifically to embedded systems programming, or even highly-resource-constrained-systems programming, won't see anywhere near the amount of traffic of a more mainstream programming site. The field just is much smaller. That, however, doesn't mean that the questions don't have legitimacy.
1 comment thread