skysight-inc/HackerNews huggingface dataset:
I don't know. As a Singapore resident with way too many bank accounts, it seems like the most unstable experiences for me tend to be the banks that try to reinvent features, like the aforementioned DBS.

I'd speculate that shipping new features, not stability, is somewhat linked to career progression.

It could also be because most Singapore banking apps end up using the same mobile security framework to pass their audits [1] — except that same security framework prefers security over user experience.

[1] https://en.wikipedia.org/wiki/V-Key
I can't find the exact link, but 80000 hours has written about lab safety as a possible high-impact career area.

https://80000hours.org/podcast/episodes/toby-ord-the-precipi...
https://80000hours.org/preventing-catastrophic-pandemics/
No, Backend is not easier than Frontend. Both are equally hard, since you will always be pushed to get the most out of what is currently available in terms of technology & tooling, no matter of your niche. If not, your job will become worth less since you are going to be automated away at some point.

A fallacy that I found many frontend-developers have is that they believe Backend is the same as Frontend, just that you don't have to deal with browsers, can work in one language and just do some data conversion.

Even if this is true in some cases, they forget the most important thing: the data. On the frontend, you can pretty much always just create a new version of your software, deploy it and then you are done. The only thing you need to be careful about is that you use the backend APIs correctly.
If you mess up, you roll back to the version before and you are good.

Not so on the Backend. If there are changes in how the data is stored, structured/formatted and processed, then there is also the chance that you might screw up data. Potentially you cannot revert this and the damage is permanent. Sometimes you can but it is very painful and needs to be done with extreme care. This is one of the reasons why Backend seems to be more stable - because the impact of errors is higher and will put more stress on you.

Therefore, I find backend less rewarding - it takes longer for you to see results, because you must be more careful.

Disclaimer: of course it can also be that it's the other way around, but usually it is like I described.
Pretty much the opposite is true, the dichotomy is just wrong-
I think backend is easier because you can write “passable” code and develop a passable architecture and nobody would be any the wiser whereas the Frontend is right in your users faces and it’s a high bar you’re competing with!
What about the legend that the cloud thing is maintained by professionals?
> Well, because it’s gosh-darn hard to do it the right way.

I think this overstates the difficulty. This of course depends a lot on the language, but for a reasonable one (not C++) you can just go and write the parser by hand. I’d ballpark this as three weeks, if you know how the thing is supposed to work.

> it doesn’t have to redo the whole thing on every keypress.

This is probably what makes the task seem harder than it is. Incremental parsing is nice, but not mandatory. rust-analyzer and most IntelliJ parsers re-parse the whole file on every change (IJ does incremental lexing, which is simple).

> The reason (most) LSP servers don’t offer syntax highlighting is because of the drag on performance.

I am surprised to hear that. We never had performance problems with highlighting on the server in rust-analyzer. I remember that for Emacs specifically there were client side problems with parsing LSP JSON.

> Every keystroke you type must be sent to the server, processed, a partial tree returned, and your syntax highlighting updated.

That’s not the bottleneck for syntax highlighting, typechecking is (and it’s typechecking that makes highlighting especially interesting).

In general, my perception of what’s going on with proper parsing in the industry is a bit different. I’d say status quo from five years back boils down to people just getting accustomed to the way things were done. Compiler authors generally didn’t think about syntax highlighting or completions, and editors generally didn’t want to do the parsing stuff. JetBrains were the exception, as they just did the thing. In this sense, LSP was a much-needed stimulus to just start doing things properly. People were building rich IDE experiences before LSP just fine (see dart analyzer), it’s just that relatively few languages saw it as an important problem to solve at all.
“Delayed”: Resilient Background Jobs on Rails
I wonder if perhaps this is also a generational thing. Programmers from before syntax highlighting became popular would be less likely to prefer it, no? I’m not even sure if programmers from current/recent generations ever prefer not to have syntax highlighting, but I’m genuinely curious if there are such people out there.
Technology Connections talk about Microwave tech stagnating, or even going backwards -

The Antique Microwave Oven that's Better than Yours https://www.youtube.com/watch?v=UiS27feX8o0

It mentions lookup tables for the steam sensor, which fits for pre internet technology.
I find front end much easier because of hot reloading and recent stuff like vite which instantly reflects whatever you're doing. This definitely helps to increase the speed of development.

Also there have been some recent developments like "Liveview" (1) which make it look like in future the distinction between back and front will be rather blurred.

(1) https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
Nono, I'm sorry. Looking back I responded rudely.

I misread "taking a break on social gatherings and travel for a few years" as that you were going to stop seeing people and then go to travelling for a few years. My head inserted a comma.

