!!rant
!!ANGER

Micromanager: "Hey, Root!

Since you're back, and still not feeling well, we have an easy ticket for you: Rewrite the slack integration gem! Oh, you don't have to re-implement all of it, just make sure it all works the same way it does now. That bitch you worked with once over a year ago who kept throwing you under the bus to management and stealing credit for your work? Yeah, she wrote the original code like four years ago. It's perfect, so don't touch it. but she can fill you in on all the details you need and get you up to speed on how to test it.

But yep! It should be simple. and I just knew you would love this ticket, so I saved it just for you. Nice and quick, too, to get you an easy win.

You know, since you have to repair your reputation with product. and management. and the execs. and the rest of the team. and me. Yeah, product doesn't trust you so they don't want to give you any tickets. They just can't trust you to get them out and have them work. So you have a lot of hard work to do."

Spoiler: The bus-thrower wasn't much help. (Surprise.)
Spoiler: The ticket was already in my backlog -- one of a grand total of two tickets.
Spoiler: I don't find the ticket fun. Maybe if I was to write the entire implementation with a nice DSL? but no, "don't touch the perfect code." Fuck you.
Spoiler: It isn't going to be nice or quick. But, she (micromanager) is looking to lose me, so that really is an easy win. for her.

And. just. argh. fuck you. i've been exhausted and dying for well over a year, but you've kept ignoring that (and still are, despite me providing goddamn legal forms from fucking doctors stating it in plain fucking english, which you also fucking ignore), and you just keep piling on the work and demanding the ridiculous of me despite it. Yeah I can pull it off sometimes. No, I really shouldn't, and I'm surprised I can. (also, "Time off? What, and lower your productivity even more? ____ doesn't even take vacations. And how are you doing on that ticket?") And no, none of my tickets have ever had any fucking problems. Not even when there are upstream service outages. Not. a. single. fucking. one. Ever. And the only things I've ever missed were things that bloody product never put in the fucking ticket, so fuck you with your "repair your reputation" bullshit.

god, i fuckiNG HATE THESESTUPOID ANWETLJAF SAJEWTKW BITCHFACEDUCKFUCKERS

Why the FUCK am I still fucking working here?
Right, because I've been burned out and dying so much I can't pass a fucking interview so I can fucking leave.

jasdkl;fk

ugh. Anyway. If you ever find yourself starting work at a Cali fintech company whose internal mascot is a very fine duck? Just run. I absolutely guarantee you will be miserable.

micromanager: "Quick and easy win! Please have this done in 2-3 days to start repairing your reputation"

ticket: "Scrap this gem, and implement your own external service wrapper using the new and vastly different Slack API!"

slack: "New API? Give me bearer tokens! Don't use that legacy url crap, wth"

prev dev: "Yeah idk what a bearer token is. Have the same url instead, and try writing it down so you don't forget it?"

Slack admin: "I can't give you access to the slack integration test app, even though it's for exactly this and three others have access already, including your (micro)manager."

Slack: "You can also <a>create a new slack app</a>!" -- link logs me into slack chat instead. After searching and finding a link elsewhere: doesn't let me.

Slack admin: "You want a new test slack app instead? Sure, build it the same as before so it isn't abuseable. No? Okay, plan a presentation for it and bring security along for a meeting on Friday and I'll think about it. I'm in some planning meetings until then."

asdfjkagel.

This job is endless delays, plus getting yelled at over the endless delays.

At least I can start on the code while I wait. Can't test anything for at least a week, though. =/

What an absolute fucking disaster of a day. Strap in, folks; it's time for a bumpy ride!

I got a whole hour of work done today. The first hour of my morning because I went to work a bit early. Then people started complaining about Jenkins jobs failing on that one Jenkins server our team has been wanting to decom for two years but management won't let us force people to move to new servers. It's a single server with over four thousand projects, some of which run massive data processing jobs that last DAYS. The server was originally set up by people who have since quit, of course, and left it behind for my team to adopt with zero documentation.

