SDET team writes automated tests. Devs self test some, SDETs fill in the gaps. Manual QA handles the stuff that's not worth automation.

Sounds great, but the process is a pain in the ass. Devs don't like the tests that SDETs write, but their feedback on PRs is bad. Manual QA doesn't know what's automated so they way over-test.

Everything is shit.

Sex, drugs, and rock 'n roll.

K8s learning path:

Junior: "I just want to deploy some services, I'll start with managed kubernetes."

Mid: "OK I understand a bit better, time to bootstrap my whole cluster."

Senior: "just use managed k8s."

How about: "yeah linux is super dead. That's why Microsoft put a bunch of dev effort into building the Windows Subsystem for Linux."

Been evangelizing warp.dev to stop this shit.

Terminal lets Jr send a link to output that's actually readable.

@thebiochemic carbon seems like it'll be great, but the repos Readme has a real "this shits not ready, but the marketing people dont listen" kinda vibe.

Containerized microservice? May need to give the container runtime some of that memory?

Wow, ChatGPT already learned the most important programming rule: never work for free.

@illuminaughty uhhhhh idk about you, but I haven't had my foot chopped off for leaving work early recently... so no. Not at all the same.

Also relevant, I dont think this about forcing developers into submission.

I didn't feel dominated by anyone using main as a default branch name.

Sure, GitHub is just playing lipservice to racial equity on this one, but I seriously doubt that they had forcing me into submission in mind when making that change.

I mean, isn't having to use "master" as a branch name way more dominating? We didn't complain about it then.

Like why do we actually give a shit about this? And not just it's symbolism of forcing us to do something or being bullshit, do we actually care about the material change to our daily life?

I don't, got way more bugs to fix than allow something like that to annoy me.

@nururururu yeah I get that, the white liberal progressive stuff can definitely water down real progress in tech and I don't think there are a ton of people who are offended by it in reality.

I just don't care about having a branch named master at all. It can make some sense, but it's not a cultural thing for me or even something that technically clarifies its role to a newcomer better than develop, prod, main, whatever.

So if there's a one in a million chance someone is offended by it, chuck it to the wind, it doesn't matter. That doesn't apply to everything, but in this case, I think devs are way overreacting to the significance of this branch name.

If you're angry that white liberals are doing this instead of halting police brutality, I'm right there with you, we should be focusing on other things.

@Grumm I get where you're coming from, but I think thats a bit of a slippery slope fallacy.

Like, vegan vs meat is a good example --- having a master branch isn't a part of my identity, whereas choosing to eat meat is definitely a personal choice.

But seeing master as the language used to describe a branch could remind someone who has an ancestry of being enslaved of messed up stuff and make them uncomfortable. Not really my place to say they shouldn't be uncomfortable, even if the context doesn't make sense.

Trauma responses are often not rational, doesn't mean we should ignore them.

Idk, seems like a small courtesy change to me.

In reality, I think the better argument against this change is that it doesn't make tech more accessible to underrepresented people, it's just a rhetorical change that feigns being progressive.

But at the same time, then why wouldn't I be OK with it?

We use develop. Have been for years. Main and master are actually way more ambiguous than develop, prod IMHO.

Master/slave language also just isn't a fun reminder for folks who are less represented in IT regardless of whether or not its actually referring to slavery (lookin at you, Jenkins).

If it makes someone more comfortable working on my team, why wouldn't I change it if i can?

Depends on the language. C++? Hella commented. TypeScript? Ehhhhhh.

We only use comments to describe something that has a use which isn't obvious from the code.

Doesn't help a guy like me that wants explanation for why we needed each tailwind class to make it work because I suck at css, but overall the code is very readable.

It is great for simple use cases! We played with Nomad for a while and found that config flexibility was a problem. The supported hcl fields worked for a bit, but stuff like getting secrets into artifact requests is actually not possible, so getting secured artifacts had to be bash scripts within templates.

Don't jump in head-first until you've checked that their approach to deployment phases will work out for you!

