Aboutanxious coffee drain; barely even a developer;
Joined devRant on 2/4/2022
Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Why does MS need to be such a scumbag with Windows updates?
Every now and then, this unskipable blue setup screen appears and forces the user to make some decisions.
"Do you want to set Edge as the default browser?"
"Do you want a 360 subscription?"
The usual crap.
But it‘s not skippable!
You have to make a decision and the UI for "fuck off" is different for every decision.
You can‘t just press the Nope button every time.
It‘s fucking deliberate. They want you to spend time on reading their shit and force it down your throat.
And let‘s not forget about people who don‘t know computer stuff very well and are confused by this. Then call us because "the computer isn‘t working again."
And you can‘t tell them to skip this slimy rotten vomit of a marketing weasel because you need them to tell you what the options are for each fucking decision screen.
(Forgot to post this a few days ago. Was just too tired.)
Finally finished the code review from hell.
The patch on top of the PR is +1448 -1114, and nearly all of it is rearchitecting, not moving.
I think I spent six days on it, 4-5 productive hours a day? Seems like a lot. This codebase is a bitch to work in.
@Root has a code review.
CR comment: “Why would you do it this way? It’s awful. Clean it up!”
Totally fair. I had copied the legendary dev’s code, and it was ick. Cleaning it was easy and enjoyable. I cleaned the source, too.
CR comment: “Why would you touch this? It’s outside the scope of the ticket. You could get it working without changing all this.”
CR comment: “The interfaces don’t match. Now it’s confusing, and that makes it harder to maintain.”
$work: Ey @Root, make this super simple thing.
$work: No, not like that.
$work: It also needs to do A, B, and C.
$work: No, not there. You should build it somewhere else, but I won't tell you where.
$work: You need to build out F and G, too.
$work: What do you mean you don't have the data? Just ask support drone #3. (who directs me to #2, and that one to #8 who doesn't know, and that one to #12 who won't answer)
$work: Why can't I do K, Y, or S? You should be able to infer these from the mind of whoever wrote the ticket by its wording, despite no mention of them whatsoever.
$work: Are you done yet? It's a super simple ask!7
Most tedious part of my day...
While meetings are boring and awful and all, it's probably spinup times for me. Each and every change requires a minimum of 35 seconds of spinup to test. If i'm testing something with mailers or other daemons, that increases to easily 90+ seconds (plus the worker thread pickup times).
It's not enough time to do anything useful, and more than enough time to lose my focus. It turns every task into boring, tedious struggle. It's awful.
Apart from my coworkers, this is the single worst part about my job. (Okay, the awful code quality totally pushes this to third place.)4
Firefox by far :)
At least as a program I start up my self.
I do use a fair number if other to but no other comes close.
We had all hands on developer meeting. There were 2 interesting bullet points:
- deliver fast
- make quality applications
I mean, these two points are not correlated 🙈10
The biggest joke maybe is that studying Software Engineering will not make you a Software Engineer. You will learn 100s of other things but developing software. Welcome to the 100-year-old curriculum.14
Week 278: Most rage-inducing work experience — I’ve got a list saved! At least from the current circle of hell. I might post a few more under this tag later…
TicketA: Do this in locations a-e.
TicketB: Do this in locations e-h.
TicketC: Do this in locations i-k.
Root: There’s actually a-x, but okay. They’re all done.
Product: You didn’t address location e in ticket B! We can’t trust you to do your tickets right. Did you even test this?
Root: Did you check TicketA? It’s in TicketA.
Product guy: It was called out in TicketB! How did you miss it?!
Product guy: (Refuses to respond or speak to me, quite literally ever again.)
Product guy to everyone in private: Don’t trust Root. Don’t give her any tickets.
Product manager to boss: Root doesn’t complete her tickets! We can’t trust her. Don’t give her our tickets.
Product manager to TC: We can’t trust Root. Don’t give her our tickets.
TC: Nobody can trust you! Not even the execs! You need to rebuild your reputation.
Root: Asks coworker a simple question.
Root: Asks again.
Root: nudges them.
Root: Asks again.
Coworker: I’ll respond before tomorrow. (And doesn’t.)
Root: Asks again.
Root: Fine. I’ll figure it out in my own.
TC: Stop making it sound like you don’t have any support from the team!
Root: Asks four people about <feature> they all built.
Root: Okay, I’ll figure it out on my own.
TC: Stop making it sound like you don’t have any support from the team!
Root: Mentions multiple meetings to discuss ticket with <Person>.
TC: You called <Person> stupid and useless in front of the whole team! Go apologize!
Root: Tells TC something. Asks a simple question.
Root: Tells TC the same thing. Asks again.
TC: (No response for days.)
TC: Tells me the exact same thing publicly like it’s a revelation and I’m stupid for not knowing.
TC: You don’t communicate well!
Root: Asks who the end user of my ticket is.
Root: Asks Boss.
Root: Asks TC.
Root: Fine, I’ll build it for both.
Root: Asks again in PR.
TC: Derides; doesn’t answer.
Root: Asks again, clearly, with explanation.
TC: Copypastes the derision, still doesn’t answer.
Root: Asks boss.
Boss: Doesn’t answer.
Boss: You need to work on your communication skills.
Root: Mentions asking question about blocker to <Person> and not hearing back. Mentions following up later.
<Person>: Gets offended. Refuses to respond for weeks thereafter.
Root: Hey boss, there’s a ticket for a minor prod issue. Is that higher priority than my current ticket?
Root: Hey, should I switch tickets?
Root: … Okay, I’ll just keep on my current one.
Boss: You need to work on your priorities.
Everyone: (Endless circlejerking and drama and tattling)7
In the macOS app "Keychain", if you search for something ("fork" in this case), you can’t delete it from the results directly. To delete it, you need to select it in the list without searching, which of course defeats the purpose.
WTF is this? This can’t be on purpose right?
(Sorry for the bad photo instead of a screenshot)8
Installed SonarQube and Snyk on the CI/CD of a 2.5 year old project that only had a linter enabled previously.
Practically zero problems found. One minor problem (same code in different branches), a few false positives, and a few possible problems in dependencies that I have no control over.
Am I really that good or are those tools just shit?10
New JoyRant TestFlight build 11:
* Posting Rants
* Improved Notifications Category selection UI with unread indicators (screenshot attached)
Posting this rant from JoyRant right now 😄
The app is now in a state what I consider to be the first major milestone.
There are still features missing (see github https://github.com/WilhelmOks/...) but the most important and most frequently used stuff is done.
Trash, trash, trash.
Who the fuck writes this shit?
Who the fuck lets these trash should-be-junior devs roll their own crypto? and then approves it?
The garbage heap of a feature (signing for all apis) doesn't follow Ruby standards, doesn't follow codebase conventions, has `// this is bridge` style comments (and no documentation), and it requires consumer devs to do unnecessary work to integrate it, and on top of all this: it leaks end-user data. on all apis. in plaintext.
Ticket: Add <feature> to <thing>. It works in <other things> so just copy it over. Easy.
Thing: tangled, over-complicated mess.
Feature: tangled and broken, and winds much too deep to refactor. Gets an almost-right answer by doing lots of things that shouldn't work but somehow manage to.
I write a quick patch that avoids the decent into madness and duplicates the broken behavior in a simple way for consistency and ease of fixing later. I inform my boss of my findings and push the code.
He gets angry and mildly chews me out for it. During the code review, he calls my patch naive, and says the original feature is obviously not broken or convoluted. During the course of proving me wrong, he has trouble following it, and eventually finds out that it really is broken -- and refuses to admit i was right about any of it. I'm still in trouble for taking too long, doing it naively, and not doing it correctly.
He schedules a meeting with product to see if we should do it correctly. He tells product to say no. Product says no. He then tells me to duplicate the broken behavior. ... which I already did.
At this point I'm in trouble for:
1) Taking too long copying a simple feature over.
2) Showing said feature is not simple, but convoluted and broken.
3) Reimplementing the broken feature in a simpler way.
4) Not making my new implementation correct despite it not working anywhere else, and despite how that would be inconsistent.
Did everything right, still in the wrong.
Also, they decided I'm not allowed to fix the original, that it should stay broken, and that I should make sure it's broken here, too.
You just have to admire the sound reasoning and mutual respect on display. Best in class.19
Spent all day trying to fix a Windows 10 machine.
I fixed lots of things I didn't know needed fixing..
But I don't know yet if I've fixed the things I started off needing to fix !
Along the way I discovered all manner of things..25
I got assigned approximately 20 tasks, all are high priority.
Coworker got assigned 2 tasks, (“like fix button sizes and padding”, “localisation “)
I got questioned: “are you sure you are a senior developer? Are you doing your work at all? If your coworker can finish low priority tasks in a day , why you as a senior can’t? “
Me :”if you have the ability to see , please tell me how many tasks I have that are in high priority.”
“Exactly, I need you to complete it now , I expect more from you as a senior. “
Me: “why not you tell me which tasks are higher priority? Because can’t be all are urgent. If everything is urgent , nothing is urgent.”
“Stop giving excuses, be a team player.”
Me :” how is it making excuses for asking urgencies of the tasks?”
“Hahaha you called yourself a senior. What a joke”
Me:”likewise, you called yourself a Project manager yet can’t manage. What a joke indeed.”20
Long time no see devRant. This rant is dedicated to an MQTT implementation we use. Mosquitto, mqtt.js - FUCK YOU.
I spent the last fucking 30+ hours trying to find why the bloody fuck the stupid server / client won't connect to the shitty mqtt broker. From changing all possible config, enabling & disabling specific code nothing abso-fucking-lutely works.
But then it will randomly decide to connect to the fucking broker, not causing any issues at all. And each fucking day when I wake up again and think to myself: oh today I can actually leave when it is still somewhat bright outside - NOPE. Because guess what? The fucking shitty abomination doesn't work anymore.
I just love these types of problems that are almost impossible to debug because the only logs you get is: "SERVER disconnected". It's impossible to get a proper reason out of this shit show, it's just turned into randomly guessing what the error could be (and especially where it could be).
And each time I got it to work, tested it and let the testing team know that they can start testing it will just stab me in the back and be like "fuck you, I'm not working any more". Luckily it's not like the deadline is next week... otherwise work is great, trust me.13
May be just me, but I am quite frustrated with complexity of systems nowadays, even more how it’s became a norm for developers to import a library for every little sh*t…
Like, do you even need to import that OSS library, can’t you make it without it? Is it really worth it to import that monstrous library of 10k loc, just so you can save writing those 50loc for just once?
It almost feels like it’s driven by logic “if you don’t own the code, then you don’t need to maintain it”. But ironically you still need to mantain it, only now not the code (best case), but the library itself. You have to upgrade it (for security, bug fixes) and you better pray there’re no breaking changes. And if you encounter an edge case/bug that no one addressed yet, then well, I bet you wished you didn’t use that library in the first place.
It’s so much easier to support small piece of code within your codebase, than fix a bug in a library, that possibly has thousands of unnecessary dependencies, enormous abstraction trees, and infinity loc to support all possible use cases, which your project doesn’t even care about.
Just to make it clear, I am not talking, about cases where some library would really do some heavy lifting for you, it would be non-sensical not to use it in that case.
And talking about complexity, let’s not even mention microservices, kubernetes, and other hyped stuff…
Does anyone else shares the sentiment?16
Asked junior to clone a git repo
junior: tried everything it doesn't work
me: show me how you did it
junior: right clicked on the repository, 'Copy link address' then paste it into the terminal
me: put that mouse down right now!29
Love when the client knows more than you and tells you to create a report on an imaginary tool they are 100% sure it exists because their friend is an SEO expert and thinks all pages should be running at a 100 percent on lighthouse. Fml.1
Before you ask, yes I'm garbage at front end development5
That nice feeling in a cold morning of booting up your code editor / ide of choice and making a brand spanking new prototype project with a language you love. All accompanied by your hot beverage of choice, a warm blanket, and a pet or two.5
> Reading closely the percona-toolkit docs
> Reach for a coffee mug for a nice sip of the dev juice
> Take a sip...
> ... of air - there was no coffee left
The morning is ruined now.5
It's crazy to me how much of a misguided superiority complex some CS college kids have.
"I'd never learn Python, that's just for kids"
"Front end is so easy, it's just HTML and making things look pretty"13
Don't buy the "We're bleeding edge, agile and embrace devops.". Those who proclaim that the loudest are the ones that think they do, but don't.
Oh, and any place that refers to employees as "tech ninjas" or "superstars" or anything cringy like that. Stay away.
This was more how to avoid shitty places. So to find a good place to work, use this statement in your search:
... // maybe you're lucky
Most successful? Well, this one kinda is...
So I just started working at the company and my manager has a project for me. There are almost no requirements except:
- I want a wireless device that I can put in a box
- I want to be able to know where that device is with enough accuracy to be able to determine in which box the device was put in if multiple boxes were standing together
So, I had to make a real time localization system. RTLS.
A solo project.
Ok, first a lot of experiments. What will the localization technique be? Which radio are we going to use?
How will the communication be structured?
After about two months I had tested a lot, but hadn't found THE solution. So I convinced my manager to try out UWB radio with Time Difference Of Arrival as localization technique. This couldn't be thrown together quickly because it needed more setup.
Two months later I had a working proof of concept. It had a lot of problems because we needed to distribute a clock signal because the radio listeners needed to be sub-nanosecond synchronous to achieve the accuracy my manager wanted. That clock signal wasn't great we later found out.
The results were good enough to continue to work on a prototype.
This time all wired communication would be over ethernet and we'd use PTP to synchronize the time.
There was a lot of trouble with getting the radio chip to work on the prototype, ethernet was tricky and the PTP turned out to be not accurate enough. A lot of dev work went into getting everything right.
A year and 5 hardware revisions later I had something that worked pretty well!
All time synchronization was done hybridly on the anchors and server where the best path to the time master was dynamically found.
Everything was synchronized to the subnanosecond. In my bedroom where I had my test setup I achieved an accuracy of about 30cm in 3d. This was awesome!
It was time to order the actual prototype and start testing it for real in one of the factory halls.
The order was made for 40 anchors and an appointment was made for the installation in the hall.
Suddenly my manager is fired.
Ehh... That sucks. Well, let's just continue.
The hardware arrives and I prepare everything. Everything is ready and I'm pretty nervous. I've put all my expertise in this project. This is gonna make my career at this company.
Two weeks before the installation was to take place, not even a month after my manager was fired, I hear that my project was shelved.
"We're not prioritizing this project right now" they said.
It would've been so great! And they took it away.
Including my salary and hardware dev cost, this project so far has cost them over €120k and they just shelved it.
I was put on other projects and they did try to find me something that suited me.
But I felt so betrayed and the projects we're not to my liking, so after another 2-3 months I quit and went to my current job.
It would've so nice and they ruined it.
Everything was made with Rust. Tags, anchors, RTLS server, web server & web frontend.
So yeah, sorry for the rambling.5