As far as getting paid to write code in our industry goes, it was quite enjoyable. Most of the code was totally new and not particularly tightly coupled with the rest of the system, so the challenges were in understanding the subtleties of the requirements and coming up with a clean and performant design rather than fighting legacy code.
Touch wood, I've done a reasonable job. We got it done a couple of months before it was required and a full dry run with our entire customer base only found one pretty subtle edge case that I'd missed.
So we get to keep our license to look after billions of pounds of customers retirement savings, which is kinda important, and because I worked on this other developers got to work on stuff that actually helps our customers (which is important for our customers, and ensuring that our business retains and expands said customer base).
However, the new version of the regulations, while written with the laudable intention of providing people with more accurate and unbiased information about how much money they will have on retirement, achieve nothing of the sort. It just replaces one set of assumptions that are wrong on some edge cases, with another set of assumptions that are wrong on a different set of edge cases, in some cases arguably wrong in worse ways. Nor does it address the real weaknesses in these statements.
And across the industry, there are literally dozens of companies who had developers who spent similar amounts of time to me implementing this new standard, for no benefit of any of their customers that I can discern either.
I feel much the same way about working on code for Australia's Consumer Data Right (CDR).
Mostly it would have been OK if the code handed to me (a project I took over) wasn't the worst kind of "smart people doing stupid things" dependency injection hell in javascript. Then, having to deal with the ever evolving CDR regulations for the banking sector and trying to get the institution I was working for to take it seriously (there are fines involved if it doesn't work).
The end result - nobody in the public actually uses it except for a few dodgy lender-of-last-resort companies.
https://www.frc.org.uk/library/standards-codes-policy/actuar...
As far as getting paid to write code in our industry goes, it was quite enjoyable. Most of the code was totally new and not particularly tightly coupled with the rest of the system, so the challenges were in understanding the subtleties of the requirements and coming up with a clean and performant design rather than fighting legacy code.
Touch wood, I've done a reasonable job. We got it done a couple of months before it was required and a full dry run with our entire customer base only found one pretty subtle edge case that I'd missed.
So we get to keep our license to look after billions of pounds of customers retirement savings, which is kinda important, and because I worked on this other developers got to work on stuff that actually helps our customers (which is important for our customers, and ensuring that our business retains and expands said customer base).
However, the new version of the regulations, while written with the laudable intention of providing people with more accurate and unbiased information about how much money they will have on retirement, achieve nothing of the sort. It just replaces one set of assumptions that are wrong on some edge cases, with another set of assumptions that are wrong on a different set of edge cases, in some cases arguably wrong in worse ways. Nor does it address the real weaknesses in these statements.
And across the industry, there are literally dozens of companies who had developers who spent similar amounts of time to me implementing this new standard, for no benefit of any of their customers that I can discern either.