CoderPad

@Sylum haha yeah good point. When I stagnate or feel it's not a challenge/maximizing my skills, I may consider an internal transfer (that's how I got this position).

@johnmelodyme good on you mate. You're what we aspire to be.

On premise data center.

Want serverless functions? OpenFaaS, self-hosted (is this still serverless? Lol)

Want s3 buckets? MinIO, self-hosted.

Want an entire cloud platform? OpenStack, self-hosted.

Do absolutely everything yourself motherfucker. Raspberry Pi cluster all day.

Failing that, DO is pretty good. AWS is great, but it costs $$$. Cheers.

Fast AI course is awesome if you want to get usable skills in a short period of time.

Its top down, so you learn theory after you've learned the practical stuff and that's often very helpful.

You dont strictly need any Java. Kotlin, dart/flutter, react native, swift cross-platform, and python can be used to develop on Android.

There are other options, though many default to Java fsr.

I wouldn't cancel an interview with a company you're interested in until you've received a paycheck from the company you've joined and aren't planning on quitting.

There's a moralizing argument that if you accept a position from a company, you should spend n number of days with them before leaving, going to another company, or whatever.

But you really only know a company (and your team) once you sit down and start submitting PRs, joining standup, etc.

You might accept from company C, cancel interview with company B, go to work for 2 weeks and hate your life, wishing you'd at least tried to interview at company B.

Keep doors open until you're forced to close them or close them willingly because you're no longer interested in the opportunity.

Yeah I get this.. I'm a queer dude, so i often feel like my success is supposed to be more than me pursuing a goal.

It's supposed to be this beacon or something that other people who are like me can do this, which is great and all, but that's a lot of extra baggage when its already hard enough to just make the fucking software work.

If your dream is to prove x type of person can do y type of thing, great.

If you just want to do it to prove yourself as you (regardless of what you are), great.

Pursue what you want, tell anyone who says you cant do it to fuck off, and know that everything else is a sideshow.

Except CSS and stuff. That will always suck. Tailwind is all I can handle.

As a backend dev, I have managed to like react.

Things like Crank.js might actually make me love the frontend.

Find the shit that works for you bro. It can be pretty fun to create UIs.

Also it's free and has open source code for everything that it works through with a supportive and active forum.

The fastai course. Its code-first top-down learning with excellent plain language education. They really do break down the complex language and just tell you what's actually happening and let you learn by doing.

if you are learning go on a whim, i'd recommend reading this as a precautionary measure: https://fasterthanli.me/articles/...

if you are learning golang because you have to or are into it pretty deep already, ignore that article, it won't be encouraging and instead check out some of this: https://golangdocs.com/

there's also these: https://pkg.go.dev/google.golang.or...

hope they help, peace

@jotamontecino don't get me wrong, i write and like javascript - but it is very easy in JS - and frequently done - to fuck with people in the writing of your code by aliasing, indexing, re-exporting, etc due to the way JS handles modules and whatnot.

I'm not saying my code is shitty because JS is shitty, I'm saying there's no constraints in JS that encourage more explicit and stable mechanisms for naming --- the kind of laissz-faire, write whatever however approach is convenient, but the cost of that convenience is standardized, readable code.

Clearly, a good engineer with a head on their shoulders and a brain thinking about all of the audiences for their code can write beautiful, readable code in just about anything.

Except lisp. we don't talk about lisp.

also, sidecar: this is an argument for snake_case code style.

create_mongo_client_server_connection forces you to admit you want to add 4 underscores to a single name. It looks wrong, on sight. camelCase lets you flowingly string together excessively long names and have that flaw blend into the background of the language.

likewise, a snake_case convention explicitly discourages over-shortening your names to cdbc() by forcing you (in the "good practice code style" kind of way) to explicitly separate the words of your variable names with an underscore if they are meant to convey more than one word.

connect_to_mongo. create_db_connection. read_csv. read_csv_s3. see how nice? join the snake_case gang.