I'm in the same situation as you (or was, until about a week ago). I'd been looking for a new contract for a couple of months and also had lots of enthusiastic calls with recruiters, only to be ghosted or hear nothing more. A couple of my contractor friends have also had the same experience. Compare to late last year, when I was batting contracts away whilst I was taking a couple of months off. Picked up a new contract when I was ready within a few days in November.
Whilst I'm a full stack dev, I found narrowing my CV, or creating multiple versions (one FE, one BE, one devops) helped sustain more interest/got me through more doors. Being a full stack dev puts you behind anyone that pitches themselves as a BE dev for BE roles, FE dev for FE roles, and so on. It's assumed that since they're 'specialised', they're better suited for the role.
Same goes for tech. Whilst everyone _here_ will appreciate the fact knowing/working/having experience in multiple languages will generally mean your the better programmer, it's not something HR seems to grok.
In short: If there's a Go contract, send a version of your CV that pitches you as a BE Go Dev and that only. Once you're through the door and speaking to the people that matter, you can open up about your other experience.
As for timing, generally now is a good time. Some companies will have budget to use before the end of the tax year. Some companies will have new budgets at the start of the next tax year.
There have been a lot of layoffs, so the market isn't quite as much in the favour of developers at the moment.
---
Anyhow, that said, I've just taken a perm role again, just for another year or so whilst I learn some new tech and hopefully the contract market sorts itself out. It's only about £1k/month less. Worth it for the security, for now.
Love the story. My first exposure to programming was through automating RSC. All I was doing though was writing scripts for SCAR. I think maybe in… pascal?
I remember trying to learn some Java at the time, but could never make the leap between building simple CLI app’s and primitive string manipulation to integrating with the RS client and actually doing something ‘useful’. However, I was only 8, so I’ll cut myself some slack!
1. It's great. I'm not sure I've ever heard the fans spin up. I've had very occasional glitches with sound when switching workspaces.
2. The only thing that's been a blocker for me is trying to run an old Terraform release and the lack of some arm64 docker images (in which case I have to target amd64).
3. See #2. In addition, I did experience some poor performance when mounting volumes from my local filesystem, but that has been _vastly_ improved since they added "VirtioFS accelerated directory sharing". Now it's great.
4. I only have 16GB of RAM. My workloads are typically not that heavy, but I have edited a couple of videos in DaVinci Resolve and didn't have any issues. Sounds like it would make sense for you to go for 32GB though.
I don’t think the demise of classic forums/self-hosted communities is a technical problem. There is no shortage of modern communities - as you say, Discourse is one of the most popular. Otherwise there’s NodeBB, Flarum, etc - and vBulletin, IPB, phpbb, etc are still under active development.
The larger “problem” is the world has moved on. For its flaws, people seem to enjoy the familiarity/community of umbrella sites like Reddit.
I think they’re saying only backing up _data_ is not enough (S3, GCS). You need to be able to roll out infrastructure elsewhere to, in order to have somewhere to restore said data.
They will most likely be rendering the page in full server-side. This is how things were done in the beginning, but also what a lot of websites are returning to, for performance reasons.
> How this s** works:
Modern fonts can combine
letters into a single ligature,
usually for things like fi or fl
but you can pick anything
so we’ve done it for swears.
I wouldn't say totally irrelevant. I've worked on many line-of-business applications and websites where the database is the bottleneck. People love to obsess over "what language?", happily ignoring the fact database access is 90% of the request time.
YNAB. I've used it for a few years (since YNAB 4). The automated import and categorization of transactions, combined with envelope budgeting is all I need. About as frictionless as it can realistically get, for my use case.
I stumbled across this library a few months ago and also really liked the approach. Unfortunately I had to drop it temporarily due to this issue (https://github.com/kyleconroy/sqlc/pull/983)... which I now see is solved. Taking another look. :)
If they're going to make the leap of switching the render layer, I'm surprised the leap isn't to flutter (which is supposedly stable/ready for production web apps?).
...but seeing as that isn't the case.