Details
-
SkillsAWS and Azure deployment/automation, Python, Go, Java, Linux Shell, PowerShell
-
LocationUnited States
-
Github
Joined devRant on 12/13/2018
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@b2plane I'm no expert on hiring or HR or anything so take my words with a grain of salt, but as far as I know, companies don't actually like talking to each other. Blacklisting you globally is basically impossible unless you're in a very small, specialized field where everybody knows everybody. There's no global database of job applicants. Someone with a massive personal vendetta against you could maybe make it harder to find a job, but most companies couldn't give less of a shit if you end up working for a competitor because they didn't want to hire you.
Also, that kind of blacklist is actually illegal in many US states (and probably a lot of other countries too).
They might put your name on an internal "do not hire" list, but the odds of any other company seeing that list are almost non-existant. -
@b2plane they'll probably just toss your job application in the trash and hire someone else.
-
@b2plane its usually part of the background check. If it's not included in that, then they usually just call the companies you say you worked for and ask when you worked there and what position(s) you held.
Employment history is the most common thing people lie about on resumes so most companies put a lot of effort into verifying it. -
That's actually one of the very few things on your resume that prospective employers DO check. Not always, but often enough that lying about past employment is pretty risky.
-
@aviophile Well, they're not forcing you to stop using master, so that comparison is a bit flawed. They changed their default for new repos but you don't have to use that default setting if you don't want to.
Nobody's forcing anything. It's entirely social pressure and if you don't want to give a shit then you don't have to. -
@IHateForALiving I really don't care what the default branch name is, and I had no reason to insist on keeping it the same. So I chose to put in an afternoon of work, one time, to rename everything I own. Pointless? Perhaps. But also incredibly trivial, so why not?
I spent more effort complaining about the change than actually doing it. -
I complained a lot about the master-to-main rename a while back, but actually making the switch to main took maybe an afternoon and then I never really had to think about it again.
I guess if your CI pipelines are complicated then it might be an issue. I wrote a script that renamed the default branch to main on all my repos, cloned them, did a simple find/replace on the workflow definition files, and committed and pushed the changes. Easy.
Honestly it would have been more trouble in the long run to NOT make the change and deal with the probably-inevitable complaints from people who cared more than I did. -
Updating is important, and it makes sense that they'd rebuild it on a newer base image, but not without bumping the tag, for fuck's sake. That's just a recipe for pain.
-
@asgs "Cloud" is more specific and relevant though, and "I know cloud" is basically true for almost any definition or subcategory of "Cloud." I've used every major cloud infrastructure provider. I've dabbled in almost every IaC language. I've dealt with almost every aspect of enterprise cloud from design to deployment to disaster recovery.
-
Imagine any data you send to ChatGPT is actually being sent to a random stranger you don't know, never saw in person, and don't trust at all. That will make it much easier to make value judgments.
-
I'm really tempted to delete the many buzzwords in my Skills section and reduce it to just "Cloud, in its entirety."
-
*laughs in github org admin*
If I want to merge an unapproved PR, they can't stop me. -
Well, it's been five years... I'll let you know when I figure it out.
-
They use different words to describe things which are basically the same. If you learn one, it takes maybe a day or two to become reasonably competent in any of the others.
Which to use really depends on what you want to do with it and the major difference usually boils down to price. AWS is cheaper for this set of resources, while Azure is cheaper for that set, and GCP is better for that other thing.
Under the hood the differences are minimal. -
I've had failed updates on Windows, Mac, and Linux but only Linux actually tells me what the hell happened. If you don't know the meaning of the error message you can paste it into a search engine and because it's so verbose and specific, you'll get useful answers.
Last time my Mac failed to update, I only knew it failed because after rebooting I was still on the old version. No error message. No intuitive location to find logs. Just had to try again and pray.
Last time Windows failed to update, it just said it failed. No additional information that I can recall. I broke Windows Update for a year or two and I'm not sure if it fixed itself or one of my hail mary fixes actually worked.
When Linux failed to update, it told me which repository caused the error, exactly what url it failed to reach, and the error message returned from the server. -
That's because nobody actually uses the ÷ operator instead of a fraction unless they're deliberately trying to confuse people (or entering the equation into a simple calculator, I guess).
-
Why on earth would the *Director* be responsible for indexing data?
-
I have two entirely separate accounts on GitHub, one for work and one for personal use. At first I messed around with aliases to swap my username and email as needed, but then I found an easier way. If your folder organization isn't a complete mess, you can use conditional includes based on the repo path.
[includeIf "gitdir:~/work/"]
path = ~/.work.gitconfig
Then I just have my work username, email, and gpg key configured in that .work.gitconfig file. Any time I perform git operations on any repo under ~/work, it includes that other config file, overriding my personal credentials with my work credentials.
More details (and probably a better explanation): https://medium.com/@mrjink/... -
And this is why everything I self-host runs on docker if the option exists. So much easier to deal with containers.
-
It was always bad. Working remotely during COVID made it worse. It hasn't gotten better despite some people returning to the office.
I spend at least two-thirds of my time in meetings. Usually more. Usually scheduled so that my morning is booked solid and my afternoon has no uninterrupted period of free time longer than an hour.
I had to set up a recurring calendar event for lunch or I wouldn't have a chance to eat until 2. And that doesn't stop everybody since I still get meeting invites during time I've blocked off. It's the worst. -
@SuspiciousBug it's the usual wash trading to prop up the value combined with people trying desperately to get rid of their shitcoins and near-worthless NFTs by trading them for BTC/ETH.
-
@netikras If the list is 800 items, just give up and reinstall Ubuntu lmao
-
Look at the list it gives you before you type Y, and you won't have this problem. If you're really cautious/suspicious of orphaned dependencies like I am, check why each one was originally installed before confirming the autoremove.
I can understand not realizing that a package named "gir" will break things if you remove it, but if you managed to autoremove your Nvidia drivers, that's on you lol. -
One of many reasons why I don't use Word any more unless it's unavoidable.
-
Now I'm curious how HR fucked up. There are so many possibilities...
HR fucked up with one of our contractors a while back. His contract was officially renewed but someone forgot to update the end date in whatever database HR uses to track that. He showed up Monday morning expecting business as usual and his badge didn't scan so they wouldn't let him in the parking lot. He thought they'd changed their minds and fired him. -
I've been working for an insurance company for six years (2 years IT support, 4 years Cloud DevOps). It varies widely between exciting and dull depending on what you're working on, though I'd say it probably trends more towards dull. I find what I do interesting and the stuff I work on in the cloud space is relatively new, but I'm not *revolutionizing* anything. I'm totally fine with that and I'm still constantly learning new things because cloud services are constantly evolving.
Pay is pretty good, though they might try to lowball the initial offer so you might need to negotiate. Benefits are great. Job stability is unparalleled. Insurance companies are generally profitable even during market downturns, so you should see consistent raises and bonuses.
It's very traditional, sometimes enough to feel smothering.
Security, stability, and maintainability will be your most important goals. No "move fast and break things" when the company stands to lose billions if you fuck up in prod. -
I had to perform some archaeology/investigation/surgery today. Digging up an ancient code base developed by people who quit two years ago, investigating it to figure out why it was so absolutely broken, and then surgically removing a dependency that stopped active development three years ago and finally started presenting issues recently.
I want to bomb the whole codebase and rewrite it because it sucks. I just don't have time for that, lol. -
Apply to those jobs anyway. Tell them you're willing to learn AWS and Azure. That's pretty much how I got my current job, because they couldn't find any experts willing to take their admittedly-low salary offer. I took it because it was a big bump from my previous earnings and because the only relevant experience I had was tech support and Python programming.
-
You can really tell when someone hasn't taken the time to learn the fundamentals. Their code (probably) still works, but it looks like a spaghetti nightmare.
-
People say security through obscurity is just a delaying tactic at best, but those people have no idea how many times my blog has thwarted hacking attempts by returning a 404 for /wp-admin.
(Because it's not even a WordPress site)