From that I envisioned a cliche I've seen a lot where that fear comment always sits alongside someone who always talks in one-way or another about breaking the social contract of a community and mad-maxxing it across the country to find a "better place with similar people", thus the lone-wolf.

Apologies from a dylexic brain, and maybe one that should reflect on its prejudices.
A slightly more involved version of this puzzle asks about covering all but one square of the chess board with 21 trominoes (each of size 3x1 or 1x3), since 64 = 21*3 + 1.

What square remains uncovered (unique up to symmetry) ?
One significant difference is that frontend today focus a lot on how to do things in framework X whereas in backend you focus more on what is a reasonable technical solution for a specific problem and that is most of the time language agnostic.
Microsoft bet on GUI when nobody thought it was gonna be the future
Banditry: Senator Na’Allah expresses concern, proffers solution
The is only true at a small scale. The frontend is often like the tip of the iceberg - it hides an enormous amount of complexity.

I've worked on a lot of systems in my career and I have found there to be a lot more complex and interesting problems in the "backend" than in "frontend".

With backend development, there are very real consequences for making mistakes, and you have a high chance of being punished for making them. When I have front-enders moving down the stack I have to invest significant effort into this. Particularly around secure development, proper automated testing etc, they are fairly uncommon in the frontend but absolutely vital in the backend.

I do get more enjoyment - more feeling of having "made" something when I've worked on the frontend. There's just something about being able to interact tangibly with your work which gives me a big sense of accomplishment. That, and if you're working on a game/native code then the optimisation work is more immediately rewarding.
Sorry for answering this late and thanks a lot for the recommendation. I'll definitely take a look at d3js.org since our current solution works on top of a geoserver which has performance issues when we try to load rather large polygons and working with it is a frustrating process overall. The learning curve for the current solutions we have was steep as well so I'm not too scared (yet haha). Thank you!
As a backend engineer, I would say yes, backend is easier. But also you'll be concerned with completely different things.

Interviewing is pretty hit or miss. You regularly get to meet teams who think you have to already deeply know their exact tech to do the job, which they somehow couldn't communicate to the recruiter or anyone else prior to your full-day onside
> I also agree that other banks can be a lot worse, and HSBC in particularly has been abysmal.

At least HSBC got something right with their app UX: they give me an option to log in using my PIN instead of automatically trying Face ID multiple times, in this era when masks are still mandatory.
A big issue I'm having learning back-end coming from front-end was to gauge if my implementations were correct at all. With front-end you usually get immediate feedback: CSS mistakes and infinite rendering loops are easy to spot. With back-end, poorly optimized code can run great in development and even beyond because stacks these days are very forgiving, up to a certain point where you have no idea why things are slowing down/crashes. In a sense: I find back-end to be more abstract, you have to visualize possible issues more and develop skills to stress-test and identify bottlenecks.

A thing that helped me so far was to demystify databases a bit – looking at you, Designing Data-Intensive Applications – but I'm still seriously struggling to be confident in deploying in production.
It doesn't end there. Even caring a bit for that makes a huge difference, I agree, and I appreciate the effort. The last time we had an accessibility audit, however, it was consisting of more than 200 problems with different priorities for an app with 70 something views. Our FE people were immediately up to the task of getting them fixed; a motivation I simply cannot expect from anyone who doesn't have a front-end focus. My basic checker reports in this simple comment-editor already a couple of problems.

It also doesn't end there. There's the UX part, re-usability (huge difference to have a cross-team front-end service-team), performance (not just initial load... Are the widgets you build with, say, Alpine.js tested for performance?), development speed, caching, offline-capabilities, opportunistic rendering, other best practices, branding, consistent design and interaction and so on. It's a science on its own.

Front-end is not just some basic thing which got a complex solution for no reason. It is a complicated task.
I moved the other way. Frontend is perhaps overly complicated, but it is what users see, you get to demo things that people will actually interact with. Backend work is more invisible and felt less rewarding to me.
I always thought the best cat and mouse example was the Xbox 360 drive firmware angle tests.

The drive would report via some “secure” firmware if the disc passed detection or not. So the hackers made a firmware that reported good on a failure, ways to flash the drives over SATA, etc.

But either Microsoft was very clever or the hackers made a mistake… the drive would report the angle of the disc during certain movements. It would do some operation and report it went from 20degrees to 223 degrees. Well, the hackers and MS disagreed on an angle integer rollover.

The original drive would report 0-359degrees, but the hacked drive rolled over different and reported 0-360degrees or vice versa, I don’t remember. So iirc, MS listened for awhile, if a drive ever reported 360 degrees or whatever the wrong indication was, MS added it to a list.