Anyway, the 500GB disk is 100% full. The memory (all 64GB of it) is fully consumed by stuck jobs. We can't track down large old files to delete because du chokes on the workspace folder with thousands of subfolders with no Ram to spare. We decide to basically take a hacksaw to it, deleting the workspace for every job not currently in progress. This of course fucked up some really poorly-designed pipelines that relied on workspaces persisting between jobs, so we had to deal with complaints about that as well.

So we get the Jenkins server up and running again just in time for AWS to have a major incident affecting EC2 instance provisioning in our primary region. People keep bugging me to fix it, I keep telling them that it's Amazon's problem to solve, they wait a few minutes and ask me to fix it again. Emails flying back and forth until that was done.

Lunch time already. But the fun isn't over yet!

I get back to my desk to find out that new hires or people who got new Mac laptops recently can't even install our toolchain, because management has started handing out M1 Macs without telling us and all our tools are compiled solely for x86_64. That took some troubleshooting to even figure out what the problem was because the only error people got from homebrew was that the formula was empty when it clearly wasn't.

After figuring out that problem (but not fully solving it yet), one team starts complaining to us about a Github problem because we manage the github org. Except it's not a github problem and I already knew this because they are a Problem Team that uses some technical authoring software with Git integration but they only have even the barest understanding of what Git actually does. Turns out it's a Git problem. An update for Git was pushed out recently that patches a big bad vulnerability and the way it was patched causes problems because they're using Git wrong (multiple users accessing the same local repo on a samba share). It's a huge vulnerability so my entire conversation with them went sort of like:

"Please don't."
"We have to."
"Fine, here's a workaround, this will allow arbitrary code execution by anyone with physical or virtual access to this computer that you have sitting in an unlocked office somewhere."
"How do I run a Git command I don't use Git."

So that dealt with, I start taking a look at our toolchain, trying to figure out if I can easily just cross-compile it to arm64 for the M1 macbooks or if it will be a more involved fix. And I find all kinds of horrendous shit left behind by the people who wrote the tools that, naturally, they left for us to adopt when they quit over a year ago. I'm talking entire functions in a tool used by hundreds of people that were put in as a joke, poorly documented functions I am still trying to puzzle out, and exactly zero comments in the code and abbreviated function names like "gars", "snh", and "jgajawwawstai".

While I'm looking into that, the person from our team who is responsible for incident communication finally gets the AWS EC2 provisioning issue reported to IT Operations, who sent out an alert to affected users that should have gone out hours earlier.

Meanwhile, according to the health dashboard in AWS, the issue had already been resolved three hours before the communication went out and the ticket remains open at this moment, as far as I know.

Current work project is microservices architecture out of 4 - 8 components.

It is fully Infrastructure as a Code automatized. I just change somewhere code, git pushing

And it automatically invokes Gitlab CI, terraform, ansible, kubernetes helm charts.
Auto checking itself with unit and integration tests in autoredeployed staging env. Then it saves tested results to docker registry and asks for one button verificating click to be rereleased to prod.

I just go for drink or eat food. While all the stuff is happening.

And I am proud that all the infrastructure, backend and frontend I made on my own.

I don't need to remember how to Deploy it. It is all automatized

Worst collaboration experience story?

I was not directly involved, it was a Delphi -> C# conversion of our customer returns application.

The dev manager was out to prove waterfall was the only development methodology that could make convert the monolith app to a lean, multi-tier, enterprise-worthy application.

Starting out with a team of 7 (3 devs, 2 dbas, team mgr, and the dev department mgr), they spent around 3 months designing, meetings, and more meetings. Armed with 50+ page specification Word document (not counting the countless Visio workflow diagrams and Microsoft Project timeline/ghantt charts), the team was ready to start coding.
The database design, workflow, and UI design (using Visio), was well done/thought out, but problems started on day one.
- Team mgr and Dev mgr split up the 3 devs, 1 dev wrote the database access library tier, 1 wrote the service tier, the other dev wrote the UI (I'll add this was the dev's first experience with WPF).
- Per the specification, all the layers wouldn't be integrated until all of them met the standards (unit tested, free from errors from VS's code analyzer, etc)
- By the time the devs where ready to code, the DBAs were already tasked with other projects, so the Returns app was prioritized to "when we get around to it"

