Me: *spends 4+ hours refactoring existing spaghetti, ensuring components are modular, easier to test and fault tolerant*

Project manager: ...

Also me: *adds pre-loader image to register and login buttons when user submits form*

Project manager: *All excited* Awesome work. 🙌That's some nice improvement..

Like wtf dude 😳..

My takeaway: These noobs only care about what they can directly interact with

I know it's not done yet but OOOOOH boy I'm proud already.

Writing a JSON parser in Lua and MMMM it can parse arrays! It converts to valid Lua types, respects the different quotation marks, works with nested objects, and even is fault-tolerant to a degree (ignoring most invalid syntax)

Here's the JSON array I wrote to test, the call to my function, and another call to another function I wrote to pretty print the result. You can see the types are correctly parsed, and the indentation shows the nested structure! (You can see the auto-key re-start at 1)

Very proud. Just gotta make it work for key/value objects (curly bracket bois) and I'm golden! (Easier said than done. Also it's 3am so fuck, dude)

TL; DR: Bringing up quantum computing is going to be the next catchall for everything and I'm already fucking sick of it.

Actual convo i had:

"You should really secure your AWS instance."

"Isnt my SSH key alone a good enough barrier?"

"There are hundreds of thousands of incidents where people either get hacked or commit it to github."

"Well i wont"

"Just start using IP/CIDR based filtering, or i will take your instance down."

"But SSH keys are going to be useless in a couple years due to QUANTUM FUCKING COMPUTING, so why wouldnt IP spoofing get even better?"

"Listen motherfucker, i may actually kill you, because today i dont have time for this. The whole point of IP-based security is that you cant look on Shodan for machines with open SSH ports. You want to talk about quantum computing??!! Lets fucking roll motherfucker. I dont think it will be in the next thousand years that we will even come close to fault-tolerant quantum computing.

And even if it did, there have been vulnerabilities in SSH before. How often do you update your instance? I can see the uptime is 395 days, so probably not fucking often! I bet you "dont have anything important anyways" on there! No stored passwords, no stored keys, no nothing, right (she absolutely did)? If you actually think I'm going to back down on this when i sit in the same room as the dude with the root keys to our account, you can kindly take your keyboard and shove it up your ass.

Christ, I bet that the reason you like quantum computing so much is because then you'll be able to get your deepfakes of miley cyrus easier you perv."

Once upon a time, one or two jobs ago, a really awesome engineer specced out a distributed search application in response to a business need. This company was managed pretty oldschool and required a ton of paperwork and approvals.

The engineer spent many weeks running tests and optimizing the hell out of this app cluster. It flew, and he had the data to prove it could handle production workloads (think hundreds of terabytes of data being processed every single day)

Part of the way he achieved this was having RAID0 on all of the servers to maximize I/O throughput. He didn't care much about data loss, since the application itself was fault tolerant on a much more granular level.

Management, hearing about this, absolutely flipped their shit and demanded RAID6 instead. This despite the conclusive data that the engineer had that proved RAID6 couldn't keep up.

He more or less got told to STFU.

Even this despite the fact that a RAID restripe would actually take many times longer than rebuilding the failed node from scratch (a process that took about 30 minutes by hand, and could probably be automated to be done in less than five), causing a longer exposure to actual data loss throughout the length of the days-long array rebuild time.

The ill-thought-out requirement added about 50% to the cost of the project (*many* more hard drives now required), beyond the original budget, and the subsequent bureaucratic wrangling resulted in a late product launch.

6 months or so later, after real customers were using this product, the app was buckling under around half of its expected workload. A friend of the engineer suggested to management to try RAID0. Sure enough, that resolved the I/O bottleneck.

This rage-inducing story has a happy ending, though! Said engineer left the company not long after this incident, citing it as a reason for his departure. He was immediately hired by another company, making integer multiples of his prior salary.

The product the company botched the launch of by ignoring his spec? It died a few months later. Maybe the poor customer experience was to blame? Maybe the late launch? Maybe it was another reason entirely.

Either way, millions of dollars of hardware now sat fallow. This was a black eye on the company all the way up to the C-level.

tl;dr: Listen to your engineers. You hired them for their expertise.

Daghhhhhhhh Kafka.

Set it up, seems to work fine.

