Librarianon

Your local Librarianon

  • He/Him

Writer, TF Finatic, Recohoster, and Game dev. Wasnt able to post here as much as I liked, but I'll miss it and all of yall. Till we meet again, friends!


Bigg
@Bigg

I think a person's knowledge that There Are Precisely Two Programmers On Staff and what that means in terms of the cultivation & evolution of a live social network does a pretty reliable job of informing how said person might react to what they consider an important site feature taking a long time to manifest. This site's userbase has a very high density of people who understand computers, technology, and long-term collaborative projects, and as such to people who don't have that experience it might seem like @staff receive a very high degree of "blind faith" (or whatever you'd like to call it) and that criticisms of @staff's priorities are met with a (relatively) great amount of backlash and rebuttal.

To understand why this is, let's take a look at what there being Only Two Programmers means:

  • To begin with, understand this is not to discount the contributions of the two non-programmer members of @staff (who do site visuals/design and support management, respectively). Indeed, their contributions are every inch as vital as their colleagues, and the site would not look, feel, or function as well as it currently does without them.
  • However, it must be understood that There Are Only Two Programmers. I know I'm saying it a lot but it is very very important that people who read this understand that There Are Only Two People On @staff Who Can Make Changes To The Site's Codebase And Thus Implement New Features. Just two of them! Just enough for a game of tennis! One, and then the other, and that's it.
  • It is vitally important that a project like this have at LEAST two programmers, because when one programmer writes code that they intend to publish to the codebase, they must have another programmer check their work, or perform a "code review". Publishing untested code to a live project as complex as Cohost is a very, very, very bad idea, no matter how good a programmer you think you are. Mistakes still make it through even with review, but they are far, far less common.
  • Cohost has two programmers. Only two of them! Did you forget?
  • The ironclad necessity of performing code review means that the programmers can never truly take time completely off. Even when one is technically on vacation, they must still review the other's code before it can be published, or else risk introducing site-breaking behavior and endangering the livelihoods of all 4 members of @staff.
  • Gee whiz! That sounds very tiring and stressful!
  • There will be times when, due to sickness or other unforeseeable emergencies, a programmer will not be able to perform code review. This means that any features either programmer is working on will be delayed - one because they cannot work, and another because their work cannot be reviewed.
  • I haven't even mentioned that the work that the programmers are doing would be difficult and time-consuming even absent the ever-present spectre of code review. Creating a feature-rich website that works, let alone works WELL, across a wide variety of devices and browsers is very, very difficult work. It requires constant maintenance - bugs that they didn't catch crop up constantly, tools that they use change, outside factors might hammer the site and the programmers need to respond to all of it. The two programmers who are responsible for creating new website behaviors are the same two programmers who are responsible for site maintenance. When programmer time is being spent maintaining the website, it is not being spent building new features. And with somewhere north of 100k users, the website needs a LOT of maintenance.
  • The site's two programmers are not JUST programmers. They don't get to simply write code all day and then clock out. They are, along with the two non-programmer members of @staff, responsible for the site's communications, community management, accountancy, project management, and so on. Writing update posts, balancing the books, meeting with other @staff members, securing funding - all of this also represents time that the programmers must necessarily spend NOT writing new features for the website.
  • In order to seek sustainability and reduce the amount of debt they take on, @staff do not pay themselves especially well for the work that they do. Senior-level developers with analogous skillsets and analogous levels of responsibility would make somewhere from 40,000-80,000 USD/year more than what @staff are currently making (depending on location).
  • To sum up: the site's programmers (the two of them) are taking a significant pay cut to do the extremely difficult work of building and maintaining a porn-friendly, leftist-friendly, fascist-hostile social media website that does not serve ads, harvest data, or cook your brain with metrics within the framework of a worker's collective, work that they cannot ever truly take time off from unless rendered effectively disabled by circumstances beyond their control.
  • If one of the two (2) programmers becomes too sick to work for an extended period, gets burnt out and has to quit, or is hit by a bus, development of new website features will come to a complete stop and indeed the future of the website will be in jeopardy.
  • It is not possible for a sympathetic, enthusiastic end user of Cohost to protect the two programmers who work on this website from becoming sick, or from being injured, or from dying.
  • It IS possible for a sympathetic, enthusiastic end user of Cohost to do their small part to protect the two programmers from burnout by running interference on petulant, ill-informed, will-to-carry-on-sapping complaints from users who consider it appropriate to hold said two (1+1) programmers to the same feature delivery standards as billion-dollar multinational tech conglomerates (many of whom's products do not even match Cohost's full existing feature-set). So, many of them do!

