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.

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.

The last couple of years his catch-and-shoot and off-the-dribble numbers are basically identical. Actually since about 2017 he’s been a better catch-and-shoot than off-the-dribble shooter - but again, it’s close.

I agree with you that he’s quit on three teams in a row and still wants a big role in an offense wherever he goes - but I think my point is valid, too. If he could resign himself to being the third best guy on a team, he’s still got enough in the tank to be value added.

He’s not washed - he’s just an asshole. 😂

Real talk, though - you’re getting at least a 50% chance he shows up out of shape, a 100% chance that he’ll quit on you at some point, and even if those two things don’t pop, he’s never exactly been a lock down defender. But he can still create shots and hit 3s at a decent clip. He’s basically the better version of Seth Curry, if Seth insisted on having the entire offense run through him.

I think sometimes the difference between strongly typed and loosely typed is easier to explain in terms of workflow. It’s possible (note: not necessarily a good idea, but possible) to start writing a function in vanilla JavaScript without any real idea of what it’s going to output. Is it going to return a string? Is it going to return null, because it’s performing some action to a variable? Or is it going to return that variable? And vanilla JS is good with that.

But that same looseness that can be kind of useful when you’re brainstorming or problem solving can result in unexpected behavior. For instance, I write a function that prepares a string for additional processing. For the purposes of this conversation, let’s say that it removes white spaces and any non-letter or number characters, and then returns the transformed string.

What happens if I feed a number (integer) to this function instead of a string? What about a number with a decimal (float)? Does my function (and/or JavaScript) treat them as literal strings? Does it remove the decimal from the float, since it’s a non-letter, non-number value?

Without Typescript, you have to either a) write your code in such a way that you ensure that the situation never comes up (i.e. by validating inputs, or by being very careful about when and how this function is used), or b) you have to handle those weird cases, which turns a cute little three line function into a 30 line monster with a switch case and typecasting. And truthfully, on any project ‘at scale’ you’re going to have to do both.

With Typescript, you specify that this function takes in a string, and returns a string, and that’s it. Then, when another dev (or you, in six weeks when you’ve forgotten all about this function that you wrote) tries to send in a boolean, or a float, or an array of strings, Typescript is going to blow up. Nope. Can’t do that. And they (it’s more fun to think of it as future you) will have to follow the rules that you put in place by writing the function the way you did, which just means being careful enough to cast a float or integer into a string before passing it, or concatenating an array, or whatever.

Strongly typed languages expect you to write functions with the end state you’re expecting in mind. You’ve already got the solution in your head before you start typing, at least enough to know what type of data goes in and what type of data goes out.

It also hides (but doesn’t totally get rid of!) some of the sillier things that JavaScript does because it’s not strongly typed. True + True should probably never equal 2.

As to OP’s question, though - if you know how to do things in JavaScript (.trim(), for example), then you know how to do a thing in Typescript. Manipulating data in JavasScript and manipulating data in TypeScript is identical - but TypeScript is also watching what the types of the different data types being used, and throwing up the BS flag when you get too loose with what you’re doing (or don’t think through the consequences of your design decisions).

Man it’s a good thing that Darryl Morey didn’t like, take a huge gamble on him, based on their history together.

Oh.

James Harden was a transcendent offensive talent, even though he’s never been much fun to watch. But I can’t remember a player who has had a sadder (or quicker?) descent from MVP-caliber to actively cancerous ring-chaser.

He’ll still probably get a ring, somewhere. IF (and it’s a big if, actually) he can stay healthy, stay in shape, and be comfortable actually being the third or fourth best guy on a title team.

Is it just an extreme difficulty spike at this point that I have to trial-and-error through, or am I doing anything wrong?

I would say this is the biggest ‘aha’ moment for pretty much any developer - the first time you go from “I built this myself” to “A team built this and has supported it for 10+ years”. Not only can a team of three or four write a lot of code in ten years - they’ll optimize the Hell out of it. It’s ten years worth of edge case bugs, attempts to go faster, new features, etc. And it’s ‘bumpy’ because some of it was done by Dev A in their own style, some of it by Dev B, and so on. So you’ll find the most beautiful implementation for problems that you haven’t even considered before next to “Hello World” level implementation on something else.

The biggest thing you can do to help yourself out is make sure you’re clear on their branching strategy. When you’re the only one working on your code, it’s cool to push to main and occasionally break things and no harm no foul. But for a mature code base, a butterfly flapping its wings on that obscure constructor can have a blast radius of ‘okay, we have to rebase to the last stable commit’. When in doubt, ‘feature/(what you’re working on)’; but there might be more requirements than that, and it’s okay to ask. Some teams have feature requests tracked by number, on a kanban board, some put it in their username, etc.

Get the code pulled down, get it running on your machine (no small task), git checkout -b from wherever you’re pulling a branch off of (hopefully main or master, but again, it’s okay to ask) and then, figure out what the team’s requirements are for PRs. Do they have any testing environments, besides building it locally? Do they use linting or some other process to enforce style on PR reviews?

