Ramblings of a man who hates code reviews.. Why do I have to look at and approve the code of someone who clearly knows what they are doing with no fucking context before it can be merged? Just run tests, linters and scans (or have automation do that) to make sure it's good and pass it forward. I'm not gonna take your branch and use my time to manually test your changes and I don't have enough information to question the choices you made in the code. Why do I have to do this shit?!

"Let's keep in touch": to your co-workers as you are leaving the shitty company after 3 years and other lies you tell yourself.

Damn I do not want to work in the US. First week I joined a new team the EM got fired and project manager quit. Four months later the CTO gets fired, along with other senior management, and teams get restructured just as we got comfortable. The mentality of just firing people right and left is so bizarre to me, holy crap! Are these people really that bad or causing some drama, or is the mentality just so cut throat that people can be kicked out if they don't suit the new plan?

I fucking hate phone calls. The quality is always shit, you have to respond to every question immediately and be in a place where you can talk. Then came the era of using instant messaging, chats, and I still get those fucking phone calls in Slack, even though you have the opportunity to write me a fucking message and I will get to it when I can!

What is one bug in a single service when cloud engineers bring down the entire environment with one config change?

This is the first project where I've worked with a separate QA department and it is pain. It's just handing out work and waiting for hours for them to finish testing a very small thing, and you just have to sit there, waiting, because context switching will end up messing something up. Then you get a failure, because you didn't replace an icon, that was in the design spec just as a placeholder, and you can't move forward because you need another icon too that was not included in the spec. So here we are, sitting and waiting for the designer to return from their holiday so we can have their feedback.

When I asked if we could just skip the icon and push to production, then wait for feedback and do another iteration if needed, the answer is a firm NO. It must be completed on this one test cycle because they're too lazy to do another test run.

Fuck you and your waterfall working methods!

- "Integrate this API to the front-end application"
- "Okay.. where are the API schema and docs?"
- "Oh there aren't any. You need to look at the iOS app code to figure it out."

Oh kill me already..

You try building a fucking app for a customer who responds to a list of questions with complete ignorance, but somehow expects a product to be delivered.

Some people really just have to assert their dominance in an organization. "WHY HAS THOU NOT INFORMED ME OF CHANGES HERE SO I COULD LAY DOWN MY JUDGEMENT ON THY CODE AND TELL THAT IT'S WRONG!". Fucking pay attention you cunt. I'm not gonna call you specifically when I do changes just so you can feel better to have some type of imaginary control of everything.

Why the fuck are people so concerned over not meeting their sprint goal? It's imaginary! It's not agile. It's a rigid boundary set by project management to make you accountable for completing a certain amount of work on a specific timeframe so they can monitor you and make sure you're working. It's the opposite of agility where we should constantly be responding to change. Fuck sprints! How about instead you just build trust and get shit done! No imaginary boundaries. The work takes as long as it takes, but you need to trust people to get it done!

Fucking five minutes before everyone goes on holiday, someone has to report a fucking bug and there's no one to fix it. I pretended like I didn't see that message and bolted. "Yeah, I don't know anything about that feature"

Continuing on the PR ranting.. That's six PR's in the queue now. The most important one took over a week to sort through because someone had a grand idea to generalize the work and that required a ton of changes. Great to receive that kind of feedback AFTER I've already done the work.. Then we waited on translations because can't miss those! Now the tests are failing. Not caused by me! Someone messed up the E2E tests. That's two weeks in the queue now.

Because one test is failing, that's a block across all the PR's. All of them have now been waiting multiple days in the queue. After someone manages to fix the broken test, all PR's go one by one into the QA testing queue and that takes 1-2 hours per branch to test and deploy to production.

Really love having a cycle time of four days for coloring a button differently! And the constant context switching.

Such a joy to attempt to update a commonly used library, where documentation is poor so your work just sits in a review queue because no one knows how publishing the package works.. Fucking great.

