Tomorrow is Monday, and that means new sprint and the morning is once again starting with standup.

There are about 250 working days in a year (plus or minus), and that's 250 useless standups where people are not listening each other (with usual "'Yesterday, I completed this, today I will do that, no blocks") or at worst discussing some design decisions and 15-minute meeting are taking 30-45 minutes.

The management also doesn't have a lot of use, because almost daily they have separate meeting with each software engineer to update on a status of current tasks.

DevOps is a huge scam.

Whoever sold companies maintenance-free cloud is God-tier marketer, they would be able to sell fire extinguishers in hell.

First, the platform is constantly moving, keeping up with all the updates for Kubernetes/CNI/Ambassador/Calico/kube-proxy/wtf/foo/bar/etc requires a huge team constantly peddling the boat; and if not updating in time - eventually everything will suddenly break when AWS deprecates old Kubernetes version (1.23 in EKS has just 1 year and 2 months (!!!) of support) or whatever else. At least they don't deprecate services that often.

Second, all other tooling either suck, or expensive as a Boeing. DataDog/Splunk/NewRelic/Grafana? Data centers were built for the monthly prices of these tools not so long time ago. But, capex vs opex, what stupid software engineers knows (though, it's hilarious to be present on a meeting with an agenda "reduce cloud costs").

That's all really.

On the bright side, when the team is solid and really care about the product and build it in a cloud-first manner (with understanding of all the requirements, caveats and limitation) - it can be rock solid, stable and fast platform.

To bad it's incredibly easy to implement some impressively wrong architecture (much more easier than f'up single-server architecture).

StackOverflow Jobs was the best platform for finding and posting jobs: quality candidates, quality job postings.

I hope that whoever decided to kill it got a huge pay from LinkedIn/Indeed.

But it's loss would be felt for years to come.

And, who have any suggestions similar to StackOverflow Jobs?

I am tired of a glorified code monkeys cosplaying software engineers.

Disclaimer: in general, I have immense respect to engineers and technological advances that came from FAANG/MANGA. Bbbuuuuttttt...

Especially people that has a few relatively short (less than a year) stints in a few of them and thinking that their salary expectation for their skills is reasonable.

What I've saw so far, based on a few hires for past few years in a company of ~50 engineers, Python/JavaScript stack, monolith to microservice transition (all people had senior and above titles):