Oh no...! Take a broker down, then messages go missing - hmm, that's not right. Fine, I'll just look into... Ah, bad replication factor, my fault. So then it's all fixed! Woop. Wait, no. Some messages still going missing occasionally. Oh, only set to "at most once" delivery. My bad, fix that, and... now everything is out of order. Oh, ok, partitions setup wrongly. Wtf, now the whole thing stalls when there's a network blip until a restart. Right, ok, looks like commits have to receive acks in the library I'm using before continuing. Switch to a library that uses CommitWithoutReply. Brilliant....

Apart from said library seems to have commits failing all over the place because it keeps trying to commit during a rebalance 🙄😒😤

The frustrating thing is I KNOW for a fact that Kafka is a fault tolerant, resilient, horizontally scalable thing capable of handling stupid amounts more than I'm throwing at it without missing a beat. But damn,configuring it, and checking you've configured it sanely is a royal, monumental PITA.

If you're currently in college and wish to get placed in a major tech giant like Amazon or Facebook:

Don't learn React.js, instead learn Linked lists.

Don't learn Flutter, instead learn Binary search trees.

Don't learn how to perform secure Authorization with JWTs, instead learn how to recursively reverse a singly linked list.

Don't learn how to build scalable and fault tolerant web servers, instead learn how to optimally inverse a binary search tree.

These big tech companies don't really care what real world development technologies you've mastered. Your competence in competitive programming and data structures is all that matters.

The system is screwed. Or atleast I am.

We spent 9 hours taking a vote, across all of the dev team (including junior devs), about how to design the backend architecture and which security measures we should take.

The CTO refused to listen to the person assigned to the design (me at the time) because he preferred fire-and-forget for EVERYTHING, ignoring all of the blatant drawbacks, and claimed that "there is no truly fault tolerant system", which is such a cop-out that my mind still cannot fathom it.

So therefore, since he couldn't have it his way, we took it to a vote (not my decision). Spent nine hours discussing the pros and cons of HTTP vs MQ systems to arrive at a vote.

I "won", and then left the company shortly after, because it was clear that even though the votes were in my favor, I was going to be "nickel and dimed" to death about the changes and how it's deployed, etc. to the point the system will end up like the previous systems they wrote.

Oh and the fact I was asked to help "improve morale" for the team that was working on the old, broken, overengineered project (I don't manage them nor did I write any of that code) by being assigned to arrange breakfast catering because it'd somehow mean more "coming from a senior dev".

I loved the people there - truly, some of the best people - but the company was broken from the ground to the ceiling.

CTO was let go a while after I left, I guess - most of the dev team has since left too and the majority of their work is being outsourced to Indian subcontractors.

When fixing high CPU load and unresponsive servers is a simple restart. Ugh...

I continue to internally read and study about Smalltalk in an effort to see where we might have FUCKED UP and went backwards in terms of software engineering since I do not believe that complex source code based languages are the solution.

So I have Pharo. Nothin to complex really, everything is an object, yet, you do have room for building DSL's inside of it over a simple object model with no issue, the system browser can be opened across multiple screens (morph windows inside of a smalltalk system) for which you can edit you code in composable blocks with no issues. Blocks being a particular part of the language (think Ruby in more modern features) give ample room for functional programming. Thus far we have FP and OO (the original mind you) styles out in the open for development.

Your main code can be executed and instantly ALTER the live environment of a program as it is running, if what you are trying to do is stupid it won't affect the live instance, live programming is ahead of its time, and impressive, considering how old Smalltalk is. GUI applications can be given headless (this is also old in terms of how this shit was first distributed) So I can go ahead and package the virtual machine with the entire application into a folder, and distribute it agains't an organization "but why!!!! that package is 80+ mbs!") yeah cuz it carries the entire virtual machine, but go ahead and give it to the Mac user, or the Linux user, it will run, natively once it is clicked.

Server side applications run in similar fashion to php, in terms of lifecycles of request and how session storage is handled, this to me is interesting, no additional runtimes, drop it on a server, configure it properly and off you go, but this is common on other languages so really not that much of a point.

BUT if over a network a user is using your application and you change it and send that change over the network then the the change is damn near instant and fault tolerant due to the nature of the language.