Fast forward 6 months later, all the devs were 'done' coding, having very little/no communication with one another, then the integration. The service and database layers assumed different design patterns and different database relationships and the UI layer required functionality neither layers anticipated (ex. multi-users and the service maintaining some sort of state between them).

Those issues took about a month to work out, then the app began beta testing with real end users. App didn't make it 10 minutes before users gave up. Numerous UI logic errors, runtime errors, and overall app stability. Because the UI was so bad, the dev mgr brought in one of the web developers (she was pretty good at UI design). You might guess how useful someone is being dropped in on complex project , months after-the-fact and being told "Fix it!".

Couple of months of UI re-design and many other changes, the app was ready for beta testing.

In the mean time, the company hired a new customer service manager. When he saw the application, he rejected the app because he re-designed the entire returns process to be more efficient. The application UI was written to the exact step-by-step old returns process with little/no deviation.

With a tremendous amount of push-back (TL;DR), the dev mgr promised to change the app, but only after it was deployed into production (using "we can fix it later" excuse).

Still plagued with numerous bugs, the app was finally deployed. In attempts to save face, there was a company-wide party to celebrate the 'death' of the "old Delphi returns app" and the birth of the new. Cake, drinks, certificates of achievements for the devs, etc.

By the end of the project, the devs hated each other. Finger pointing, petty squabbles, out-right "FU!"s across the cube walls, etc. All the team members were re-assigned to other teams to separate them, leaving a single new hire to fix all the issues.

- Be me
- Been in a new job for 2 months
- Was excited because of 50% salary increase and better position

- Have a new team of 6 devs including me. All new guy
- Market crash
- Top management demands a trim down to all divisions
- Will be left to 3 devs next month

- All the while being asked to
- Deliver a shopify like marketplace from end to end
- Deliver integration with partners for data inventory tracking
- All within 2 months

- Furious when target is not met
- Demands a micro management to every single person on the team on what their day to day schedule
- Demands everybody to live by hustle culture and ready to work non stop even nights or weekend

- Be me
- Been working non stop for at least a month
- Sacrificed weekends and holidays

Beginning to think that maybe the money and position isn't worth the hassle

Employer: Hey, we are moving an API update live tomorrow morning that could affect our apps. Can you regression test the apps to make sure they all work?

Me: The API team is pushing code overtop of live endpoints that can break them?

Employer: Yes, we need the updates to work with a new product we are developing.

Me: And nobody thought about versioning these endpoints so we guarantee uptime on all existing services using them now?

Employer: We looked at that but it cost extra and required us to use the cloud solution so we don’t use versioning.

Me: Okkk… I also take it that the API’s don’t have integration tests written?

Employer: What are integration tests? Are unit tests the same thing?

Me: No, so when do I need to regression test all 7 production apps?

Employer: The API’s are moving to production at 4am and we need it signed off by 7am.

Me: I only have 3 hours to regression test 7 production apps at 4am? Each app, if I just skim over them, would take me 2 hours each. I will do my best but that’s a very short time to ensure complete functionality.

Employer: Don’t you have unit tests?

Unpopular opinion: unit tests are often overrated.

Although a well written test suite is almost essential in some parts of the application (I.E. business logic) I cringe when I see hundreds or thousands of line which “mocks” everything to test a micro service which just does CRUD operations on a database, in cases like that unit tests are just a waste of time because almost every operation involves a mock which may not behave like the real database and often needs to be rewritten when the code undergoes a huge refactoring. In these case a integration test suite is faster to write and way more helpful.

probably every time I see my tests failing.

