5 ms·

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

by h4kor 5y ago

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

bpodgursky 5y ago
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.
NikolaeVarius 5y ago
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
- ysavir 5y ago
  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.
  - NikolaeVarius 5y ago
    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.
    - soperj 5y ago
      so the solution to overwork is more work?
      - NikolaeVarius 5y ago
        yes? That was literally my point, its less efficient, but can be okay in terms of final output.
        Nursie 5y ago
        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.
    - nradov 5y ago
      No quality control process can reliably catch software errors. That's why it's generally better to prevent errors rather than catching and fixing.
      - NikolaeVarius 5y ago
        Why does "normal working hours" solve the "reliably catch software errors" issue.
      - dodobirdlord 5y ago
        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 https://www.fastcompany.com/28121/they-write-right-stuff
        nradov 5y ago
        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-supporting-materials/ https://sw-eng.larc.nasa.gov/supporting-products/archive-of-...
        ysavir 5y ago
        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.
    - ysavir 5y ago
      So now you have to do extra work to catch errors, which is a compromise in its own right.
      - NikolaeVarius 5y ago
        hence the inefficiency comment?
        ysavir 5y ago
        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?
- shakna 5y ago
  > 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/productivity-working-hours https://siepr.stanford.edu/research/publications/productivit...
kodah 5y ago
> 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.
- svachalek 5y ago
  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.
  - kodah 5y ago
    Kinda what I figured. Thanks for the response.
- shanecoin 5y ago
  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-ee5ad5fa485c https://medium.com/fullstacked/the-ice-age-is-coming-ee5ad5f...
  - baby 5y ago
    I don’t think PoS was a thing when Ethereum was invented.
    - joshmarlow 5y ago
      It's mentioned in the whitepaper - https://ethereum.org/en/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.
throwkeep 5y ago
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.
- bcrosby95 5y ago
  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.
  - greyhair 5y ago
    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.
  - hanniabu 5y ago
    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.
bhandziuk 5y ago
I think they're being hyperbolic. "we're working really hard to make it happen"
- serial_dev 5y ago
  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 :)
CarlBeek 5y ago
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.
svarog-run 5y ago
Are you serious? This was proposed in the initial white paper. It's not something that suddenly came to mind. This stuff takes time

by h4kor 5y ago

bpodgursky 5y ago

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.

NikolaeVarius 5y ago

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

ysavir 5y ago
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.
- NikolaeVarius 5y ago
  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.
  - soperj 5y ago
    so the solution to overwork is more work?
    - NikolaeVarius 5y ago
      yes? That was literally my point, its less efficient, but can be okay in terms of final output.
      - Nursie 5y ago
        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.
  - nradov 5y ago
    No quality control process can reliably catch software errors. That's why it's generally better to prevent errors rather than catching and fixing.
    - NikolaeVarius 5y ago
      Why does "normal working hours" solve the "reliably catch software errors" issue.
    - dodobirdlord 5y ago
      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 https://www.fastcompany.com/28121/they-write-right-stuff
      - nradov 5y ago
        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-supporting-materials/ https://sw-eng.larc.nasa.gov/supporting-products/archive-of-...
      - ysavir 5y ago
        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.
  - ysavir 5y ago
    So now you have to do extra work to catch errors, which is a compromise in its own right.
    - NikolaeVarius 5y ago
      hence the inefficiency comment?
      - ysavir 5y ago
        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?
shakna 5y ago
> 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/productivity-working-hours https://siepr.stanford.edu/research/publications/productivit...

kodah 5y ago

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

svachalek 5y ago
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.
- kodah 5y ago
  Kinda what I figured. Thanks for the response.
shanecoin 5y ago
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-ee5ad5fa485c https://medium.com/fullstacked/the-ice-age-is-coming-ee5ad5f...
- baby 5y ago
  I don’t think PoS was a thing when Ethereum was invented.
  - joshmarlow 5y ago
    It's mentioned in the whitepaper - https://ethereum.org/en/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.

throwkeep 5y ago

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.

bcrosby95 5y ago
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.
- greyhair 5y ago
  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.
- hanniabu 5y ago
  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.

bhandziuk 5y ago

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

serial_dev 5y ago
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 :)

CarlBeek 5y ago

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.

svarog-run 5y ago

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