I've built a tool that analyses UK company accounts data to highlight various forms of unfair treatment of workers, such as serious wage decline in spite of soaring profits.
All data sourced from Companies House as xbrl or pdf.
The trickiest part was all the unexpected edge cases I found in the data, but that's also where most of the learning (aka fun) was found. For instance, before starting this project I didn't know that negative turnover was possible, or that accounting periods vary between years and can be 52/53 weeks to make sure they end on a specific day of the week. The more I learned, the more aware of my ignorance in this regard!
Here is a typical example:
> Between 2024 and 2025, workers at this company each lost £4,196 due to a combination of falling pay and price inflation.
(User clicks/taps through if they want details and method)
I've also noticed a high representation of care-home providers appearing in the results. It's something I want to dig into but it's unexplained (to me) for now. Possibly it's related to a higher proportion of workers on zero-hours contracts.
It's also been challenging to present less obvious factors such as nominal and real wages alongside inflation metrics, all intended for a non-technical audience. Consequently I've spent a disproportionate amount of time on the wording for each type of inequality, and I'm still tinkering.
Not ready to share the URL just yet, as the site could easily be abused or the facts taken out of context and used to mislead or unfairly (lol) condemn. It may never be public, but I definitely have an audience in mind.
Ideas for development include
- sector/industry analysis and comparisons
- an inequality leader-board of some kind
- sentiment analysis from director reports
- search and filter
I started programming on Zilog z80 when I was 11 years old, at school in NZ. I'm now 55, and I've been a programmer for all that time. I've worked as contractor, consultant, tech and architecture lead, people manager, independent limited company in the UK, published author. I started a charity. There's more, but you get the idea, I've seen many sides of this programming malarkey.
Like you, at times, I reached a plateau of motivation, and more than once I questioned the meaning of the job I was doing, unsatisfied and listless.
I think if you are at all introspective, reflective, that it's inevitable you go through patches like this.
You've now got plenty of advice from many with experience, I won't add to that pile. Instead, just briefly, a word on my current situation and outlook.
Working for someone else is only rarely going to be broadly fulfilling. Working for yourself can be worse.
So I developed my hobby interests, most involving programming, because I still love it. I still get excited exploring possible solutions to hard problems. It's fulfilling in a way that working for megaCorp can never be. It's the difference between straining to meet a work deadline and straining to win a game. Similar, but different.
In other words, contentment, for me, comes from within.
Realistically that is the balance I am hoping to eventually reach through freelancing (more money the freedom to work on things I like and try micro businesses)
Voluntarily playing Kd7 on move 5 instead of castling is maybe a human move (like a bong cloud) but at the time it seemed more like a move a stochastic parrot would make.
Stripe, first of all, your report misrepresents software development reality.
You present software maintenance as a massive waste of time and money. But that’s just not true. Maintenance is how software stays relevant.
Laws and regulations change, technology platforms change, features rise and fall in importance, the users themselves change over time. There are endless justifications for ongoing software maintenance.
For as long as software serves a useful purpose, it will need maintenance.
Yet you present maintenance as somehow bad, when in reality maintenance is the natural consequence and an essential aspect of software development, and it has always been so.
You’re also pandering to an ignorant attitude that believes software can be written free from bugs and perfectly formed from the outset. Thus all it takes, thinks the ignorant executive, is for my coders to be better than they are.
You highlight the cost of “bad code”.
You don’t provide a definition of bad code, so here’s mine:
Bad code is code that is hard to understand and/or hard to modify without breaking things and introducing errors.
If you know software developers, you know we are, on the whole, vocal and assertive about the avoidance and elimination of bad code. Look at what we talk about at conferences, in blog posts, and on twitter.
Writing and learning about good code is a consuming passion for many developers. Search for “clean code” to see countless examples.
How do we avoid writing bad code in the first place? That is a billion-dollar question (or $85bn as you say).
Everyone without exception agrees we should not write bad code, yet bad code persists.
Bad code is a function of ambiguous requirements, unreasonable deadlines, lack of training and support, lack of a proper testing regime, lack of appropriate project sponsorship, internal politics, lack of funding, and so on.
Yes, some engineers will at times be lazy, thoughtless, short-sighted. Just like their managers. Just like their manager's manager.
But in the round, bad code exists primarily because of human, social, and political problems we all share.
And then consider how we eliminate bad code. We do that with maintenance of the code, Stripe, this is the very thing your report damns as waste.
To maintain software, we refactor, we add tests, we discuss and debate, we tease apart and reconstruct. To the software developer, maintenance is normal and expected. It’s part of the job. You build it, then you support and maintain it.
The reason I’m so hot about this is that I know (from watching it happen again and again) how many executive level managers will interpret your report. They will think it’s because their programmers are lazy, feckless, indolent, and narcissistic.
It’s cognitively and politically much easier to blame bad code on an engineer’s attitude than the ecosystem in which they work.
And these executive level managers will vent their frustration on those same engineers and look for quick wins like off-shoring.
"If we’re going to suffer from bad code, at least let’s get it cheaply."
Or the exec might crank up their attitude of command-and-control to bring those apparently miscreant coders to order. Misery for the coder, and never works out well.
Stripe, your report does not help us get better. You’re throwing fuel on the fire.
(Originally posted most of this Twitter, wanted it here to increase the chance of someone relevant at Stripe seeing it)
I will join the chorus - wkhtmltopdf has been working fine in production for many months, reliably producing thousands of 10+ page PDFs with cover pages, headers, footers, page numbering, and images. Sure, it takes bit of fiddling to get it working as you like the first time - as most non trivial things do - but I've no regrets and would recommend it.
We're just a simulation of intelligence that's done with clunky, inelegant biological materials. The only thing that separates humans from slugs is scale and complexity of neural interconnections, all the basic parts are present in a slug.
Intelligence itself is an emergent phenomenon, so who's to say what's "simulated" and what's "real"? If it behaves in an intelligent manner, which can be tested and probed exhaustively, then it is intelligent.
That’s the standard zombie argument. It’s weakness is that the premise is not reasonable. If the premise is true, the argument is compelling. But there is no strong evidence that the premise is true or possible.
Please note that I haven’t taken a stance on this here myself, so there’s no need to argue with me about the truth or falsity of the premise. I’m just explaining the problem with the zombie argument.
"The self is a kind of fiction, for hosts and humans alike. It's a story we tell ourselves... there is no threshold that makes us greater than the sum of our parts, no inflection point at which we become fully alive."
Yes, and, I might be misunderstanding your question, but I view that as a good thing. I don't ever want to spend my time in a meeting witnessing people bicker over where to position a dialog button, when you could just run an A/B test and let data guide the decision process.
"Based on the data collected, most users seem to prefer..." is better than, "Based on my training and personal experiences, I think users would prefer..."
It is a lot easier to come to a common agreement on something as objective as statistical significance when compared to personal feelings and opinions.
Yes. There was a piece on 60 Minutes a few years back where they had a big (~20 ft. wingspan maybe), loud drone circling overhead a few thousand feet up. It was inaudible and invisible. What's the point in solving a hard problem like hi-res imagery from space when you can just fly one of these over the target practically at will? (With a Hellfire missile attached, no less.) Range and airspace issues notwithstanding, the drone future is a scary place.
Those are precisely the reasons satellites will remain relevant. Satellites are the reason the SR-71 fell out of service. Russia can and will shoot down US aircraft or drones in their airspace.
SR-71 is about as far from a drone as you can possibly get. Politicians are going to (pretend to) care a lot less about airspace sovereignty when violating someone else's airspace does not involve risking pilots' lives. Range and stealth are only going to increase. This is why I said the future looks bleak.
All data sourced from Companies House as xbrl or pdf.
The trickiest part was all the unexpected edge cases I found in the data, but that's also where most of the learning (aka fun) was found. For instance, before starting this project I didn't know that negative turnover was possible, or that accounting periods vary between years and can be 52/53 weeks to make sure they end on a specific day of the week. The more I learned, the more aware of my ignorance in this regard!
Here is a typical example:
> Between 2024 and 2025, workers at this company each lost £4,196 due to a combination of falling pay and price inflation.
(User clicks/taps through if they want details and method)
I've also noticed a high representation of care-home providers appearing in the results. It's something I want to dig into but it's unexplained (to me) for now. Possibly it's related to a higher proportion of workers on zero-hours contracts.
It's also been challenging to present less obvious factors such as nominal and real wages alongside inflation metrics, all intended for a non-technical audience. Consequently I've spent a disproportionate amount of time on the wording for each type of inequality, and I'm still tinkering.
Not ready to share the URL just yet, as the site could easily be abused or the facts taken out of context and used to mislead or unfairly (lol) condemn. It may never be public, but I definitely have an audience in mind.
Ideas for development include - sector/industry analysis and comparisons - an inequality leader-board of some kind - sentiment analysis from director reports - search and filter
reply