That machine was my intro to computers too, and I was fascinated by “fast mode” blanking the screen and the interesting tradeoffs between hardware and software.
4,017 karma · joined May 11, 2017
Easements can be a huge headache too e.g. some utility may have an easement to come on your property at any time and do a whole list of activities to maintain a pipeline, or power line, or what have you.
You describe a shared database, micro services you aren't aware of using the same database, and a desire for everyone to have a rough idea of the state of the codebase. And things breaking unexpectedly being caught by code review.
You have a bigger problem here of a system you can't reason about very well. The code review will help here, but I think you have bigger discoverability problems based on what I'm reading.
As others have said, what is needed is automated testing that would catch this sort of problem automatically without needing a human in the loop saying "Oh, wait...". We still want/need humans in the loop, but they should not be the only safety net.
Very little, or possible nothing at all, is going to change in 3 weeks. If you are that myopic - as the XP people were - then constant failure is not going to be surprising. It will be expected.
YAGNI in that context is hilarious, because they were replacing an existing COBOL based payroll system. They literally needed pretty much everything the old system did to be successful. Part of the failure is because the devs did not understand what they were replacing.
Not that they didn’t write no code, obviously, but they didn’t understand the domain and so YAGNI’d everyone to death. As a result there wasn’t enough code for the system would do what it needed to do.
The code was simple and highly testable, but didn’t actually do the job.
I think a huge amount of technical debt goes straight to YAGNI - devs pretending they are not going to need something that, yeah, they need.
YAGNI and related tenets were all excuses for “we are consultants in a field we don’t understand”.
Your expectations of course are not unusual because so many developers work on systems where users are not the customers, but the product.
Facebook, Insta, Google all fuck up results very regularly, but what are you gonna do when they do?
Now imagine your bank occasionally losing deposits, your account balance going up and down a percent or two every day, the IRS fining you for tax evasion because your Cool Fintech Rounding does not match generally accepted accounting rules.
Without physical feedback you can rapidly devolve into unstable positive feedback loops. And emotions are what help us process and react to that feedback.
Kids learn partially because their friends say sharp words that hurt them, fire burns them, they go hungry and starve if they don’t plan for meals.
Humans in the loop, MCP, etc are all very primitive hacks that are mimicing feedback and emotion, poorly.
Looks like just a handout to IBM.
Macos really excels at managing memory very well.
They definitely had brain power at the Holmdel location too.
You mean like every startup ever that has been successful?
And for a service that is heavily text bound? A 14x increase would not be a big deal.
What "brunt"? These are not large numbers.
If Microsoft can't scale something like Git 14x, then the problem is with Microsoft.
A volume increase that is a single order of magnitude (which 14x is) should not result in this level of failures.
When I compare what Github does and the volumes vs social media companies, payment companies, video platforms, etc, it just doesn't make sense that it is just a volume problem.
It looks a lot more like a platform that already has baseline issues that are compounded by increased volume.
We had a vote thrown out of an election several years ago, the woman died right after the election, the signature on the card looked nothing like hers and was probably done by her daughter.
That said all indications are voter fraud is not any kind of wide spread problem in the United States.
The loading dock was kept completely open "because it's hot and we don't have A/C back here!".
He started complaining to management that 50 CI/CD setups was his limit he could support.
He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.
I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications.
What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbrella. But shield them from the details and your specific efforts here, unless it is relevant.
Maybe even more important, though - recognize inflection points in your company and your group. How you manage during routine times and during stressful times may well be very different. If they're not, then you have a serious problem.