I'm glad that the projects I worked on, which used webpack, already had all necessary config and just worked. I never had to touch anything webpack related. Same with CRA bootstrapped React apps that I used

I still don't know if webpack has necessary complexity or unnecessary / accidental complexity 🤦‍♂️ I never even wanted to try webpack or learn webpack. I have used webpack a few times in existing projects. I usually went with parcel.js just for simple projects, because it worked with zero config usually for my basic side projects

Me *thinking* : meh, I know all this

* After a moment *

Me *thinking* : wait, did I really know this or think about this before this person mentioned it?

Me *thinking* : oh I know That. But I didn't know all of the other stuff, I'll go figure

Me *thinking* : it's so good I'm shutting up always, regardless of if I know it or not. Let everyone think idk anything, lol. I'll have to deal with the show offs and all the flaunting and boasting though...right...

Software is messed for the most part. Many things ain't intuitive. Many things are not simple. Too many features, including complex features, too many fucking complex things, but we can't get our simple work done with powerful tools because they are also dumb usually. Debugging is a nightmare usually. We need debugging handbooks for every fucking thing. And debugging tools and diagnostic tools and monitoring and observability tools for everything. Fucking automate all the debugging and tell me what's the next step I need to do. And I hate non actionable errors the most. Silent errors too.

Software breaks all the time. :/ People need to get better at building software. :/

@devphobe ooooooh. I like the sound of that. Not sure about the boss though 😜😂

@Demolishun Lol 😂 Good one!

@Benutzername haha, more of a metaphor

A better elaborate version -

Hired developers *mind*: "Why the fuck is this small work done by my team? My team is such a big team! Why so many people for this work???!

Why the fuck is this work done by a my team (a different team) and not by the same team that built the product? Oh, they don't have bandwidth? They want to parallelize? And all decisions still have to go through the product team? They have months of experience and context? We have to gain all of that from docs or slack messages or extract it from them if it's not available in docs or slack? Depend completely on them? Right"

I remember doing this, to make the module "testable". The actual code was such a mess and I couldn't even see that from the bubble I was in. Now I don't ever wanna write code that's complex / not-simple

@iiii I guess every company deals with such things differently. Some companies would just split responsibilities. People who like to do just one thing would love such a setup. Some companies would just say "as a dev, you need to know everything we use" and this also helps with situations when someone goes on vacation or is sick, or leaves the team or company. People do pair programming and what not for similar reasons. People who love to learn everything and learn things across the stack would love such environments

@ItsNotMyFault It makes sense. I understand that small companies might be doing this or even big ones if they don't want to cut down software development into very very tiny parts and assign it to teams and then make communication as the friction among teams. I just think that the company should also be aware that their developer is gonna end up doing a lot of things when doing all of this and that it eats up the time taken to build the actual software with business logic. And not all businesses are about Kubernetes. I also understand that availability, resilience, possibly reduced cost from shared infra if resources were underutilized before are all good things that come from orchestration, it should also be noted that more new systems, especially distributed systems means more complexity and also more time spent on maintaining and working with them which also comes with a cost. If it's a conscious decision, fine 🤷‍♂️

@Lyniven A Dev's job is to spend more time on business problem, than learning Kubernetes. And for deployment they only need to do a few things - define their service's deployment saying where's their repo / artifacts like Jar etc, how many instances or replicas, port exposing information maybe, kind of deployment like canary etc and configuration like environment variables / files etc, how to run their service with a command, any pre run commands like DB migration command, if service needs extra components like DB so that they can provision one with a click a get connection details. I think they really don't have to know if behind the scenes of docker is being used or Podman, or Kubernetes, or Nomad or whatever, or just plain old VMs with no platform for that matter

@Lyniven Kubernetes has become a monster and I think developers should be saved from it's complexity. Because learning Kubernetes is no easy task and if companies are gonna pay developers to learn and use Kubernetes, and spend time in that too, apart from mainstream work, it seems a bit much. Devs just need some tools and what not to work with their services, regardless of what platform it is on. Be able to build, test, run and test locally and in any environment the same way, without worrying about things. I mean, Kubernetes environments can have tons of issues - which are not related to the developer's service. And it's hard to even tell if it's a platform (Kubernetes) issue or service issue at times. I think we can do a lot better

Idk about the exact ideal situation, but surely the current situation ain't that great according to me

@Lyniven More like, if there's an issue, I should be able to debug it without having to learn too much stuff. I want logs? I should be given some tool or GUI (web UI or something) to see the logs. Do I need to ssh into the environment? Have another tool for that. But asking Devs to understand Kubernetes, Kubernetes resources, and all the CRDs that are being used, it's just too much I think. A CRD can work in any way and one has to go learn about that in the CRD's docs

@Lyniven It's the perspective. Maybe useful for all the operators, sysadmins. But developers really don't have to know what's going on behind the scenes. They just need to solve their fucking business problem which is usually unrelated to Kubernetes and move on. Only Kubernetes based business folks have to learn all that. And then operators, sysamins could learn it, set it up, whatever. All these companies asking a single role to do everything and learn everything, when the main thing is - solving the business problem which itself is a very complex thing usually

Frontend and JavaScript have become a monster. Too hard to tame them. People are building more and more tools to tame all this monster complexity. Slowly those tools also inherit some complexity to get all the knobs and configuration. It's a crazy world

Omg. Same feeling after changing jobs recently :(

Well. People love numbers game..:/

@kindawonderful Yeah :) I mean, I usually have had only one commit PRs and have always amended commits in local and force pushed. So, all good. Also GitHub supports squash in Web UI, but yeah, some prefer doing custom squash in local with small message

@hjk101 I agree with all the points. I've infact worked with GCP (GKE), and I'm also a helm contributor.

I have enough experience to say that we can still do better. Currently the way we do it better is we provide high level tools for abstracting stuff. I'm not sure if the low level tools and the system are really that great. That's why I want more solutions. More innovation. Instead of just having one solution and a monopoly. In that sense, I like there are some solutions. But I would like to see more.

@hitko I want competition. More similar miracle solutions. Different implementations.

@Tayo I'm not talking about the concepts. I just felt there could be a lot more innovation as to how the end user (non ops folks) uses the software. I think currently it's just too bad. Beginners struggle. Also, Kubernetes and Docker are not the only softwares present. And containers is not magic. I understand it's good. Yes. Agreed. I mean, hell, even I might be using it if I build a company. But idk, I'll also check other alternatives, like uni kernels, micro VMs (firecracker), Nomad, Apache Mesos, and see what works for the use case and see what options are out there. Kubernetes and Docker are just famous and has a big community. Yes. Unfortunately it looks like a monopoly. I want some competition and good user experience. For end users, and for Ops folks too! Surely it's not good enough currently is what I feel. Yamls and what not. And quite some learning curve.

@irene I want the usage at least to be simple :/ and software code itself - only simplicity is easier - for more contributions. And for easy change and debugging. Or else people are just gonna shy away from it. Also, tests! To keep it robust, no matter what

@Root I hear this a lot 🤦‍♂️ We build complex tooling and then more tooling to make it easy. Not sure what's the reason or how to make it better. For now I'm sticking to making tooling to make things easy

Fuck yes