This is the real answer.
There are still, in the year 2023, Cobal developers graduating and getting hired to work on software.
My alma mater’s website runs on PHP.
The investment to flip even a microservice from one language to another is REALLY high, and most companies won’t pay unless there’s a significant pain point. They might not greenfield new projects with it anymore - but it will still be around effectively forever.
When you do your job as a developer so good you have to allow users to use a whole programming language to get the functionality they need.
Although this might speak to the abuses of excel in the business world more than the failures of excel, tbh. Maybe both?
You’re not wrong. Having to figure out which element is borked in a yaml file is not great. And the implementation using yaml is all over the place, so even though tools do exist, they’re mediocre at best.
But, to be fair, Python has always done the same to me. As a fellow Neuro-spicy (and with a background in Java and C# and JavaScript), although the tools are better to point you in the right direction, significant white space (or indentations) are significant white space (or indentations).🤷♂️
.xml
Not sure whether fantastic troll or just no exposure to Python.
Either way…I’m here for it.
The most compelling argument I heard is that WASM can’t manipulate the DOM and a lot of people don’t want to deal with gluing JS code to it, but aside from that
But other than that, Mrs. Lincoln, how was the play?
You’ve gotten several other answers that are true and correct - the pain of implementation at this point is greater than the pain points that WASM solves. But this is also a non trivial one - most of what Javascript should be doing on a webpage is DOM manipulation.
At some point, WASM will either come out with a killer feature/killer app/use case that Javascript (and all the libraries/frameworks out there) hasn’t figured out how to handle, and it will establish a niche (besides “Javascript is sort of a dumb language let’s get rid of it”), and depending on the use case, you might see some of the 17.4 million (estimated) Javascript developers chuck it for…what? Rust? Kotlin? C? C#? But the switching costs are non-trivial - and frankly, especially if you still have to write Javascript in order to manipulate the DOM…well, what are we solving for?
If you’re writing a web app where one of the WASM languages gives you a real competitive advantage, I’d say that’s your use case right there. But since most web applications are basically strings of api calls looped together to dump data from the backend into a browser, it’s hard to picture wider adoption. I’ve been wrong before, though.
For a second I thought my github was going viral. ;)
This is a hilarious (and interesting!) read.
As a young(er) and slightly shittier web developer, before I really understood or could implement promises effectively (or when my code would ‘race’ and fail to recognize that the DOM hadn’t been loaded yet, so I couldn’t attach event listeners yet), I was known to implement a 2 second timeout.
It wasn’t pretty, but it worked!
I’m a web dev turned DevOps (with the front end design eye and CSS knowledge of a DevOps! Lol) but this seems like a great place to use a css grid, no?
Junior-ish DevOps with some blue/green experience.
It’s a very thorny problem, and I think your willingness to put up with the trade offs really would drive what patttern of architectecture.
Most of our blue/green deployment types use a unitary database behind the backend infra. There’s a lot ways to implement changes to the database (mostly done through scripting in the pipeline, we don’t typically use hibernate or other functionality that wants to control the schema more directly), and it avoids the pain of trying to manage consistency with multiple db instances. It helps that most of our databases are document types, so a lot of db changes can be implemented via flag. But I’ve seen some SQL implementations for table changes that lend themselves to blue/green - you just have to be very mindful to not Bork the current live app with what you’re doing in the background. It requires some planning - not just “shove the script into source control and fire the pipeline.”
If we were using SQL with a tightly integrated schema and/or we couldn’t feature flag, I think we’d have to monkey around with blue/greening the database as well. But consistency is non trivial, especially depending on what kind of app it is. And at least one time when a colleague set up a database stream between AWS accounts, he managed a circular dependency, which….well it wasn’t prod so it wasn’t a big deal, but it easily could’ve been. The data transfer fees are really what kills you. We managed to triple our Dev AWS bill prototyping some database streams at one point. Some of it undoubtedly was inefficient code, but point stands. With most blue/green infra, your actual costs are a lot less than 2x what a ‘unitary’ infra would cost, because most infra is pay for use and isn’t necessary except when you go to deploy new code anyway. But database consistency, at least when we tried it, was way MORE expensive than just 2x the cost of a unitary db, because of the compute and transfer fees.
You know what I don’t like about them? They’re kind of a symbol of American arrogance and bullying.
It’s only useful where there is zero AAA and zero threat from enemy fighters. It’s a cargo plane - it packs a wallop, of course, but you use it when “the other guy” is a bunch of dudes running around on the ground with no chance to fight back.
The fact that we have them in inventory says a LOT about the types of wars we’ve been fighting for the past 40 years.
(Super unpopular opinion - the A-10 is not much better, but at least it has some genuine anti-armor capabilities.)
I think you have an interesting background and potentially interesting technical skills, and I could totally see you catching on with someone and having a fantastic career. I could also see why it would be a weird or awkward fit, that you might be totally overwhelmed, and possibly even hate it. Let me qualify my answer(s) and see if that helps at all.
I feel like at its heart, being a DevOps is just being passionate about tinkering and technology. The best DevOps Engineers I know love nothing more than to nerd out about…well, all kinds of stuff. From K8s to Linux distros to build tools to code. DevOps is a practice, not a skill set - and that’s reflected in the fact that there’s no ‘base’ skill set for DevOps Engineers. I’ve known developers, sysadmins, even help desk type folks that found their way into the field and were successful. It just depends.
It kind of feels like you have the heart of a tinkerer, and the fact that you have a MS in a hard science suggests that you have the brainpower to hack it - maybe literally. :)
That said - what would worry me if I were considering hiring you is that you don’t really have any exposure to Software Development Lifecycle concepts. Maybe I’m too stupid to understand all the acronyms above, but in my (limited) experience, having a good handle on SDLC is sort of the beating heart of DevOps - at least in part because being able to have the infrastructure ready to mate up with the code at the right time and right place is like, 80% of my gig. Too early is a security vulnerability (potentially), too late and the dev team misses all their sprint targets. You don’t have to write code, exactly (although I wish I wrote more), but you have to be able to ‘follow along’ with the dev team. Especially when you’re troubleshooting.
For SRE particularly - you have a lot of nice sysadmin-y type background skills, but particularly understanding design patterns and telemetry would be the thing I’d be most nervous about for you. Scalability as well - although that’s hard for almost everybody. But for an SRE to improve reliability, you have to be able to really hone in on what’s breaking - and once you’ve gotten the big pieces sorted, being able to understand resource usage, and all of that points towards good instrumentation (and good instrumentation practices).
I joke that reading logs is my superpower - both because my devs, bless them, don’t do it, and also because if we’ve done a good job building the application, build/deploy pipelines, and infrastructure, your alerts and instrumentation will tell you exactly where any pain points are happening, and make it a lot easier to figure out where and how to focus your efforts moving forward.
So, after that wall of text - I’d point you towards the cloud. AWS is the largest/most widely known, but arguably kind of opinionated in terms of implementation. Still, AWS Solutions Architect is a pretty good ‘gold standard’ type certification. If you’re more familiar with GCP or Azure, do the ‘associate’ level certs there.
Another obvious thing that I didn’t see in your background - VCS. Git gud, as it were. I’m a big fan of hanging pretty much all your personal projects on GitHub. Mine is atrocious since I got hired, but before that I had a full year straight of commits. Sometimes it was impressive stuff, most of the time it was just messing around with code - but all the companies that gave me an offer letter mentioned it. Ymmv.
Finally - you might expand your search a little wider (SysOps instead of SRE off the bat? DevOps as well? Maybe going straight stick software dev, with your background, at a company where your science background would be a real value add is something to look at) and also be prepared to ‘take a step back’ if you do jump. I’d definitely hire you to see how things go, but I’d want you to come in as a Junior, and based on what you wrote above, that’s probably a bit of a paycut for you.
TL;DR - Do cloud certs, practice on GitHub so employers can see what you’re working on, consider SysOps/DevOps as well as SRE.
Best of luck to you!
You got downvoted for being sympathetic - and it also happens to be the right reason.
I prefer to use a Bluetooth earbud. But a lot of times even with the phone turned up and smooshed against my face - I just can’t hear. Especially in loud places.
I can, almost always hear my speaker - and I can have my hands free and interact with my phone too.
I don’t do this in public, mind. But I could see it being a hard habit to break.