Each time I am writing tests I'm convincing myself "it's an investment", "spend 2 hours now to save 2 days later", "unit-tests are good".

And each time I'm chasing away ideas like "perhaps they are right, perhaps writing unit tests is a waste of time..", "this code is simple, it should ever break - why test it??", "In the 2 hours I'll spend writing those UT I could build another feature"

Yes, it is terribly annoying to write tests, especially after writing the production code (code-first approach). Why test code that you know works, right?

But after a few weeks, months or years, when the time comes to change your feature: enhance it, refactor it, build an integration with/from it, etc, I feel like a child who found a forgotten favourite candy in his pocket when I see my tests failing.

It means I did a very good job writing them
It means it was not a waste of time
it means these tests will now save me hours or days of trial-and-error change→compile→deploy→test cycles.

So yeah, whenever I see my tests fail, I feel warm and fussy inside :)

I’ve somehow ended up in a situation where I have a big project to work on - alone, since I’m the only dev in the whole company with any expertise whatsoever in that area… which is exhausting enough by itself, since I have nowhere to turn to when I struggle with it, no one to rubber duck with and share the workload with, no one to review my code. On top of that, I’ve somehow become thee go to dev resource when it comes to this integration, that client’s custom shit and so on. I’ve been doing this big damn project since late August, and I keep getting pulled off it for weeks at a time. I think I haven’t had more than a day or two in a row to concentrate on it for at least 3 months… and my manager keeps asking me when it’ll be done. What I’d give for a few more devs to share the workload with…

Why the fuck is gradle so horrible.

I literally have no idea why anyone would ever use this thing (other than being forced too because somehow the rest of the world is using it).

Every plugin has an arbitrary DSL that you have to magically know by piecing together enough snippets. At that point, no one is actually intuiting anything based on the beauty of the DSL, every build is a frankenstein of different snippets that were pasted from different versions of gradle blog posts or SO posts.

And if you do get it o work then the DSL changes, or it isn't compatible with another plugin.

I just want to write a fucking integration test in Kotlin. Can I just add an `integrationTest` task in `tasks` right next to `tasks.test`? No, obviously it goes in the `kotlin jvm() compilations` section, DUH.

The first thing anyone in the universe should have asked is "how is this better than literally hand writing a makefile"? At least then I would be able to see the commands that it ran.

Now I'm googling how to make the new jvm-test-suite plugin work when you're using the Kotlin plugin but every single result on Google for `jvm-test-suite kotlin` just returns the docs for jvm-test-suite (whose snippets obviously didn't work in my project) because those doc pages have "Kotlin" written above each of the gradle snippets.

Please just end this.

Oh and dev rant sucks too. It thinks anything separated by dots in a url.

Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.

Little backstory. Starts with a question.

What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?

Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.

Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.

Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.

I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.

When the requested change is replacing the logo but the integration to master takes a day

I hate it when I want to implement a 3rd party API and their docs have no hint at how to create a test account.. Why do they make me call their sales team / bother their support for that?

More fzf: deeper integration with other dev tools I use.

Two data pipelines, right before integration testing :)

I got both fundamental Azure and AWS certifications, need to choose one to stick to for the future, I'm leaning more towards AWS since it has over 50% more market share than Azure and a much bigger and more robust platform, I also really like how they constantly add new features and services and integration with third party software. Azure developers seem to get paid more though and I found its UI to be more user friendly so....opinions? 🤔

What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:

The classic "Can't access .root on unmounted test renderer"

The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."

We do love it!

There's no official integration (package) for JWT in Java Spring?

I am new to Java Spring and want to create a simple RESTful server with JWT auth. Checked many tutorials, all of them involved creating your own JWT middleware to retrieve JWT token from incoming request and validate it using some 3rd party JWT library like jwtk/jjwt.

I am surprised this is not as simple as including a Spring JWT package and it would work out of box. I used to write a similar site using Python/Django, and for that adding JWT support is quite simple as adding "xxx.middleware.JWTAuthMiddleware".