Quote by my non-techie co-founder: when a developer says a new feature takes X amount of time, you always have to multiply X by PI to get the actual duration 🤓

ARGH. I wrote a long rant containing a bunch of gems from the codebase at @work, and lost it.

I'll summarize the few I remember.

First, the cliche:
if (x == true) { return true; } else { return false; };
Seriously written (more than once) by the "legendary" devs themselves.

Then, lots of typos in constants (and methods, and comments, and ...) like:
SMD_AGENT_SHCEDULE_XYZ = '5-year-old-typo'

and gems like:

def hot_garbage
magic = [nil, '']
magic = [0, nil] if something_something
success = other_method_that_returns_nothing(magic)
if success == true
return true # signal success
end
end

^ That one is from our glorious self-proclaimed leader / "engineering director" / the junior dev thundercunt on a power trip. Good stuff.

Next up are a few of my personal favorites:

Report.run_every 4.hours # Every 6 hours
Daemon.run_at_hour 6 # Daily at 8am

LANG_ENGLISH = :en
LANG_SPANISH = :sp # because fuck standards, right?

And for design decisions...

The code was supposed to support multiple currencies, but just disregards them and sets a hardcoded 'usd' instead -- and the system stores that string on literally hundreds of millions of records, often multiple times too (e.g. for payment, display fees, etc). and! AND! IT'S ALWAYS A FUCKING VARCHAR(255)! So a single payment record uses 768 bytes to store 'usd' 'usd' 'usd'

I'd mention the design decisions that led to the 35 second minimum pay API response time (often 55 sec), but i don't remember the details well enough.

Also:
The senior devs can get pretty much anything through code review. So can the dev accountants. and ... well, pretty much everyone else. Seriously, i have absolutely no idea how all of this shit managed to get published.

But speaking of code reviews: Some security holes are allowed through because (and i quote) "they already exist elsewhere in the codebase." You can't make this up.

Oh, and another!
In a feature that merges two user objects and all their data, there's a method to generate a unique ID. It concatenates 12 random numbers (one at a time, ofc) then checks the database to see if that id already exists. It tries this 20 times, and uses the first unique one... or falls through and uses its last attempt. This ofc leads to collisions, and those collisions are messy and require a db rollback to fix. gg. This was written by the "legendary" dev himself, replete with his signature single-letter variable names. I brought it up and he laughed it off, saying the collisions have been rare enough it doesn't really matter so he won't fix it.

Yep, it's garbage all the way down.

Static HTML pages are better than "web apps".

Static HTML pages are more lightweight and destroy "web apps" in performance, and also have superior compatibility. I see pretty much no benefit in a "web app" over a static HTML page. "Web apps" appear like an overhyped trend that is empty inside.

During my web browsing experience, static HTML pages have consistently loaded faster and more reliably, since the browser is immediately served with content useful for consumption, whereas on JavaScript-based web "apps", the useful content comes in **last**, after the browser has worked its way through a pile of script.

For example, an average-sized Wikipedia article (30 KB wikitext) appears on screen in roughly two seconds, since MediaWiki uses static HTML. Everipedia, in comparison, is a ReactJS app. Guess how long that one needs. Upwards of three times as long!

Making a page JavaScript-based also makes it fragile. If an exception occurs in the JavaScript, the user might end up with a blank page or an endless splash screen, whereas static HTML-based pages still show useful content.

The legacy (2014-2020) HTML-based Twitter.com loaded a user profile in under four seconds. The new react-based web app not only takes twice as long, but sometimes fails to load at all, showing the error "Oops something went wrong! But don't fret – it's not your fault." to be displayed. This could not happen on a static HTML page.

The new JavaScript-based "polymer" YouTube front end that is default since August 2017 also loads slower. While the earlier HTML-based one was already playing the video, the new one has just reached its oh-so-fancy skeleton screen.

It would once have been unthinkable to have a website that does not work at all without JavaScript, but now, pretty much all popular social media sites are JavaScript-dependent. The last time one could view Twitter without JavaScript and tweet from devices with non-sophisticated browsers like Nintendo 3DS was December 2020, when they got rid of the lightweight "M2" mobile website.

Sometimes, web developers break a site in older browser versions by using a JavaScript feature that they do not support, or using a dependency (like Plyr.js) that breaks the site. Static HTML is immune against this failure.

Static HTML pages also let users maximize speed and battery life by deactivating JavaScript. This obviously will disable more sophisticated site features, but the core part, the text, is ready for consumption.

Not to mention, single-page sites and fancy animations can be implemented with JavaScript on top of static HTML, as GitHub.com and the 2018 Reddit redesign do, and Twitter's 2014-2020 desktop front end did.

From the beginning, JavaScript was intended as a tool to complement, not to replace HTML and CSS. It appears to me that the sole "benefit" of having a "web app" is that it appears slightly more "modern" and distinguished from classic web sites due to use of splash screens and lack of the browser's loading animation when navigating, while having oh-so-fancy loading animations and skeleton screens inside the website. Sorry, I prefer seeing content quickly over the app-like appearance of fancy loading screens.

Arguably, another supposed benefit of "web apps" is that there is no blank page when navigating between pages, but in pretty much all major browsers of the last five years, the last page observably remains on screen until the next navigated page is rendered sufficiently for viewing. This is also known as "paint holding".

On any site, whenever I am greeted with content, I feel pleased. Whenever I am greeted with a loading animation, splash screen, or skeleton screen, be it ever so fancy (e.g. fading in an out, moving gradient waves), I think "do they really believe they make me like their site more due to their fancy loading screens?! I am not here for the loading screens!".