I am so sick of code reviews. I hate them so much. If you can't discover a bottleneck in your development flow, put in a code review and there you go! Since I wish to work using continuous integration any work I do takes maximum of 1 day. Then you open up a PR (because our proprietary software with closed source needs to copy the workflow of an open source project) and one dev starts thinking of all the ways this could be done differently and what type of responsibilities each component has and how we should avoid this and that and fucking TWO WEEKS LATER WE'RE STILL DEBATING THIS SHIT! FUCK YOUR FUCKING CODE REVIEWS! CONTINUOUS INTEGRATION IS NOW OUT THE WINDOW YOU FUCKING TWATS! AND ITS JUST A FUCKING DIALOG ON THE UI THAT MIGHT POP UP ON 5% OF USERS SO WHO GIVES A SHIT!

No fucking wonder we feel like our work has no meaning when I'm spending two weeks on meaningless shit like this! Does it work? Yes it fucking does. So why are we debating this shit?!

Fuuuuuck having 15 people on the team is just too much. There is nothing to retain from the dailys as it's just way too much information. This team needs to be split in half.

I should never have accepted this project. Having to work on a different time zone (remotely) and it's really messing with me because I have small kids at home. Kids wear me out before the evening is done. I can't participate in a remote call in peace. I should also be available for the team and especially QA because if they test my work and I'm not there, I am blocking them. This sucks.. Maybe I'll request to be transferred off this project because of personal reasons. Maybe I just need to fix other stuff like my sleep schedule, or eating habits, start exercising more to gain energy.. Idk.

Who claims code reviews actually work? It has always been a bottleneck in every single organization I've ever worked at. You work on a story for 1 day because you want to apply continuous integration as a practice, but the branch always gets stuck in the code review phase when no one reviews it even though you ask them to, someone finds something small that needs to be changed with it and that adds more delays, or it ends up being halted because another team member who works on another layer of the cake is making changes to their layer and those changes need to be synced. So instead of having a cycle time of 1-2 days, it always ends up being 1-2 weeks. Simply because of the review process. Why can't I fucking pair program with someone?! This is so stupid. I want to have feedback immediately as I work if you don't trust people with real trunk base development!

Hearing horror stories of people burning out from working 100 hours a week really makes me glad we have unions in Europe (atleast the nordic countries), who enforce certain work limits and I cannot be forced to work that much. I've actually only worked a handful of days overtime, and that was a pre-planned maintenance that we all agreed on. I will never take this job so seriously to work more than I need to and if someone tries to tell me to, I can tell them to fuck off and quit.

I just love these Shopify theme "developers". A customer has a theme that they have some problems with and here I am, trying to solve it and bumping into some interesting front-end coding conventions..

Lately as I've been reading about hacks in companies like Uber, Rockstar etc. I've come to remember my time at a company that worked like a feature factory, where developers constantly groaned about not having enough time to do things right. This had lead to having a few dozen people (both business and technology side) with direct access to the production database, just so they can do their jobs and that database was replicated across various environments just so they could develop on top of it, and do "proper testing".

The bad side is, this database contained the personal information of millions of the people (names, addresses, ssn numbers..). I saw this security problem, and always spoke out about it, but there was never enough time to do anything about it, like build the features the users need for them to do their job without direct access to the database. The app itself was a monolithic nightmare with poor development standards and holes here and there.

It only takes one person whos credentials could be compromised to bring that entire business down because all the data resides in one single database. However, they are lucky that there were at least smart people in the Ops department so they do have some good security measures in place on that side, because the development side was complete shit. Don't go lacking around with security!

Is it a job requirement for QA "engineers" to be like children? Because that's what it feels like.

Well.. some consultant sure managed to sell a bunch of nothing to a customer. Sure, let's move this website from one provider to another, that's more expensive on a monthly basis. That's the whole job.
...
What?

Your face when a customer's manager shares the credentials to at least five different production environment databases and third party services, in their project management platform (making them accessible to the entire organization) because they want to be a developer when they grow up.