this post was submitted on 21 Mar 2025
1381 points (98.3% liked)

Programmer Humor

21776 readers
1763 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] buddascrayon 7 points 3 hours ago

Oh, they have new functionality. It's all in the back end, detailing everything you do and sending it to the parent company so they can monetize your life.

[–] courval 7 points 12 hours ago

Performance/optimisation wise is an environmental catastrophe..

[–] [email protected] -2 points 7 hours ago (1 children)

Most resources are not consumed by wonky code or dependencies. Most resources are consumed by images and sounds.

[–] elfin8er 1 points 4 hours ago (1 children)

Surely it depends on the specific software.

[–] [email protected] 2 points 2 hours ago

I imagine the ability for an app to watch me take a shit consumes about the same resources regardless of platform.

[–] UnfortunateShort 25 points 20 hours ago (1 children)

Because companies give zero fucks. They will tell you they need tons of IT people, when in reality they want tons of underpaid programmers. They want stuff as fast and cheap as possible. What doesn't cause immediate trouble is usually good enough. What can be patched up somehow is kept running, even when it only leads you further up the cliff you will fall off eventually.

Management is sometimes completely clueless. They rather hire twice as many people to keep some poorly developed app running, than to invest in a new, better developed app, that requires less maintenance and provides a better user experience. Zero risk tolerance and zero foresight.

It still generates money, you keep it running. Any means are fine.

[–] rhadamanth_nemes 2 points 17 hours ago

Ironically the management that does have a clue often is hamstrung somewhere up the chain.

[–] Gxost 17 points 21 hours ago (1 children)

It's all because of Electron, unnecessary libraries, and just bad coders. Asus Armoury Crate weighs a lot and is so slow, but it's basically a simple app. Total Commander has much more features, but it's fast, lightweight, and consumes 9 MB of RAM.

[–] [email protected] 8 points 16 hours ago (2 children)

I've said this on reddit before, but once for a joke I tried to make a windows program to play doot.wav during October at random, and tried programming it on Linux.

Sinds playing audio and working with the system tray was tricky, I ended up with electron.

So yeah, an atrocious 120 mb application to play a 6kb wav file with a Math.random(). I don't remember the memory consumption, but it was probably just as gross.

[–] [email protected] 2 points 6 hours ago

Which faang company are you sr. engineer at?

[–] Gxost 3 points 12 hours ago (1 children)

Once I wrote an annoying program adding acceleration to the mouse cursor, so it was difficult to click any UI item. It was written in Object Pascal with Win API and weighted 16 KB. And I think in C it would be even smaller.

[–] [email protected] 1 points 2 hours ago

I remember there was a pretty funny prank program that would make the user's mouse pointer leave behind little poops on the screen at random.

[–] [email protected] 51 points 1 day ago* (last edited 1 day ago) (3 children)

isn't it a combination of younger developers not learning to programme under the restrictions of limited memory and cpu speed, on top of employers demanding code as soon as possible rather than code that is elegant or resource efficient or even slightly planned out

[–] herrvogel 12 points 20 hours ago

Mostly the latter. We don't do any optimizations on our product whatsoever. Most important thing is to say yes to all the customers and add every single feature they want. Every sprint is spent adding and adding and adding to the code as much as we can and as quickly as we can. Not a single second is allotted to any discussion about performance or efficiency. Maybe when something breaks, but otherwise we keep piling on more crap at full speed non-stop. I have repeatedly been told "the fast way is the right way" followed by laughter. I was told to "merge this now" on multiple occasions even when I knew that the code was shit, and told the team as much. I am expected to write code now and think about it later.

As you can expect, the codebase is a bloated nightmare. Slow as shit, bugs galore, ugly inconsistent UI, ENORMOUS memory use, waaaaaay too frequent DB access with a shit ton of duplicate requests that are each rather inefficient themselves. It is a rather complex piece of lab management software, but not so complex that it should be struggling to run on dedicated servers with 8 gigs of RAM. Yet it does.