To make a page dependent on JavaScript and sacrifice lots of performance for a slight visual benefit does not seem worthed it.

Quote:

> "Yeah, but I'm building a webapp, not a website" - I hear this a lot and it isn't an excuse. I challenge you to define the difference between a webapp and a website that isn't just a vague list of best practices that "apps" are for some reason allowed to disregard. Jeremy Keith makes this point brilliantly.
>
> For example, is Wikipedia an app? What about when I edit an article? What about when I search for an article?
>
> Whether you label your web page as a "site", "app", "microsite", whatever, it doesn't make it exempt from accessibility, performance, browser support and so on.
>
> If you need to excuse yourself from progressive enhancement, you need a better excuse.

– Jake Archibald, 2013

Silly and stupid me.

Woke up.
Check phone. Check devRant.
Saw Trogus's filter update post.
Happy and left a comment.
Went to playstore and update.
Open devRant and use the feature.
Tried to filter only Rants and Questions type.
Happy and went back to sleep again bcz Saturday.
Continue the rest of day with other stuffs.
Use devRant again.
"Huh why the heck is the first post about some random quote?"
"Why the hell is second post meme"
"Why...why...why"
Check filter feature again.
Facepalm.

Silly me and stupid my eyes and useless my brain is not worthy for good and clean UIUX.

God, the dude who "assisted" me today can go and fuck himself with a cactus.

I need to configurate and integrate some cms into a project. But since the documentation is utter horse shit and superficial, it's fucking torture to do so!

So after creating an issue on their helpdesk, i get an answer from some employee there. Instead of actually posting something useful, he decide that he could instead quote the fucking documentation.

Of course, he also quotes the very page i mentioned in my issue for being COMPLETELY USELESS. This goes back and forth. And he keeps just quoting the fucking documentation.

So i decompiled their product and painstakingly worked out how the feature worked that i needed.

Fuck you support asshole. I hope you get to maintain a legacy VBA project!

So I just got asked for a quote for developing an app for a client's friend. He wanted an app that requires me to build let's just say a combination of what you see on uber with the live tracking of your uber driver, seeing all cars around your location and determining the closest one (It wasn't necessarily cars) plus profiles and another app for another set of users (I can easily make this one and determine the logged in user and in turn tailor the features for that user but they wanted two). An admin portal also was included and I had to do various integrations with Google maps. In app purchases was also necessary. Logs as the app has to keep track of all activities basically. A wallet feature was also to be implemented, scheduling, rating and complains section was also something requested and finally a mini accounting system was also to be developed. I was going to do this singlehandly as a freelancer. Obviously this is a lot of work. I also gave them a timeline of about 3 months for development. Which meant I was going to be putting all my time into developing this. Front end and backend for the app and front-end and backend for the server and database architecture. I charged them $10,000 not only for the work but also because they were going to be making money off of the app. They go "wow and why does it cost so much"...Judging from their reactions I don't think they will move further with this with me because of costs...😂 I can't even begin to wonder why they think that isn't a fair price. I have learnt from previous work before that you always state a cost for which you are absolutely sure you would want to work for else you would start doing the work and once you see how little you are being paid for so much work you end up hating the work and completing it ends up being a difficult task.

I know it would be against devRant's simple UI and mechanism, but I'd love a Quote/Jump To Quote feature.

I have a great chemistry with this coworker.

He lacks some depth of android knowledge but is always very interested in adding new google libs to the project, so we often discuss and come up with the safest, scalable solutions.

He is SE2 and I am SE1.

But one thing that is interesting about him is the way he gives estimations for the tasks. He takes usually that much amount of time that i would take, for a task, but he would quote half the time estimates.

the bosses usually come on the last days to check the feature demo, but QAs gets the first build when a task is completed. I have seen his first builds that goes to QA and most of the time, boy it has some amazingly stupid bugs.

dude would just put a util function, then run the build, if everything compiled, he would just give the build to QA directly. he wouldn't even check that the util function gave an expected output or not.

He is simply wasting QA time n efforts, and risking product quality by not testing enough, but he almost always gets a clean chit for this behavior just because he did the work super fast.

Dude is super cool and i don't envy him for his good luck, but rather think of him as an inferior dev. However bosses think of him as a better dev and my TL even once told me to "be like him"

So i guess this is how corporate works. I will try to apply this in my next role in current/next organisation.

you know one should tread very carefully when getting a business dealing out of friendship.

if their is a boss-employee dynamics in the business, as in you are the boss and they are being paid to work for you or vice versa, then during work , be prepared to take criticism constructively. as a friend, the relation is different, we say each other anything and it is laughed off, but during work, there is a matter of respect, seniority and professionalism.

another kind of dynamics are the freelance/favour relation where friend is giving you free/paid service/advice or vice versa. this is even more shittier situation and is almost always bound to fuck up.
- the guy receiving service will try to negotiate a better deal because friend factor ('you will take so much money from your homie?')
- the guy providing service will try to offer a bad deal because friend factor ('i know he trust me. let me offer him a bad quote as he don't know anything of this domain')
- the guy providing service may not consider the service/advice as priority because friends factor ('he is a homie. he can wait')
- the guy receiving service may not be satisfied with the product/offerring/guidance because friends factor ('you could have added this x feature too bro, i paid you')

overall friend factor sucks. somehow the boss-employee factor worked for me as i was careful after 1 bad attempt