Now I am faced with the reality that my algorithm is not a 100% of the time delivering the correct result, but may - under very specific circumstances - provide an erroneous result. Unfortunately, the algorithm works correctly and the issue is with my conceptual idea of it. Meaning that it can't be fixed with simply tweaking some code.
So I'm guessing you've considered this, but can you detect these circumstances and flag them?
Programming is really more of an engineering pursuit than a purely mathematical one. Lots of problems in computer science are incredibly expensive to solve perfectly, but most of our modern lives are enabled by plenty and plenty of solutions that are 90% of the way there.
Hell, I mean the whole concept of a cache is pretty ugly if you're looking for an aesthetic mathematical solution to a problem, and yet the web is soaked with caches. (Well, which then go on to cause a bunch of security problems of their own if not very carefully managed, but that's a whole 'nother issue.)
So, I wanted to ask the people here who have more experience than me. Should I ...
- Abandon the project because the algorithm is faulty?
- Finish the project, publish the page, but highlight that the provided algorithm is faulty and kind of say "but hey, I made all this"?
- Finish the project, publish the page, but don't tell that there is an intrinsic issue with the algorithm?
I kind of feel like a retard who created something that is essentially worthless, but still I am kinda proud of it.

So, what do you think? How would this be received and can it be a door opener for a development-adjacent position in a larger company? Or would I be laughed out the door because the essential premise is faulty and what I build around it does not matter for that reason?
So if you can't flag the unsupported situations, then publish it as some subdirectory on a domain you control and just don't publicize it. Show it off when you're applying for jobs.
It sounds like you learned a bunch about coding, but also infrastructure, deployment, all sorts of little odds and ends that people forget about when pursing a career in software, but are still entirely essential. Stuff that people often learn on the job, and you can demonstrate you're coming in far ahead of the typical douchebag right out of college / six week code camp. That's impressive in and of itself.
Though I have to say, I know your pain. I know what it feels like to be painted into a corner and have to choose between tearing everything down and starting anew (if that's even an option), or just giving up.
Say what you will, at least she didn’t use a long dependency chain.
I mean, the main problem with long dependency chains is with languages, specifically Javascript, that can't distribute binaries. (Or don't have a standardized binary format.)
I don't care about a bunch of C or Java dependencies.
You should decompile Terraria if you want to see the longest fucking nested if/else statement in existence.
e: oh it's
up on github
gaze into the abyss of right brackets and despair
Is that from the decompiled binary or the original source? Because decompilers often have to guess at what the original source code was. That could've been generated from some sort of macro system or something.
Or maybe the dev did just copy and paste like a moron lol.
I was confusing him with a woman who posted a comparison of men vs. women coding, and the "man" code is Fast Inverse Sqrt while the "woman" code is just a bunch of comments.
Oh god, yeah. I just spent like twenty minutes racking my brain, trying to remember who that was. She became a laughingstock.
I was thinking, like coding with Kalie? Something like that?
Turns out, Karlie Kloss:
I think there's some other hilarious stuff she's done.
Can you learn AWS on your own (without online courses) or what are some good AWS courses?
I really never know what job listings are asking for when they ask if you "know AWS".
Like, I've made use of several different AWS APIs, like textract, S3, EC2, and others. I've used them together, separately, from APIs, from the CLI, etc.
None of these projects were that impressive, btw. You read the docs for the API you want to use, they're usually very good. Hook things up and it'll work.
I guess what confuses me is that there isn't really any common "AWS" to learn. Like at most, there's a common user/access/permission system, so a big organization can give out user IDs and keys for smaller departments to access the above APIs without accessing each other's data. Beyond that, most AWS services seem to be pretty independent to me.
Idk, just start a hobby project that uses like, EC2 and a couple other AWS APIs and make it work. That's about the level of effort I put into feeling justified putting "AWS" on my resume.