* Have no idea how to setup own development environment on MacBook.
* Have no idea how to run code and tests for Python (from discussion, the two only development experience was "code - commit - push - done" and "clicking button in remote coding environment".
* Have no idea how to use bash/zsh (the person had "Linux skill up to 11").
* Grinding leetcode and interviewing during work hours (were let go immediately).
* Introducing a new microservice for each task (we're transitioning from Django monolith, but not to that extent).
* Ignoring all the onboarding, documentation and ignoring every request for writing documentation "I am not a technical writer".
* Knowing nothing about Kubernetes (this was in the job posting/requirements).
* Person actively hostile to any frontend task (the position is not full stack, but JavaScript is a required skill).

I am pretty open and I understand the eternal "generalist vs specialist" thing, but if the person do not posses certain skills and actively lie about it, just because "I worked at FAANG companies, obviously I have that skills" - it's dishonesty at best and fraud at worst. And if with the end of ZIRP you suddenly became unhireable in FAANG/MANGA - you need to think why.

There are tons of small software companies that nevertheless have a good salary and benefits, and most of the time hiring was a breath, because for the most of the people they were flying under the radar.

Unfortunately, since this year the hiring is exhausting, the amount of incapable candidates is incredible (a lot of them with credentials), and instead of 10-15 candidates per position (before and during pandemic), now there are more than 300 candidates per position with "impressive" working experience and only 10 people who really spend time on interviewing.

In short, if you think you're worth gold only from 3-4 companies in the world and all of them stopped hiring you - you should rethink your worth.

The term "serverless" has been popping up more and more in the tech industry, boasting the benefits of not having to manage servers and providing a more cost-effective solution for businesses. However, if we take a step back and think about it, isn't this just a marketing ploy?

The reality is, serverless software has been around for decades. Before the cloud became a popular option, we had software that could be installed and run locally on our computers without the need for managing servers. This was essentially serverless technology, but it just wasn't called that.

Now, with the rise of cloud computing, companies are trying to capitalize on this buzzword by promoting their products as "serverless", even though they still rely on servers in some way. It's almost laughable that we are being sold on a concept that has been around for so long.

In addition, the term "serverless" also gives the impression that there are no servers involved at all, when in reality, there are still servers powering these cloud services. It's just that the responsibility of managing them now falls on the cloud provider instead of the business.

The truth is, serverless technology is not new. It's just a rebranded, hyped-up version of what we've already had before. Instead of constantly chasing after the latest buzzword, we should focus on the actual benefits and capabilities of a technology, and not let ourselves be swayed by clever marketing tactics.

So, let's not get caught up in the serverless hype. Let's remember that we've had this technology for a long time, and instead of focusing on the label, let's focus on the functionality and value it can provide to our businesses.

It's utterly frustrating to work with someone who has been in the same job for five years but still hasn't bothered to learn the basic tools necessary to do their job effectively. It's like they're stuck in a time warp, refusing to adapt and improve their skills.

How can you possibly expect to be successful in your career if you're not willing to invest time and effort into learning the tools of your trade? It's not rocket science, and these tools are there to make your job easier, not harder.

And what's worse is when these same people complain about their workload, blaming the tools for their inefficiency. Well, guess what? If you took the time to learn how to use them properly, maybe you wouldn't be drowning in work right now.

It's not even about being tech-savvy or a quick learner. It's simply about taking some initiative and responsibility for your own professional development. It's about having the basic level of competency required for your job.

Not to mention that constantly asking for help and guidance on tasks you should be able to handle on your own is not only a waste of your colleagues' time but also reflects poorly on your work ethic and reliability.

So, please, if you've been in the same job for five years and still struggle with basic tools, do yourself and your team a favor and take the time to learn them. It will make everyone's lives easier and improve your chances of success in the long run. Don't stay stagnant and hold yourself back – embrace opportunities to learn and grow. Your career will thank you for it.

The tools in question is Kubernetes and it's directly related to the persons day-to-day work (SWE + SDET mainly), 5 years is more than enough time to learn and adapt to a new toolset, and yet this particular person refuses to invest time into it. It's frustrating, to say the least, but also a disservice to themselves as they are limiting their potential and hindering their own career growth.

let RANT = $state(true);

Don't even get me started on frontend engineering right now. It's like the wild wild west out here, with no rules or regulations.

I mean seriously, what is going on with frontend engineering these days? It's like we're stuck in some sort of weird limbo state where nothing seems to make sense and everything is a struggle. And to top it all off, the project I've been working on for the past two years has the same damn issues as an existing codebase that I was hoping to leave behind.

For some reason the npm build runs when container starts. Are you kidding me? Every time I have to restart the app, I have to wait for 30+ minutes just for the damn thing to build. And what's worse, it's not even a complex app. It's a simple frontend for a research website. So why the heck does it take so long to build?

I'll tell you why, because some genius thought it would be a good idea to build the entire codebase every time the container starts. And I have no doubt that this same genius probably thought it would be efficient and time-saving. Well let me tell you, it's neither efficient nor time-saving. It's just plain infuriating.

And don't even get me started on the codebase itself. It's like a labyrinth of tangled and convoluted code (multiple versions of React and now rewriting on Nextjs). Trying to make even the simplest changes feels like unraveling a giant knot (every freaking component have it's only style and everything from React is being used - hooks, Redux, whatever else is popular). And heaven forbid you make a mistake, because then you have to wait another 30 minutes for the whole thing to build and see if your change even worked.

And let's not forget about the old codebase that is still being used, because the new one wasn't ready in time. So we're constantly having to switch back and forth between two different codebases, trying to remember which one has which functionality, and hoping that we don't break anything in the process.

Don't get me wrong, I'm not against rewrites. In fact, sometimes they are necessary for a project to move forward. But when frontend engineers can't seem to make up their mind and constantly want to rewrite the code, it's a recipe for disaster.

And don't even get me started on the experience level of the frontend engineers who started this project. Most of them only had 2-3 years of experience (at the time of inception some of them has less than 1 year of experience), and yet they managed to convince management to approve this mess. It's like the blind leading the blind.

But hey, who needs experience and expertise when you have shiny new technologies and frameworks to play with, right? Isn't that what matters most in frontend engineering these days? Keeping up with the latest trends and constantly jumping on the "hype train" without any real understanding of how it will impact the project in the long run.

As a backend engineer (so I kinda don't give a flying freak about frontend) with almost two decades of experience and who was doing frontend with jQuery back in 2005 - that's frustrating and all the inconsistency is literally killing people (a couple of clients literally dropped the contract because of frontend quality).

RANT = false;

PS: why I used Svelte runes? Because some freaking genius suggested to port new (unreleased, only beta version) frontend UI to Svelte 5 because of runes.