And then…don’t move a button. (Unless that button actually needs moved!) But try to mimic something that already exists. Create a second button in the new location. Steal from the codebase - implement something small in a way that has been done before. After the new button works - then remove the old button and see what happens.

The longer you deal with a codebase (and the attendant issues and feedback) the more you’ll feel yourself drawn to certain parts of the code that you’re familiar with.

Anyway, hope that advice helps! But most of all, don’t be scared. You will break things unintentionally. Your code will break things. If there’s not a process in place to catch it before it happens, that’s not your fault; that’s the senior dev/owners fault. But do try to limit the damage by using good branching strategies, only PRing after linting/testing, and otherwise following the rules.

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!

Wish I could upvote more than once. Azure artifacts has some fucky authentication requirements (cleartextpassword is the dumbest field I’ve ever heard of - especially since it’s not clear text or a password, it’s a base64ed PAT) but there’s plenty of first party support to make it less painful, and it’s a problem you only have to ‘fix’ once.

Our prior solution was verdaccio for NPM and a shared drive location for Nuget, and….well, it beats the tar out of either of those. Being able to see exactly what’s in the feed, when it got there, who put it there….all grade a stuff. Handling SSO and such seamlessly is nice too, and being able to scope access with tons of granularity….well it seems like a rake waiting to be stepped on, honestly, but if you need to manage access it seems like a big win.

Public feeds - yes. Why reinvent the wheel? Will be easier to find and use if it’s on nuget.org.

If OP’s goal is to be able to source control all the public packages that their projects use, for security or peace of mind purposes (or to make it the sole source of packages to avoid dependency injection/confusion attacks)…there’s actually a feature of Azure Artifacts where you can pull packages from an ‘upstream’ like nuget.org and host public packages in a private feed. It’s got a gui, and it’s pretty convenient as far as such things go.

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.

Oh yeah, well I’ll make my own community! With blackjack! And hookers! You know what, forget the community and the blackjack! Aw, forget the whole thing.

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 😂

My first wifi network post-college was “viruses_and_goat_porn”.

It still didn’t stop free loaders….but in their defense, there were no viruses. 👀🐐

Make it a CON save and watch the whole world freak out.❤️

Or every front-liners favorite dump stat - INT!

Playing dumb is fun until you realize…you’re not playing.

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.)

The Spurs in many ways created modern load-management ideas - and they also had a big three (Duncan, Ginobili, Parker) that managed to all stay productive until they were almost 40. Shutting Victor down after two summer league games, where the games literally do not count, is very on par for them.

As for the Britney Spears thing - I mean, it’s a good example of why getting Victor some time off is a good idea. All of the Spurs/Vic statements, put together, are maybe two lines of text. Britney, who admittedly has had a rough life and a weird relationship with her fame, is the one that keeps releasing statements and videos and trying to drag out this interaction. It was clearly a low-stakes misunderstanding, there’s been no charges or lawsuit, and EVEN IF TMZ had gotten word of it not from one of the like, six people that were there, it could’ve been squashed very easily by releasing a statement that there was miscommunication, everyone apologized, life goes on. We’re still talking about it three weeks later because Britney keeps posting about it and talking about it to stay in the public view.

Welcome to the NBA Wembanyama. I bet he’s so weirded out by the whole thing he just wants to go hide in a gym and work on his step back three. Which from the Spurs perspective, is perfect.

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!

There’s probably a bit of a disparity, but it’s not nearly as much as you’re making it out to be.

In the US it depends greatly on the industry and company - I don’t know anybody making 200k-400k in software development (CTO? sure. Devs writing code? Nah), but I also don’t know or work with anybody that’s in FAANG world. Those are the companies paying $100k+ for a junior.

I live and work in a lower cost of living area, for a company that’s not ‘software first’ and our juniors come in between $50k-75K. And that’s not the lowest I’ve seen for junior engineers starting out.

That said - it’s also not unusual for mid-career folks to be in the $100-150k range, and seniors/leads moving up from there.

So with all that in mind - some of it is market forces (are there more devs and/or fewer dev jobs in Europe than in the US? Potentially less mobility?) but one of the bigger causes (I’d guess, anyway) is the lack of FANG type “Master of the Universe” companies. Part of the reason juniors and seniors command that kind of pay in the US is because the rates that the FANGs pay tend to ‘trickle down’. The average senior/mid career dev may not be interested (or capable!) of working at a FANG - but if the other people in their hiring pool are, they’re still going to command that kind of salary.

As a point of comparison - my understanding is that financial services is sort of the same thing. Most Euro bankers/stockbrokers/finance bro types are pretty heavily underpaid compared to their US counterparts. Some of that is regulatory, but a lot of it is that there are more higher paying jobs in the US, mostly at the big multinantional conglomerates you can think of off the top of your head (Goldman Sachs, Bank of America, Citibank, JP Morgan), and that tends to drag the scale up throughout the whole system. A rising tide raises all boats.

Anyway - I don’t have any research or statistics to back any of these suggestions up - hopefully Cunningham’s Law gets us a ‘real’ answer. :)