Diseased Open Source Software Community - it's about ethics in Code of Conducts

[Cryonic Haunted Bullets]

View attachment 1142662

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

 

[SpEd Kaczynski]

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

I also get annoyed with that shit, but it does serve a purpose. When you have any kind of a culture there needs to be social mores that dictate what is acceptable and unacceptable and that pushes members of that culture into a direction that benefits that culture while steering people away from thoughts and behaviors that damage the culture. When you get rid of those social mores you often see a culture turn into shit.

I think that ultimately the type of "tough guy programmer" ethos you are pointing out probably has more of a positive than negative effect on the programming subculture. It's certainly better than the "anybody can be a programmer, especially homeless PoC genderfluid tranny hookers!" narrative that gets pushed so much nowadays.

 

[DumbDude42]

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

seething webdev baby detected

at the end of the day there's two options: either people stay tough and enforce gatekeeping according to technical skills and expertise, or people go soft and get overtaken by blue haired genderblobs and all the bullshit drama they bring.
the choice is yours, and if you choose the latter you deserve nothing but contempt tbh

 

[Dr. Sexbot]

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

I'm sorry but I really don't see what you're talking about, can you please explain? Optimizing your code doesn't seem to appear on the "tough guy" list of traits that pop into my head. Maybe I'm missing something.

Now the "brogrammer" thing is pretty annoying (both the archetype and those who whine about it) but I think that's probably more of a temporary demographic blip than anything, at least until SV collapses further. I suspect in a few years that those types will sink to the bottom, leaving little more than a footnote in computer nerd history. (This assumes that they even exist; I've met exactly one person in my professional life who might have met the description, but even that's a stretch. I also do not work in SV, nor could you pay me enough to do so.)

 

[Marvin]

I also get annoyed with that shit, but it does serve a purpose. When you have any kind of a culture there needs to be social mores that dictate what is acceptable and unacceptable and that pushes members of that culture into a direction that benefits that culture while steering people away from thoughts and behaviors that damage the culture. When you get rid of those social mores you often see a culture turn into shit.

I think that ultimately the type of "tough guy programmer" ethos you are pointing out probably has more of a positive than negative effect on the programming subculture. It's certainly better than the "anybody can be a programmer, especially homeless PoC genderfluid tranny hookers!" narrative that gets pushed so much nowadays.

I don't think the "tough guy programmer" shtick pushes people out of programming though.

If anything, it pushes programmers into behaviors that are negatives overall for the software industry.

 

[deus et ursa]

wrt. Open Source, I think the supply of OSS now so severely exceeds the demand, that for most authors it's become solely a wishful-thinking exercise. The GitHub profile as a sort of doll's house where you meticulously dress up each of your (zero-user) libraries as if they are important and industry-ready.

 

[uncleShitHeel]

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

What tough guy image?

Are you telling us you're upset at this MSPaint drawing of a comparision between competent developers and people who warm seats? Look like a cow wandered into its own thread.

 

[clownworld]

i hate the current state of software engineering but i also hate the reactionary "tough guy programmer" ethos espoused by images like this one

Agree to the extent that the packed-#linux-irc-chatroom-toughguy-midwit-who-halfway-responds-to-random-questions-all-day archetype is super fucking annoying who's capabilities are far lower than what they believe them to be. The best engineers you meet tend to spend little energy posturing to others.

wrt. Open Source, I think the supply of OSS now so severely exceeds the demand, that for most authors it's become solely a wishful-thinking exercise. The GitHub profile as a sort of doll's house where you meticulously dress up each of your (zero-user) libraries as if they are important and industry-ready.

Publishing anything open source these days for the purpose of 'wishful-thinking' that it will take off and pick up a ton of users is foolish. It's like a lottery, and you probably won't be able to market it enough to pick up many users, and then what are you going to do if you get them? Turning this into direct income is difficult. Users of your work who don't pay are pests tbh.

You can, though, turn those projects into high income jobs. Going through the motion of polishing a project or library you have written is a very excellent exercise for any dev to go through, and that experience carries over into other elements of ones work. Its useful to remember that many terrible libraries have millions of users. Community interest isn't necessarily a metric of quality. Having some polished projects made public can make an excellent portfolio of what you are capable of, and how you work. It can be a major show when looking for work, and also a good way to make connections when you do it with others.

 

[deus et ursa]

You can, though, turn those projects into high income jobs. Going through the motion of polishing a project or library you have written is a very excellent exercise for any dev to go through, and that experience carries over into other elements of ones work. Its useful to remember that many terrible libraries have millions of users. Community interest isn't necessarily a metric of quality. Having some polished projects made public can make an excellent portfolio of what you are capable of, and how you work. It can be a major show when looking for work, and also a good way to make connections when you do it with others.

