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.

So glad I Xited right after Musk’s purchase was finalized. My days are freer and my conscience is clear!

I watched it in Vim, mostly because I don’t hate myself enough.

Not to spoil the ending either, but the nuclear device goes off because Oppenheimer smashes a bunch of keys and then finally remembers :wq.

Tech doesn’t really self select for well balanced, socially confident, neurologically normal folks.

I’m sure those people are in tech and have success as well, but the stereotype of the “hacker nerd” didn’t spring out of nothing. The obsessiveness and desire to be right and know everything that make IT geniuses can also make those same folks really, really hard to be around.

People that are ostracized for their socially aberrant behavior usually (not always!) have sympathy for other outcast groups, whatever the reason.

And you’re right, too - writing code is sort of one of those ultimate bullshit tests - either it works, or it doesn’t. Computers don’t care about your pedigree or your appearance or even your personality. Nice guys who write shit code might have management or product team in their future, but they don’t usually write code for very long. But good devs are hard to find, so even the most straight laced companies are willing to bend a bit when it comes to talented developers.

My $.02, and worth every penny 😂

Maybe this is because I’m still relatively junior (2ish years), but my favorite question to ask is, “What are some of the characteristics you’re looking for in someone in this role?”

I use it as a vibe check, especially at the end of interviews. If they start reading my resume back to me, or listing the things we’ve talked about during the interview…well, that’s a good sign. If they start describing a bunch of stuff that we didn’t talk about, it’s a chance to throw a ‘Hail Mary’ pass and show them how that’s me, as well - maybe we didn’t talk about something that was important to them, but I have relevant experience or a background.

If they start describing somebody else…well, that’s not great.

This was my first thought.

I do this for a living and it’s literally built into Linux.

Set their permissions carefully, ensure that the permission set does what you want (and not a bunch of stuff you don’t want), and keep on keeping on.

I have some experience using git and svn, but really never work in collaboration with others, in my current work we used but only git without external service. Just to keep track of the personal work.

No this is great in and of itself - what I would tell you is to treat your github projects, even if you’re the sole contributor, like you’re working on a team. Checkout a feature branch, complete your code, then PR it into main/master/release/whatever, even if you’re the one doing the code review for yourself. Even if you don’t get to experience other devs (inevitably borking what you’re working on) in the codebase at the same time, it’ll give you a better idea of what the workflow should look like.

I have a “software engineer” job in a research institution, is only the title because I’m a research assistant most of the time with some dev time. The problem is there is no grow and the founding is through a international project, so the time is fixed.

My pay is not so high, is a EU salary in a semi-public institution, tho the pay is lower that the equivalent in the industry, but I’m above the average of at county level, I’ll consider a paycut at least I could still pay the rent and past time with my family.

This all makes the SRE part more understandable and more within reach. I wouldn’t lead with, “I don’t have any dev experience”; I would lead with “I’ve been a software engineer for x years, specializing in atmospheric modeling.” Whoever is interviewing you will probably dig and figure out that you were a solo developer, but…you were still a software dev, and the first job in this industry is way harder than the next couple. Lean into that - you have the job title, you have the resume, you’re looking to take ‘the next step’ into SRE/DevOps, because as a solo-dev, you had to handle all that stuff yourself, and you figured out that you liked it and were good at it.

We’ve all been the new guy trying to break into the field - pay it forward after you land that first SRE gig.

This kind of implies that you’re crunching and then ‘recovering’. That may or may not be something you have any control over - there’s a lot that goes into creating an unsustainable ‘sprint’, and probably 99.8% of it is not related to actual developers or code - but ideally you would be using these ‘lulls’ to try to pull stuff out of the next crunch so maybe it won’t hurt so bad.

In reality, if I’m coming off of a bad crunch, I do anything I can do to avoid burnout. Sometimes that’s ‘fun’ backlog items or research for future features or something else I’m excited about, sometimes it’s studying for certs, sometimes it’s cutting slack (@cianuro@programming.dev watching Netflix feels familiar!). But again - whatever it takes to recharge my batteries and feel less bitter and shitty.

The most ‘sure’ sign that I’m coming off a crunch, though, is that I start reinforcing work/life boundaries. “It’s 5p and I’m logging off and I’m not going to think about work shit willingly until tomorrow.”

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!