Would you mind sharing some info on how you found a tech job in Norway?
I'm from another European country and looking for some first-hand knowledge on working in / moving to Norway.
Yeah, absolutely. I came from the US, so it was a bit harder than a Schengen move. Not sure if you qualify for that or need a skills visa like I did.
But essentially I applied, a lot on LinkedIn. This started early 2021. Took about 8 months to secure a role, I was at 5 YoE at the time, embedded systems / embedded Linux engineering, and I would say moderately good at my job, nothing spectacular. No FAANG.
Oslo was quite difficult, I wasn't able to secure a job there. They are also very keen on grades and transcripts, even though it had been a decade since I was in University. I had mediocre grades, which may have hurt.
But I applied all over Norway, and got a robotics job in a small town on the west coast. They sponsored my skills visa, got me here, and after a year I transferred to our Oslo branch. Once you're in the country it's massively easier to move around. Interview was standard and sane, most here have been. Recruiter/manager soft fit check, a few technical rounds, then team and upper management interviews. Be humble but confident in interviews, don't brag excessively, it's very much the opposite of the US in working culture (read about "Janteloven"). Pay was substantially lower but I am so happy with the quality of life here I couldn't care less.
I knew no Norwegian when moving. Nearly all tech jobs are English hybrid enough you can get by. But I would highly, highly recommend learning the language. Socially (private life) and professionally it helps so much. And it's a bit rare to really learn it, so people are often impressed or happy you do speak it. It's difficult though for a few reasons, dialect variety, English fluency among Norwegians, etc. I would say it took me all of 4 years to get to the point I could converse mostly fine at speed with someone speaking in a native dialect. Reading is much easier, that came after a year or two.
This was kind of an info dump, let me know if you have any specific questions!
Tl;dr: use LinkedIn, apply, apply, apply, don't get disheartened / give up, and give it time.
Given that the models will attempt to check their own work with almost the identical verification that a human engineer would, it's hard to say if human's aren't implicitly checking by relying on the shared verification methods (e.g. let me run the tests, let me try to run the application with specific arguments to test if the behavior works).
> Given that the models will attempt to check their own work with almost the identical verification that a human engineer would
That's not the case at all though. The LLM doesn't have a mental model of what the expected final result is, so how could it possibly verify that?
It has a description in text format of what the engineer thinks he wants. The text format is inherently limited and lossy and the engineer is unlikely to be perfect at expressing his expectations in any case.
Not yet, but the more you will insist, the more it will be. But what is your proposal for differentiating between just prompting without looking at code vs just using LLM to generate code?
The reflog doesn't capture everything. jj's oplog does.
An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
The thing to keep in mind is that Git doesn't version the file system, it versions the index. This is because a file system guy like Torvalds knows that the file system is a shared resource and no program should think it can control its state. Therefore a Git repository doesn't consists out of all the files below a directory, it consists out of everything in the index.
Git does version everything that is in the repository and all these states occur in the reflog.
> The thing to keep in mind is that Git doesn't version the file system, it versions the index.
Yes. I think that this difference is what introduces a lot of friction, both in the model, and how people use it. The divergence between the files that exist on disk inside your working copy and what's actually tracked means lots of opportunities for friction that go away once you decide that it should. That doesn't mean things are perfect, for example, by default jj only snapshots the filesystem when you run a `jj` command, so you can still lose changes from in between those, you need to enable Watchman to get truly full logging here.
> all these states occur in the reflog.
Well, let's go back to the documentation for reflog:
> Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.
It only tracks changes to refs. That is, the states that refs have been in. So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.
Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit <sha> with these args: jj rebase -r <sha> -d trunk"
The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.
This doesn't mean the reflog is bad! It's just a very specific thing. Git could have an operation log too, it's just a different feature.
> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.
$ git checkout HEAD
$ git commit --allow-empty -m "_"
$ git checkout master
$ git reflog
a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master
b94 HEAD@{1}: commit: _
28d (origin/feature, feature) HEAD@{2}: checkout: moving from feature to @
> Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit <sha> with these args: jj rebase -r <sha> -d trunk"
> The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.
68e HEAD@{15}: rebase (finish): returning to refs/heads/feature
68e HEAD@{16}: rebase (pick): message #6
7ff HEAD@{17}: rebase (pick): message #5
797 HEAD@{18}: rebase (pick): message #4
776 HEAD@{19}: rebase (pick): message #3
c7d HEAD@{20}: rebase (pick): message #2
f10 HEAD@{21}: rebase (pick): message #1
c0d HEAD@{22}: rebase (start): checkout @~6
a7c HEAD@{100}: rebase (reword): message ...
3b1 HEAD@{229}: rebase (reset): '3b1' message ...
4a4 HEAD@{270}: rebase (continue): message ...
One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches separately AFAIK.
--update-refs, --no-update-refs
Automatically force-update any branches that point to commits that
are being rebased. Any branches that are checked out in a worktree
are not updated in this way.
If the configuration variable rebase.updateRefs is set, then this
option can be used to override and disable this setting.
Are you saying that that text implies that the you can undo the rebase with a single command or that all the reflogs get updated atomically? Or how is it related to the comment you replied to?
Oops. No the text implies that I can't read and answered to a claim which you didn't state, namely that --update-refs can only update specific refs. (This was given by another comment.)
Yes, this is something, that JJ provides and Git does not.
Which, the stuff you said earlier is in the reflog?
I think Git will just gain a oplog. You just need to append a commit hash to a list before each command and implement undo as remove item and checkout. The hardest thing will be race conditions, but Git already knows how to be a database.
I use a Samsung Fold because I read a lot of books/manga, and I also love its multitasking features over stock Android/Pixel. Finally I also prefer it's form-factor (roughly 3:4 unfolded screen, and a narrow front screen) over other similar devices.
But it's obviously not for everyone so I can't really recommend it to everyone. And to be honest I can't in good faith recommend any Android phone these days, I hate what Google and other OEMs have done to the ecosystem.
I'm quite bullish on Linux phones though, like the FuriPhone FLX1, the Volla Phone Quintus, and the Jolla C2 - obviously again they're not for everyone, so for normies I would recommend an iPhone, and for techies I'd suggest giving the Linux phones a try (or maybe get a OnePlus/Nothing phone and load LineageOS+Magisk if you don't mind playing the cat-and-mouse game with Play Integrity).
I have no special insights, but Sony's phones seem like a good fit. They are really easy to unlock [1], but there are virtually no mods but Lineage. Maybe because they are very stock Android and bloat-free?
They range from 300 to 1000 EUR. I personally am fond of the "lower end" and slender Xperia 5 and 10 lines and the customary 21:9 screen ratio.
Don’t Sony’s have the issue of crappier photos after unlocking because of some DRM key shenanigans? This is what I remember about my old Xperia X1C and I so left for Pixel and then eventually iOS so things would just work and last longer than a year or 2.
reply