This is true but it's also why the situation gets screwy. When the primary goal is career concerns, but that is not disclaimed at all in the way that projects are presented. On GitHub, there's so much low-effort and trivial code cosplaying as industry-grade best-thing-since-sliced-bread.

Basically when an activity becomes more about the meta, things are liable to get gross.

 

[Sir Wesley Tailpipe]

This is true but it's also why the situation gets screwy. When the primary goal is career concerns, but that is not disclaimed at all in the way that projects are presented. On GitHub, there's so much low-effort and trivial code cosplaying as industry-grade best-thing-since-sliced-bread.

Basically when an activity becomes more about the meta, things are liable to get gross.

I’d agree if you didn’t use the word “gross”. Are you 5?

 

[Stock Image Photographer]

Basically when an activity becomes more about the meta, things are liable to get gross.

Do you mean "gross" in the maintainability sense or the overall ethical sense? I'm asking because I agree with both. There are a ton of github projects that clearly only exist because someone thought they would look good on a resume, which is borderline lying to a future employer because it means you're a cynic who doesn't care about good code. In the event that one of these projects actually does become popular, the owner will often fail to maintain it after they've gotten what they want out of it (i.e. a good job), which is scummy from a maintainability perspective. There's a lot of that in the Rust community, where someone will make this really useful library in Rust, only to fail to maintain it because they fell off the Rust hype-train and now everyone is stuck either using old, shitty code or doing the library over again.

 

[deus et ursa]

I’d agree if you didn’t use the word “gross”. Are you 5?

I am a big boy and I show my maturity by interrupting conversations if I hear a turn of phrase that mildly annoys me.

Do you mean "gross" in the maintainability sense or the overall ethical sense? I'm asking because I agree with both. There are a ton of github projects that clearly only exist because someone thought they would look good on a resume, which is borderline lying to a future employer because it means you're a cynic who doesn't care about good code. In the event that one of these projects actually does become popular, the owner will often fail to maintain it after they've gotten what they want out of it (i.e. a good job), which is scummy from a maintainability perspective. There's a lot of that in the Rust community, where someone will make this really useful library in Rust, only to fail to maintain it because they fell off the Rust hype-train and now everyone is stuck either using old, shitty code or doing the library over again.

Yes that is a good summary. In the large, I just meant the development ecosystem becoming more of an incoherent mess. Of course it's natural that it's somewhat chaotic, but this isn't really chaos either, when large numbers of participants are trying to act the same role. "Too many chiefs and not enough indians"

 

[clownworld]

This looks far more like a correction for package consumer assumption than it does authors. Responsibility of whats in your dependency tree is yours and yours alone. If you aren't paying for it, you probably should make sure someone else is if you want to hitch a free ride. Otherwise you are walking into the very situation you want to avoid (and yes! this situation is exponentially more likely now!).

I think it used to be the case that the 'open source' packages that you would actually see were ones with clearly enough time and knowhow to bootstrap project infrastructure, and long term viability through whatever employment arrangement was needed behind the scene to maintain it. The bar was higher to publish and often this effort was hidden. Now with Github/Lab and all of the free CI and website hosting, that barrier to publishing is much lower, so whatever proximal assessment people used to use was no longer correlated to the outcome they want.

From my perspective, the vast majority of the category of immorality we talking about falls more in the pattern of downstream consumers with poor assumptions about upstream responsibility. Someone (usually well known and 'prolific') writes a 'good' package for something they are working on, then a consumer LARPS industry readiness on something they are working on, whether that designation is warranted or not, and then assume upstream wants that responsibility when a dependency issue shows up upstream. From my xp, it's very rare for someone to write a complete looking package as a hobby or side project, and misrepresent it's significance in their professional life, without exposing some larger order personality disorder (good to know!).

I guess where we could agree is that people should be more upfront about their intentions for a package, given the signal to noise ratio around published packages these days. Print on demand books are a good thing, despite most of what gets printed is utter garbage. From the perspective of societal infrastructure, we do need more gatekeeping, bully and general professionalism when it comes the seriousness of software deployments that affect everyone. But most software isn't serious, its VCs trying to do company flips, so the maturity of the industry follows that money.

 

[Stock Image Photographer]

From my perspective, the vast majority of the category of immorality we talking about falls more in the pattern of downstream consumers with poor assumptions about upstream responsibility. Someone (usually well known and 'prolific') writes a 'good' package for something they are working on, then a consumer LARPS industry readiness on something they are working on, whether that designation is warranted or not, and then assume upstream wants that responsibility when a dependency issue shows up upstream.