[–] [email protected] 14 points 23 hours ago (2 children)

Much the latter.

Plus everything better work perfecly out of the box on any hardware, and there is a lot of different hardware. Compatibility layers are often built into the package.

Java, for instance, recommenda that you package the whole (albeit slimmed down) JVM inside the package for the target platform, rather than relying on the java runtime installed already.

The users arent expected to know any of that anymore.

load more comments (2 replies)
[–] [email protected] 7 points 22 hours ago* (last edited 18 hours ago)

Generally maybe but for apps specifically, it's the default choice of IDE, Android Studio, bundling tons of libraries for added functionality bound to Play Services.

Which would probably be illegal in EU now, if any judge had the tech see-through for it.

[–] kamen 13 points 22 hours ago (1 children)

I'd argue that deploying from one codebase to 3+ different platforms is new functionality, although not for the end user per se.

I wish though that more of the web apps would come as no batteries included (by default or at least as a selectable option), i.e. use whatever webview is available on the system instead of shipping another one regardless of if you want it or not.

[–] [email protected] 8 points 21 hours ago

But if your tool chain is worth anything the size of each binary shouldn't be bigger. To oversimplify things a bit: it's just #ifdefs and a proper tool chain.

In the web development world on the other hand everything was always awful. Every nodejs package has half the world as dependencies...

[–] [email protected] 46 points 1 day ago (7 children)

#include "the_entire_fucking_internet.h"

load more comments (7 replies)
[–] [email protected] 26 points 1 day ago (3 children)

Usually, instead of having 8-bit art, you have epic songs and very high definition textures. That is a good deal of why.

[–] [email protected] 27 points 1 day ago (2 children)

I think the epic songs and 4K textures are missing in my MS Office.

[–] HeyThisIsntTheYMCA 9 points 1 day ago (1 children)

Yeah but they made xlookup, that's worth a few hundred megabytes

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 13 points 1 day ago (1 children)

Textures and songs are not a thing on most apps right? For android, using Kotlin has created much bigger appsize than old java

[–] [email protected] 1 points 7 hours ago (1 children)

Kotlin doesn't have much impact on binary size.

[–] [email protected] 1 points 45 minutes ago

For smaller apps maybe. I've seen apps that should take less than 1mb rise to 15mb or so

load more comments (1 replies)
[–] [email protected] 8 points 22 hours ago

It's nearly all just using a whole library instead of the specific single function thats actually required, because few people are actually writing any code these days.

[–] [email protected] 80 points 1 day ago (11 children)

Fucking Chrome/Electron is why.

I honestly wouldn't mind that if they could all use the exact same runtime so the apps could be a few MB each, but nooooo.

[–] [email protected] 12 points 1 day ago

400mb iphone banking app entered the chat

load more comments (10 replies)
[–] Stovetop 312 points 1 day ago (3 children)

It's just that we have to make space for our 5,358 partners and the telemetry data they need.

load more comments (3 replies)
[–] [email protected] 56 points 1 day ago (6 children)

Simple reason - dependencies.

Modern devs dump any dependency and sub-dependency under the sun into their project and don't bother about optimizing it. That's how you end up with absurdly large applications. Especially electron is a problem in this regard.

You can still write optimized and small software. However, for most businesses, it's just not worth their time. Rather using an additional couple hundred megabytes of dependencies on the client system.

load more comments (6 replies)
[–] rational_lib 14 points 1 day ago (1 children)

Because the app stores keep adding new requirements that you have to add code to deal with and it gets worse every year and seemingly every day.

load more comments (1 replies)
[–] [email protected] 212 points 1 day ago (11 children)
[–] [email protected] 152 points 1 day ago (2 children)

And analytics. And offloading as much computation to the client, because servers are expensive and inefficiency is not an issue if your users are the ones paying for it.

load more comments (2 replies)
load more comments (10 replies)
load more comments
view more: next ›