Senior dev: We’re building a sandwich. It needs a roasted tomato, thin sliced, X mm in thickness. Add some bacon. I want mayonnaise but it needs to be feature gated.
It generated the entire comment service and I’ve not noticed any issues with how it functions. I kinda took note of that specifically because I have never seen GORM used that way.
I think every senior dev today should maintain the stance that if nobody will employ us, we should compete. If I ever end up in a position where I’m unemployed, I’m going to just use my skills to segment and dilute the market because idle hands and all.
Absolutely, that mindset is powerful. If no one’s hiring, then build, ship, and disrupt. The barrier to entry for launching products is lower than ever, and experienced devs have the rare combo of technical ability and market awareness to actually make an impact fast.
Plus, there’s a kind of poetic justice in turning rejection into innovation.
What kind of product or niche would you go after if that time ever came?
The entire gig economy developed through apps like Uber look weak to me. It would be really easy to make a competing app that gives more negotiating power to the drivers for their fares. Also I don't need a % based processing cut, I just need $1 - $5 per ride, flat rates feel better for both end users involved in that type of product. The marketing campaign should be easy for this too.
Kubernetes just kinda won the container orchestration war against swarm, nomad, and mesos. It is quite an improvement over working with those orchestrators.
My strategy involves building stateless apps with distributed services that have good support in Kubernetes like Yugabyte and Minio.
What I do is host the thing on a cheap cloud server until it grows enough to need HA or scaling. At that point I move my workloads into a cluster.
I already have everything patterned out though so, I’m living in some sunk costs if anything newer or truly better comes along.
I just don't see what doesn't "scale" exactly here. Been using k8s for 7 years, never had a problem that wasn't my own fault. Even for parallel processing, I feel like there's so many options and patterns to use because it depends on the task the job does.
I'd say here, that's may not be about the scalability itself.
For me, it's more about convenience. I have been using k8s jobs for a while now.
for some reason, the company I work for wants to fix bad architectural decisions with k8s jobs :)
We had a bunch of issues with k8s jobs, but you are right none of them were k8s fault. But having a need to monitor them, and dump the logs to Loki or DD, made debugging quite complex.
If you need to restart the job devs would go to DevOps slack channel, for the job to be fired manually, etc.
IMO, k8s jobs are more for devops & infra team tasks, not for developers. The biggest upset is the need to spin up the containers for the job to be executed. We put out jobs inside services, so you could call script that has a db conn and it does the job, but we need to isolate rabbitmq connections to not accept messages while the service is in "cron-job" mode.
I know this is more our problem, than the issue with jobs, but still. I have never seen cron jobs implemented with no issues.
This entire article is laughable. Back when I was in the dating pool, I encountered a couple of women that had this mentality that they would be dating down because I don't have a degree. Unbeknownst to them, I commanded a six figure salary and it was I who would be dating down had I stuck with them and their poor worldview. This mentality needs to just stop though, the idea of "dating down" or "dating up" is just nonsense.
Junior dev: Make me a sandwich.
Senior dev: We’re building a sandwich. It needs a roasted tomato, thin sliced, X mm in thickness. Add some bacon. I want mayonnaise but it needs to be feature gated.
One sandwich later. . .
Senior dev: where’s my bread man?
reply