My question is then what constitutes the gold standard of reliable libraries? Would it just be stuff published by organizations like the FSF or corporations? In that case, isn't there a very large burden put upon small developers to create most of the libraries they need themselves, leading to massive duplications of effort across any given scope or programming language? I get your point about needing to be responsible for your own dependency tree and I completely agree, but I think we would all be better off if there was some more shame associated with abandoning a library you brought into the world.

 

[clownworld]

My question is then what constitutes the gold standard of reliable libraries? Would it just be stuff published by organizations like the FSF or corporations?

Depends who you ask! Anything the FSF has their hands on is leftover from a time gone. They are a complete joke at this point from my perspective. A leftover grift from a bygone era. Totally ineffective. Corporate code is generally popular and 'funded', but can be quite terrible in execution on average.

In that case, isn't there a very large burden put upon small developers to create most of the libraries they need themselves, leading to massive duplications of effort across any given scope or programming language?

This is jus the way it works. People generally prefer a libraries written in their preferred language over foreign language libraries.

but I think we would all be better off if there was some more shame associated with abandoning a library you brought into the world.

100%. Too bad its becoming increasingly difficult to criticize anyones actions without breaking CoCs or pissing someone off who can grief your carrier. Generally, though find an operating pattern in this environment is going to be a better use of ones time

Anyway, this kind of getting boring. Back to gawking at retartds.

 

[AmpleApricots]

There's also the often overlooked option of touching computers for fun without making it a job. I'd highly recommend that one.

 

[Nigger Rick]

but I think we would all be better off if there was some more shame associated with abandoning a library you brought into the world.

A few years ago, the common meme in the node community was to encourage publishing micro modules, misguided after the unix philosophy of "do one thing, and do it well". People made several new projects in which the actual js code consisted of no more than 10 lines. Most of these were simple mundane functions like odd/even check, type checks, left-pad, etc.

Here's a more extensive list: https://medium.com/@areyou/are-you-kidding-me-cf7bbb348ed0

What ended up happening with most of these "prolific" developers, as they were called, was that they ended up getting overwhelmed by the number of issues and pull requests their tiny projects were getting, and ultimately ended up abandoning them. With no notice on their repo. Although now that I'm checking back on some of the projects linked in that medium article, some of them have been archived.

npm loves pointing out how many more packages it has compared to other package registries.

npm turns 10

It's our ten-year anniversary! To celebrate, we thought we’d share some milestones we’ve reached along the way. Thank you to all who have helped…

vimeo.com

 

[AlexJonesGotMePregnant]

A few years ago, the common meme in the node community was to encourage publishing micro modules, misguided after the unix philosophy of "do one thing, and do it well". People made several new projects in which the actual js code consisted of no more than 10 lines. Most of these were simple mundane functions like odd/even check, type checks, left-pad, etc.

Here's a more extensive list: https://medium.com/@areyou/are-you-kidding-me-cf7bbb348ed0

What ended up happening with most of these "prolific" developers, as they were called, was that they ended up getting overwhelmed by the number of issues and pull requests their tiny projects were getting, and ultimately ended up abandoning them. With no notice on their repo. Although now that I'm checking back on some of the projects linked in that medium article, some of them have been archived.

npm loves pointing out how many more packages it has compared to other package registries.

npm turns 10

It's our ten-year anniversary! To celebrate, we thought we’d share some milestones we’ve reached along the way. Thank you to all who have helped…

vimeo.com

Fuck node_modules to fucking hell

 

[byuu]

There's a funny recent bug report for npm:
npm sends a huge amount of requests because of all the little dependencies and the requests use some non-standard HTTP referrer that looks suspicious to Cloudflare's algorithms.
So it ends up looking like a DoS attack to Cloudflare and their protection kicks in and people are getting "Too many requests" errors when they're fetching their bloated shit.

 

[clownworld]

Fuck node_modules to fucking hell

View attachment 1155076

This is especially true (and where the trend really got out of hand) for any react/babel/webpack/typescript/eslint/prettier projects and is largely a cultural byproduct of these frameworks and the people behind them. Should npm just fail after a certain number of deps? Limit dependency tree depth? EOUTOFMODULES

There's a funny recent bug report for npm:
npm sends a huge amount of requests because of all the little dependencies and the requests use some non-standard HTTP referrer that looks suspicious to Cloudflare's algorithms.
So it ends up looking like a DoS attack to Cloudflare and their protection kicks in and people are getting "Too many requests" errors when they're fetching their bloated shit.

Go's new module system has to clone down every dependency from version control, though at least it caches them in a shared system cache and performs a shallow clone, and doesn't duplicate files all over your system. It's the nature of nested dependency management. I predict this will be a growing trend in all language module systems over time.