One day, the drop the hammer banned the lot of them. It took the hackers awhile to figure out how they were getting caught. In the meantime, I now had an Offline-Only 360.
Backend code talks via APIs. Things need to be well-defined so that machines can communicate.

Frontend code has that but has to talk UI, too. That's a much looser-defined interface relying on human nature and perception to work. Meaningful performance is based on that perception and never in the areas that were well-designed. Frontend security is something you can't just hide behind your DMZ. And the design much more susceptible to changing fashions and the whims of PMs and execs. And those people and more think they know how to do your job because it's something they can see.

Yes, backend is easier.
Post-covid (and with remote still the norm in many companies) the global market for high-talent employees has really leveled the playing field regarding compensation and packages. Where there might have been a 25-50% difference in a FAANG package between the bay area or NYC and London a few years ago it seems to be closer to 5-10% now if you know how to play the game. Junior people might be getting a bigger haircut on the difference, but for senior engineers and senior management in engineering/devops/sre it is a good time to be in the market over on this side of the pond.
There is a world of difference between

> Breaking into a device which you yourself own

> Breaking into a device which somebody else owns
I would be very interested if there was a decentralized version of Cloudflare Workers. Doing for compute what IPFS does for files with CF workers web like API (KV Store and Durable Objects).
> For humans, ignoring quoted parens is maybe easier, but i would say it's a flex to assert that you can tell if (3,(g(f('('),x))) is balanced at a glance.

True, but mentally balancing parentheses is usually something that you do while writing the code: you pushpop a little stack in your head and this becomes second nature.

Mentally verifying if parentheses are balanced while reading code is hardly ever required. You can usually safely assume that they are (unless that darn compiler tells you otherwise).
I'm a full-stack engineer, but my main focus has always been frontend, so to give my perspective.

Frontend is really hard, writing re-usable HTML and CSS is almost as hard as writing re-usable backend modules. I get annoyed by backend engineers brushing off frontend, as it's a piece of cake for them. But when you actually ask them to write some, they struggle, because they have no idea how to make it reusable.

Frontend especially requires you to stay up-to-date, even more so than backend technologies. The ecosystem changes so much, that it can become an annoyance, but the key is to stick to what you think is best. For example, I still use Gulp for tasks, just because it works, and it's far easier to configure than Webpack or any other bundler.

But on the backend, I've found that there are far more interesting problems to solve. The design behind it is far more complex, especially when you start dealing with databases and message queues.
But then you also need to start looking at how to deploy your backend, and how to scale it up, etc...

So when I made the move from frontend to backend, it wasn't easy. But it also wasn't particularly hard, if you know JS/TS, moving to a node backend is fairly straight forward. Once you have enough experience there, moving to Java or Python is just learning whatever framework you're using.
What I found much more difficult, was moving back to frontend, after doing backend for a couple of months, I felt like many things had changed, and it was hard to switch my mindset back to frontend.
The idea of needing to go somewhere to talk to a teller seems fairly old fashioned, whether or not that's done via a video stream. My bank doesn't even have physical buildings - you just do everything through the app.
Sounds like most customer interactions in Singapore that don't perfectly fit into the standard workflow to me.
systemd just has so many reasons to kill processes, and invents new ones with new releases. Timeouts for things it thinks it should be short-lived, resource limits, service isolation and sandboxing settings, etc. They are mostly documented, but you need to know where to look. While I came to like some aspects of systemd, debugging why things die for apparently no reason after systemd was upgraded has eaten many of my workdays.
I'm very bad with money. I never look at my account balance when I spend money. Heck, often months pass without me looking at my account at all. When I end up seeing the balance it is always much higher than I expected.

What am I missing? Oh right, I earn more than the average person in my country and I'm so busy I don't even have time to spend the money.
Treeware
Nice! I'm not sure if I want them to win though. Perhaps this may create a precedent also applicable to people exploring Apple firmwares for sake of user freedom and privacy rather than spying on people.
Everything is doable with LSP as it is an extensible RPC essentially.

But the above things are not done in LSP generally. It doesn’t have first-class support for structural search replace. It doesn’t have support for interactive refactors which require user input.
I moved from being a frontend guy to full stack.

What I learned is that being a front or back end guy is an artificial constraint. If you know frontend JS, working with NodeJS is not that hard. If you know NodeJS, django is doable.
In the end, it's all about solving problems, not tools.

If you are a decent engineer, you will able to solve problems in almost any environment. It might not be the best or most elegant solution in the beginning, but that comes with time.

A good first step for a front end guy to branch out is to learn how to write the APIs yourself. Then you have your foot in the door.
Oh: and I must say that modern frameworks have made frontend development much easier than it used to be. With Angular, Vue, React you can actually apply the good engineering practises to structure your code in a way that makes it more manageable than it was in the past (with JQuery + server-side templates).

The testing frameworks are also pretty good, helped a lot by the frameworks being built properly (inversion of control :drools:).
The source of experimentation have been Phil Lord and Christopher Miller, who have been pushing for experimentation ever since they directed the extremely successful Lego Movie.

They were producers in both Into the Spider Verse and Mitchell’s vs the Machines. They are the reason why this “willingness to do experiment” has happened - they succeeded beyond everyone’s dreams with Lego Movie and have taken a producer role in films that want to push the artistic envelope in 3D animation.

It’s now part of their MO to push the envelope and have each of these films “be their own thing”.

Fortiche has no relationship with them, but they would have never been allowed to do what they did here without those films having been produced IMO.

If you’re interested to know more I recommend you listen to the Roger Deakins’ podcast with them.
I’d hazard a guess you’re probably right.

Still worrying that someone who’s prepared to spout that opinion made it that far up the organisation.
Only those who would benefit from systematic injustice, could possibly oppose this proposal.

/s, or is it??
What I haven't seen mentioned here is that as a backend dev you're usually much closer to the business people. You'll have to talk to them, understand their needs and translated them from their language into code. You'll have to come up with a design and implement it. Business logic is more common to be found in backends than frontends in my experience unless you do something with really sophisticated UIs.
I find it easier anyway, mostly because I can write most code (for a specific endpoint) in my head and when I type it in, it works. With frontend, not so much. And with the visual feedback trial and error loop that frontend often ends up in, I often would not call it programming at all.

The annoying things (to me) about frontend are of course apples and pears; architecting for frontend, writing logic and fetching data is comparable with backend dev and similarly straightforward imho. While we are all fullstack, we have a few seniors who do 90% frontend and a few 90% backend; the 10% overlap that backend spends on frontend is writing logic and data fetching: after that it moves to frontend to do the rest.
Back End owns more of the infrastructure, including the admin, pipeline, and networking chores.

But the UX seems the 20% of the system eating 80% of the time, yes.
Not 'significantly' higher, no. In the remote-first covid world you are going to be paying at least Austin/Seattle rates for talent in London and closer to NYC comp packages. It has been a very, very good 12-18 months for tech talent in London if you have the right CV.
You can have hash tables that cannot be targeted by DoS attacks.

You can use a family of hash functions and seed the hash table instance with a key.

The attacker won't be able to do make assumptions regarding collisions because he doesn't have access to the initial key.
Front-end is awful in (large) part because of the tooling IMO. In the backend world, you need to make sure your _vertical_ (aka scale) is respected. It's a matter of your code, your infra plus the tooling to help you. If you're good at what you do, use the correct engineering approaches to have an efficient program and use up to date infrastructure or platforms, and use an up to date language (Rust, Python, Java is excellent here, whatever) you'll have all the tools.
Your ground won't move as long as you didn't ask him to move. So, For me, it's easier to maintain (but still requires a loooot of care and attention to not fall apart)

In the frontend world, as you said, it's movement everywhere. Browsers, JS, JS package managers, CSS and so on. Even if your code don't move, the platform under will. Your code performance is not only dependent of you, making you tied to the evolution if you want to be up to date. That's so hard, and ungrateful...

If you want to stay in the frontend world, you should definitely increase your knowledge in CSS + Responsive, I think it's the best skill.
In JS, stay on par with the language spec. Libraries will come and go, you can learn one (Vue or React, whatever it's the same) to understand the foundations, and it can land you a job basically everywhere.

Backend is easier because it's vertically aligned: performance and stability on a given system that you own.
Frontend is horizontally aligned: acceptable performance and rendering on a shitload of systems which enslave you.

What interested me those last months is another path: Mobile dev, especially with Flutter.
You keep some stability of a fixed OS (you still have the different versions + screen size, but you choose which one to support), and have the tooling of something close to the backend (compiled languages, package manager, big community).
I think you should take a look there if you still want to keep a feet in "client" software, plus you'll never get out of job offers!
Wouldn't that mean that both have the exact same responsibility? A bug in the FE, would essentially render the BE unusable, and therefore would cost a lot of money and time as well.

For example; if Amazon's checkout button somehow broke, and prevent users from checking out, it would also cost a lot of money.

EDIT: to give a more visual example, if Amazon changed their checkout button to a different color and style. It could potentially cost them millions, because it might not entice users to click it.