Honestly, I don't know what went wrong or why we are not bringing this shit to the masses, the language was built for fucking kids, it was the first "y'all too stupid to get it, so here is simple" engine and we still said "nah fuck it, unlimited file system based programs, horrible build engines and {}; all over the place"

I am now writing a large budget managing application in Pharo Smalltalk which I want to go ahead and put to test soon at my institution. I do not have any issues thus far, other than my documentation help is literally "read the source code of the package system" which is easy as shit since it is already included inside. My scripts are small, my class hierarchies cover on themselves AND testing is part of the system. I honestly see no faults other than "well....fuck you I like opening vim and editing 300000000 files"

And honestly that is fine, my questions are: why is a paradigm that fits procedural, functional and OBVIOUSLY OO while including an all encompassing IDE NOT more famous, SELECTION is fine and other languages are a better fit, but why is such environment not more famous?

Just my luck that I get the best wk76 story ever on wk77. Either way:

So some of you may know that the current project I am on has some shared code components with one of the other projects in the product line. And we have some differences in our processes. This leads to a lot of fun.

So, I was working on converting one of our shared components into a more modern language. It would save us time, money, and sanity by allowing us to more easily maintain our product. Sounds like a win-win right? That's what I thought. Until I had a meeting with the other team. THEN THE QUESTIONS ROLLED IN. Well who is going to integrate our product with yours? (You?) Are you changing the interface? (Not really.) Are you going to generate a design document? (Absolutely not especially since the interface isn't changing for the most part.) Well you are changing the type of one parameter in one method from an undocumented unmanaged type to a well documented managed type that we control. Shouldn't you generate a document to document that change? (Again absolutely not.)

So first they basically browbeat my lead into putting me in charge of their integration effort. Its fine though, as they gave me an account to charge. However, when I was finally able to get a machine with their build environment on it (at least two months later), they then told me that that account was closing and I had to wait until next quarter. So fuck me right. And because of their process I would break them if I were to check my changes in.

So fast forward to today. They are translating some shared components for the same reason that we are. However, they are changing code that while shared is technically "ours" and that will DEFINITELY break us if they do this work since this is the code that controls our algorithms. And while we have a fault tolerant process, or at least more fault tolerant than the other group's, we are currently doing a huge amount of development in the part they want to change. And when we ask them "who is going to do this work to integrate our product with your changes?" they stare at us slack jawed. Like "um, you right? it doesn't affect us." Like MOTHERFUCKERS!!! YOU LITERALLY JUST FOIST ALL THIS WORK ON US TO INTEGRATE WITH YOU BECAUSE YOU DIDN'T HAVE THE PEOPLE TO SUPPORT IT!!! BUT YOU CAN PAY THIS GUY FOR SIX MONTHS TO DO ALL THIS WORK THAT WILL BREAK US BUT CAN'T SPARE HIM TO INTEGRATE WITH US!?!?!? EVEN IF WE'RE PAYING HIM AND NOT YOU!?!?!

I will let you know how this goes when we have the discussion. I am drinking right now because it it easier and better for my emotional and physical health than bum fights.

Every tool in the JS ecosystem goes out of its way to support faulty or outdated variants of every interface, yet nothing is actually forgiving or fault tolerant. Publishing packages is exactly as agonizing as consuming them, even though both sides have tens of switches and probably hundreds of automatic heuristics to align themselves to any hypothetical setup on the opposite end.

Im fucking fed up with overbloated "all in one" ORMs.

For shit I cant find simple ORM that would literally just do fucking CRUD for me.

Thats all I require for some small project, yet still for few tables I have 2 choices:
a) do it without ORM and write models with raw SQL (which I usually end up doing, as its just more fault tolerant and works better)
b) install overloaded ORM that I wont use even 1% of features

Guys, why the fuck nobody created anything small, tiny and yet usefull? I know my SQL sucks and that is reason I want to use ORM in the first place. But when Im just forced?

Best what I found in terms of ease of use, and beeing not too heavy was RedBeanPHP.

A freaking ORM that will create database on the fly. It's awesome, sure. It's usefull, sure.

BUT STILL ALL I NEED IN SMALL PROJECT IS 1% OF THAT FUNCTIONALITY.

Does literally every single ORM dev want to feel their dick when they list out features list?

There should be allways proper tool for proper job. Its like using symfony for creating onepage website with contact form. WTF.