Hacker News Reader

Comment by h4kor | Hacker News Reader

> Several teams of engineers are working overtime to ensure that The Merge arrives as soon as possible, and without compromising on safety.

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.

View on HN

I think they're being hyperbolic. "we're working really hard to make it happen"

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 :)

> But good to see that Ethereum came to their senses and are serious about reducing the environmental impact they have.

Is it not possible there's good reasons they didn't move to proof of stake sooner? "Came to their senses" seems to imply they had no good reasons.

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.

Kinda what I figured. Thanks for the response.

It has been the goal since day one.

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.

[1] https://medium.com/fullstacked/the-ice-age-is-coming-ee5ad5f...

I don’t think PoS was a thing when Ethereum was invented.

It's mentioned in the whitepaper - https://ethereum.org/en/whitepaper/

> 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.

Interesting, in any case I don’t think any decision was made to ease the transition at the time.

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.

Mkay

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. My whole team at once? Not really.

Unless management is really vigilant, when people are working overtime everyone on the team feels pressure to do the same.

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.

PoS has been the goal of Ethereum for a long, long time.

I don't know the technicals of why the migration has been gradual, but the destination has never really been in doubt.

Are you serious? This was proposed in the initial white paper. It's not something that suddenly came to mind. This stuff takes time

No it doesnt. Having hard time/budget/whatever constraints does.

Otherwise, theoretically you can "overwork" i.e. (work more than standard 40 hour weeks or some standard of work hours) whatever without compromise

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.

Thats a problem of process where errors are caught.

It makes things more inefficient, but it doesn't compromise final quality assuming issues are found and addressed.

so the solution to overwork is more work?

yes? That was literally my point, its less efficient, but can be okay in terms of final output.

Not sure that holds up to scrutiny, as often when people are tired and overworked their output can dip negative.

It's fine for a few days, but after that it's a false economy.

No quality control process can reliably catch software errors. That's why it's generally better to prevent errors rather than catching and fixing.

Why does "normal working hours" solve the "reliably catch software errors" issue.

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.

https://www.fastcompany.com/28121/they-write-right-stuff

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.

https://sw-eng.larc.nasa.gov/supporting-products/archive-of-...

That's amazing work and dedication.

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.

So now you have to do extra work to catch errors, which is a compromise in its own right.

hence the inefficiency comment?

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?

> 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.

[0] https://siepr.stanford.edu/research/publications/productivit...

Reply on news.ycombinator.com