This is not a "don't ever complain or criticize" post, and if you choose to read it as such you are a dolt. This is a "there are two programmers on the Cohost staff" post. Criticize all you want, but allow your criticism to be informed by the fact that there are two individual human programmers working on this website - if you don't, then don't be surprised when you get an earful from people who understand exactly what that means.


You must log in to comment.

in reply to @Bigg's post:

I've been staying away from the discourse so I get if it's gotten really aggressive but I need to understand this. Why not acknowledge that no dark mode is a real issue, even without providing an estimate on when it'll be done? I think people got the impression they don't care, and as much as the fun features are neat, accessibility should come first. This is a place where we can expect that kind of care, unlike social media that's basically just being watched by bots at this point.

That said damn I had no idea this site had 100k users, I figured it was 15-20k lol

I mean you're implicitly asserting that the team is not doing important work though; "fun features are neat but accessibility should come first". They communicate a lot but how should "we're working on it but it's deprioritized compared to (twenty other things that may be critical for any number of reasons)" when people are basically dismissing anything that isn't My Feature Request as basically screwing around?

Yeah it's unfortunate, but I think Accessibility takes priority. While I agree with people proposing stuff like a silence/block list, the lack of that doesn't actively prevent anyone from using the site.

tbh, accessibility is new to a lot of people. most sites don't care about it, and we went a while here with people using Alt Text for funny gags instead of anything helpful. I wanna say that's pretty rare nowadays - people forget to do it, but the culture's shifted. I'm just optimistic that kind of culture shift can happen as people move off twitter and stop thinking in PVP mode.

Accessibility take priority is a nice sentiment but it's literally non sustainable without prioritization of which accessibility features to implement, and which to defer to an uncertain future. And that has to be weighed against the ability for the website to survive the next year. Which they have been very open in showing is not a given. Accessibility features are often very difficult, especially something that affects literally the entire website. And you can't spend time building those features if you need to build features that make money.

"Dark mode" also represents a more difficult set of changes than people might appreciate because there literally Does Not Exist a set of standardized best practices for it. Despite the tenor in which it's discussed on here, dark modes are typically treated less as an "accessibility" feature and more as an "interface customization" feature, meaning that dark mode behaviors vary widely from situation to situation. The lack of pre-existing best practices greatly increases the amount of frontloaded design and research work that must be done before anything can be implemented & published, since making changes to features in a live environment is far more costly than otherwise.

Like, dealing with transparent images is the first thing I thought of on this. And, as always, there is an XKCD for this. Also, preempting this, no, I am not calling it virtually impossible. Just harder than it fracking looks, especially on a platform that needs to scale and especially if you need to push it as an accessibility feature.

There is a kind of person who decides what gets prioritized for others and gets listened to. Unfortunately that is typically called a "manager".

As for alt text, I must be seeing very different posts than you are. I can't even remember the last time I saw an image with joke alt text. Granted, I see a lot of pictures without alt text too, but describing a cat picture with something more than "cat" requires a poet.

as a chronic burn-out i can attest that doing "fun" stuff at work is sometimes the only thing i can face doing in a day, or the only small win i can get for myself to try to get the ol' dopamine pump primed again. i think devs would like this site to keep existing as much as the rest of us and are no doubt prioritizing perfectly reasonably considering that.

as a side note this is my first time hearing that dark mode is a literal access need. something to bear in mind in my practice going forward, i suppose.

I just want to say it's new to me too, but I've seen it enough that I don't think people are just being flippant and using it as a way to get dark mode. Doesn't help that some people have made using dark mode their annoying personality trait (I like it on most sites, but sheesh).

As a programmer that does PR, PR is a soul crushing endevour that will sap your ability to do literally anything else. No matter how good at it you are. No matter how much experience you have in it. It is simply impossible to write a "correct" post that will not take more time to re-explain and explain. There are always people that will not like your answer. You literally cannot please everyone. People say that so much it's cliche, but the reality of it is incredibly mind numbingly hard to deal with. It's often simply faster to not say anything at all. Doing PR takes huuuuge amounts of developer time away from actual development. And no matter how friendly and personal the PR might seem, it's still Doing PR™.

background: i am technical and have worked on, with, and managed teams in the single digits

i have seen many tiny teams do incredible things, the team on cohost is no exception

i have also seen a lot of people dogpile onto others who have made reasonable criticisms and requests or expressed valid frustrations

(i have not experienced this myself in my own complaint posts, but i have seen it elsewhere and it can have a chilling effect)

i agree that people posting public complaints - like you have here - should remember the other people who could be impacted by it, and they should try to be constructive

but also venting on a social site is an entirely valid activity

i do not agree with anyone being mean to staff, here or elsewhere (with few noted exceptions)

but i also am not comfortable with justifying people being mean to someone who complains with the implication that they would not be complaining if they understood

"don't be surprised when you get an earful from people who understand exactly what that means"