Gloomberb

This kind of hug boxing might have been fine five years ago during the ZIRP era, but in an age where two sticks of RAM is becoming $800 (and data centers are causing dirty sin power that can wear down electronics), I think the developers have a duty to be efficient with their programs and to do what is necessary to not ship a 500 MB ram sink with every single app.

It is frankly unforgivable and it’s a drain on the skill of the industry to just say “yeah no man it’s OK. It’s OK don’t worry don’t worry about your app being completely inefficient and a drain on your users resources. Don’t worry about it. Your app is so good that nobody will ever be using any other application on their PC“

Is this developer paying for my RAM? I run local models on consumer hardware. I can’t afford a 500mb of RAM for a CLI app. Thank you for that. Thank you for writing your CLI software in a way that I have to close it in order to use other parts of my computer.

Not to mention interpreted languages are slower than compiled languages, and we are talking about a financial terminal. Talk about not even understanding the functional requirements of the thing you are building. I might go get Bloomberg terminal instead of this just because I know it’s gonna actually be faster and make me money. This might actually lose me money.

Just because they built an application that “competes” with a closed source tool does not mean that their open source tool is good or worth adopting.

I mean, have some respect for and actual thought about who your end user is.

Imagine in the 80s or 90s telling a software developer not worry about porting their Amiga fintech application to another architecture like sparc. Imagine telling a developer in the 90s and 00s not to worry about browser compatibility and thanking them for making it only for IE to protect their fragile ego.

Imagine telling the creators of UNIX “yeah, no PDP 11 is good. You could stop there anyone who wants to run it on a different architecture is just an ingrate who doesn’t respect the effort you put in.” Because they already did so much work.

This is a farce. GP had a valid constructive criticism and a valid input worth considering when you take into account the functional requirements of a financial terminal.

Just because you are willing to cut corners on things that you don’t release does not mean that it is OK to release a piece of software with cut corners. But you know that, or you would release your software. I’m certainly projecting because I know that that’s why I write tools for myself that I don’t publish, but even then I use compiled languages and go out of my way to avoid JavaScript type script, python, and all of that.

But if this project were to ever take off and they were to monetize or start charging enterprise licenses the very first thing I would ask for is the compiled version that doesn’t rely on interpreted languages or a 500 MB node folder.

Used Trello a lot before it got sold to, and damaged by contact with, Atlassian. FogBugz looked cool…but I had to use an old version of Bugzilla.

I didn't know Glitch existed until this site had a notice that it Glitch would be shutting down. Surprised me FCS had anything to do with a game, and seems it wasn't a good fit. I like the style though, and downloaded some of the art and variations on the Groddle theme before it died.

I mean, not everyone who's sensitive, but certainly anyone who can't stand another engineer pointing out poor technology decisions. If they're going to be ego babies about it instead of taking the feedback humbly and making their product better, then yeah maybe they should leave the industry.

I've worked with people like this before and they don't belong in the industry.

Idiots that don't even take the time (and perhaps aren't capable of the empathy required) to consider the end users and are personally attacked when confronted with the end users' needs.

One guy I worked with implemented a parts picker as a Python CLI app (a ~1500-line-main if-then-else monstrosity with no back navigation, so closing it was the only way to go back) built and apparently only tested on a Windows 10 PC.

During the demo he mentioned that technicians could copy the part number for entry in another form by pressing Ctrl+C. I asked why he would choose to implement copy in a tech floor CLI app using ctrl+c when all the Technician's PCs were Windows 7 based and that would close the application. He handwaved it away. This was a guy who had been promoted from technician. He knew what the functional and technical requirements were.

Two weeks later, a more senior member of one of the tech teams was having full drive issues. I ran windirstat and found that the idiot's python app was storing 500MB of temp python runtime bullshit in the AppData folder in folders named as random hashes on every run, and they weren't deleting. This elder Gen X gentleman didn't understand why Ctrl+C as he was told to do was closing the app instead of copying text and kept relaunching it until it his drive was full. But the whole tech floor shared computers in shifts, meaning that IT was gonna have to come and reimage every machine every 90 days. I did the math.

I submitted this problem to him as a formal bug report with a proposed solution, and I was written up for personally attacking him.

He later went on to fuck up timestamps in a database so badly that there was no recovering it, he took no backups, and 4 technicians spent weeks of man hours manually re-recording the data in the database and he set the launch of a device recycling program that would have saved the company millions back for several months. It was supposed to launch in April. He nuked the database in March. When I left the company in August, that shit still hadn't launched. He affected the company's share price with his crybaby sensitive ego.

So yeah, I think if anyone is so sensitive that they can't take real technical feedback like "don't use wasteful runtimes for CLI applications" it's indicative of a real mindset problem that will infect all other aspects of their work and interactions with technology, and they should consider leaving the industry or humbling themselves and learning how to take feedback and build better.