Yes, I would not read much into it. In the end, writing "We were sort of working on it at a reasonable pace, you know, work life balance is more important to our developers than finishing a month earlier" just doesn't have the same ring to it :)
The Ethereum protocol was designed with PoS in mind and has a built-in difficulty bomb[1] to prove it. In short, this difficulty bomb makes it exponentially harder to mine ETH over time. The goal of this feature was to encourage all participants of the ecosystem to transition to PoS as quickly as possible.
Given that, the implementation has not worked out totally as expected, as the difficulty bomb has been pushed back a few times over the years. However, to answer your question, the reason they did not move faster is because this transition is hard and plays in some uncharted territory.
> Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year.
It absolutely was, Peercoin (PPC), and even DPoS (BTS) predates ethereum too. What are they worth today? PoS is a scam -- also Diem is worse -- it is dystopia.
This has been the plan for a long time. But this is like Google deciding to switch to Microsoft Windows, it's not something they can just decide to do one day. There's a process. It's a massive effort and hundreds of billions of dollars are on the line.
Only time will be able to arbitrate this one, but we have consistently pushed out time-lines to ensure that Ethereum remains safe. Ethereum core development definitely favours partition tolerance and safety over liveness.
Overtime != overwork. You've probably programmed something, at some point, where you were excited to work on it from morning to night? Where you lose track of hours, forget to eat meals and completely in the zone? That could easily be the case with these engineers, working on such a historical project and consequential update.
I have been in that zone for two or three day stretches, but never beyond, and never in sync with a full team. I have experienced two forms of team wide over-time in my career. The first lasted (for me) about seven months, then I quit. I couldn't take in anymore and the project (large team, 150 people) was on fire. That was completely unsustainable. The second form was a periodic event that happened every two years when we released a new silicon design (chip vendor). The day that the first silicon was mounted onto boards began a cycle of ten to twelve days, 14 hours a day, lunch and dinner being one hour status briefings. All hands on deck. At the end of those ten or twelve days, either the silicon was fully validated, or all its known flaws were identified. And everybody on the team took a couple days off to breath. That was sustainable because it was infrequent, planned, and closed ended. I went through four of those cycles. They were exhausting and thrilling at the same time. And thankfully, infrequent and closed ended. There was always a light at the end of the tunnel.
This is a different dynamic than traditional organization. It's decentralized with contributors around the world. You have no idea how much others are working and many are contributing because it's something they're passionate about.
> Otherwise, theoretically you can "overwork" i.e. (work more than standard 40 hour weeks or some standard of work hours) whatever without compromise
That's simply not true. Humans aren't machines. Productivity falls off a cliff after 50 hours, and after 55 you may as well not even be in the office. There are diminishing returns with "overwork"ing.
On paper, sure. In practice, having people overworked leads to compromises you never intend to make, simply due to exhaustion and burden clouding judgement values.
Every software error? True. But essentially every software error, especially errors of significance? Untrue. The Space Shuttle control software was famous for its rigorous process control, and deliberately written in a language difficult to introduce bugs in. Over decades of development and 420,000 total lines of code, it appears that a total of 17 bugs ever made it into software used during a launch, with an average of about 1 bug at a time existing in the codebase. Processes to prevent errors from being introduced played a huge part in this, but the comprehensive verification and simulation process was also necessary to achieve such a low defect rate.
The NASA Manager’s Handbook for Software Development from 1990 is a great resource. We have better techniques for some areas now but most of it still holds up.
But I feel it fair to consider an organization like NASA as an exemption from the norm. This level of detailed error catching doesn't make sense for, say, a facebook clone startup.
That said, someone should send this comment to a Tesla engineer.
That makes sense, but the point is that it's still a compromise. Even if we're saying that people can work overtime to get things done, there's typically diminishing returns on each additional hour worked, and still no guarantee that quality hasn't been impacted.
If you ask people to work 12 hour days instead of 8 days, does each day provide 8 hours worth of work, 12 hours worth of work, or another value? Can we reliably say that any problems arising from working over 12 hour days are caught and handled at the same level as they would be if people were working 8 hour days?
Overworking your engineers will most definitely lead to compromises.
But good to see that Ethereum came to their senses and are serious about reducing the environmental impact they have.