In my experience software employers don’t really care about degrees. If you can code well that’s all you really need. If you have no previous employers you might need some personal projects to demonstrate that skill though.
(At least that’s how it was before AI. I have no idea now… By all accounts entry level is fucked.)
Yeah… I have 100k rep (almost exactly!) and I don’t use it any more. It doesn’t have the network effects, so even if there is a question that AI can’t answer (which does still happen despite what some people seem to think), I don’t go to Stackoverflow, I go somewhere else. A forum, GitHub repo discussions, even IRC once (OpenOCD still uses that for some weird reason - they were extremely helpful though).
It had a good run. RIP.
Seems like a good policy. Especially if they’re bottlenecked on review, which most large open source projects are.
Who doesn’t want to be able to get their work done easier? Nobody.
Err, people that don’t want to be made redundant? You haven’t been at all paying attention to the history of automation!
I don’t know why you think Python is fine but Typescript isn’t. With modern Python best practice (project.toml and uv) they have basically the same behaviour and caveats. Python is actually a little worse because most Python packages don’t use semver.
It’s not that it’s a bad idea, it’s more that it’s basically impossible at this point.
Bazel can’t use Cargo, CMake and so on for downloading & building packages because it is trying to do cross-language builds the right way - a single build graph that includes everything. No other third party package managers/build tools actually exposed their build graphs - only commands to perform builds, which are too coarse for Bazel.
To put it simply, its necessary if you are doing things at the scale of Bazel.
Python is one of the worst offenders here. I don’t think Python’s poor behaviour should excuse Lua’s.
But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.
Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don’t think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they’re for stuff that is truly ancient or almost completely unused. It’s totally possible if you care about it.
Yes but that tracks issues of all severities and with all of GitHub’s services of which there are a great many. Also “days since incident” is a terrible metric because it doesn’t capture how long the incidents last.
For example the latest incident is that copilot had degraded performance with Fable due to an Anthropic issue. It only last 18 minutes, only affected part of a part of their service, and it wasn’t even their fault!
That’s very different to “all of GitHub is down for 7 hours”.
So yes. I am not sure GitHub is worse.
Ah yeah looks like the latest 19.1 release from June.
But it also seems to suggest it’s only a UI change. Is is possible to do stacked MRs across forks? Does it not still suffer from the flaw GitHub has (or had, hopefully) - you create one MR, myfork:feature_0 -> upstream:master. That’s fine, but then you want to create the second MR targeting the first MR, myfork:feature_1 -> ???:feature_0, only you can’t. feature_0 doesn’t exist in the upstream and there’s no point creating an MR targeting your own fork.
I’m not sure it actually is. At best it is too early to tell.
I haven’t used it yet but assuming they did it right, yes you can merge the PRs sequentially.
Do you mean GitHub? Last I checked Gitlab doesn’t support stacked PRs.
What are you talking about? 500 applications is clearly way too many for them to be serious. You’re basically spamming at that point.
500-600 applications!? Sounds like you are putting low effort into sending a lot of applications rather than high effort into a few.
Ah I see. That definitely depends on what it is and who your target audience is. I would say you can be quite technically proficient in Windows without being very familiar with the command line because a) the Windows command line sucks (even Powershell is kind of awful), and b) there are so many great GUI tools available, you almost never need to resort to the command line.
So yeah, just depends where you want to draw the line and what it is that you’re making.
Depends on the windows user. But I dunno why you wouldn’t offer it for Windows. You kind of have to go out of your way these days to make supporting Windows difficult, e.g. using OCaml or Perl or Bash or something.
I’ve never seen a good answer to this question. Snapshot testing sucks. A 0.3% threshold can totally be too low for benign changes and too high to detect real bugs.
Manual testing is probably the best option if you can afford it, but it’s time consuming and tedious.
I’m sure there are people working on AI for this. I wouldn’t be too surprised if that’s the best option but I haven’t looked into any of that. Also you really want it to be deterministic and I’m not sure how you do that with AI easily.
If you find yourself reaching for this feature it probably means your Bash script has reached the level of complexity where you should absolutely not be using Bash. Use a real programming language instead.
I think the use of the term junior and senior is a bit confusing because it conflates age and skill. I would say most people use it to talk about skill, because we’re talking job titles here.
While age and skill are certainly linked, I have known several junior engineers well over 50 (don’t hire these people!), and also some extremely skilled engineers in their very early 20s. The latter hadn’t yet earned the “senior” job title but that’s just because they didn’t know they deserved it yet.
So yeah I do think junior (skill) programmers are pretty screwed - AI is already at least on par with the junior skill level people I’ve worked with. But I don’t think that means young people are screwed, as long as you are good at your job.
For now anyway. Who knows how good AI will be in 5 years. We might all be out of a job.
Yeah “if it ain’t broke don’t fix it” is code for “if it isn’t completely awful don’t bother improving it”. That’s how you end up with everything being just on the verge of broken.