Usually the TZ offset is enough. The use case is a guy reading notes and logs from multiple sources. All that guy needs is to see the local time at the time and place of the event. So that, for example, he can match up the time stamp on some computer recorded log with the time some human operator recorded, in local time, on a paper record.
Ralph Waldo Emerson is as relevant as always: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."
Also Instant is a database (it has queries and so forth, more appropriate for bigger data). I would put Jazz at the document sync side of the spectrum:
With decentralised I always like to be very precise:
- Jazz is decentralised in a "source of truth" sense. You mutate data locally and sync edits between participants until you reach eventually consistent history (and thus state, as per the underlying CRDTs)
- the protocol is peer-to-peer
- the way you use it typically is in a very centralised way. You use a central sync and persistence peer (either your own, or my distributed Jazz Mesh service) and every device syncs to that. That way devices don't have to be online at the same time to sync
> I have yet to visit this misterious universe you describe.
The trick is to have 1 backlog. Tech debt and features live on the same list and it is up to the PM to prioritize. Engineering’s job is to argue cost.
Good PMs will prioritize relevant tech debt or pull it in with feature work in the same area. They understand the tradeoff of go slow to go fast. They also understand when tech debt will never become relevant (because the feature is getting nixed, or hasn’t shown desired impact yet, or because the cost of interest is waaaay lower than the cost of paying it off in many cases).
This only works when engineers have the discipline to look stinky awful code in the eye and say “not today” and stay within agreed timeboxes. You blow this estimate once or twice, get the PM in hot water with leadership, and you’ve lost the trust.
All of the teams I've been on have used one list. I've never seen a PM prioritize the technical work. I still think it's a good idea for it to be one list, but it's not sufficient.
For teams that don't have a good PM, you also need a tech champion. Failing that, engineers need to inflate estimates and do tech work under other stories. Then everything becomes less predictable and teams never develop trust.
All PMs I have seen so far were just passing on management’s desire for more features quickly. The only approach I have seen work is if engineering adds refactoring as part of the normal work that needs to be done without asking for permission.
That's the practical advice to engineers who are stuck in a dysfunctional organization where they can't really effect change, which is probably 90%+ of all organizations.
> For teams that don't have a good PM, you also need a tech champion
Yes. And to add some nuance, you need a [trusted] engineer who can say “This will take 3 weeks because of tech debt items A, B, C. We can fix those in 1 week and then take 1 week to implement this. How would you like to proceed?”
Any decent PM will take the 2 week option that also cleans up the codebase.
But if fixing the tech debt would take 3 weeks and then another 2 weeks to build the feature, then any decent PM will take the option that doesn’t fix tech debt unless there’s a bunch more stuff coming in this area in which case taking 3 weeks to fix stuff is totally worth it.
Their job is to make those tradeoffs. Our job is to highlight the tradeoffs they’re making so they can make informed decisions.
> “This will take 3 weeks because of tech debt items A, B, C. We can fix those in 1 week and then take 1 week to implement this. How would you like to proceed?”
I've experienced something like this, but only on a project that mostly had the original team that built it (including me) still working on it. We were able to keep things in check, and in the above case would just do it that way without really asking.
On many other projects I've been involved in, there's years of tech debt that has accumulated: the typical retrospectively incorrect design decision, followed by layers and layers of band-aids, each time making the real fix more complicated and a bigger scope.
These things undoubtedly increase the cost of everything else, but it's really hard to articulate. The fixes take weeks, the break-even won't come until months later, the long-term team members are a mix of skeptical and defensive of their work (eg: don't want to do the real fix). In some cases, there's a war story "we heard that about x, but that caused so many bugs we had to revert and abandon it, why is this going to be different?"
Those are easy calls for which everyone's incentives are aligned.
The problems come from the calls where personal incentives are not aligned. A typical example - the team builds a feature hidden by a feature toggle which is, after a period of A/B testing, enabled globally on the product.
The existence of the feature toggle raises the complexity of the code - let's say it's used in 10 different places, each of those double the amount of possible code paths. Removing it may be a question of a couple of hours of work and is very clearly work paying for itself in the long term, but PM will not schedule this work, because there's no immediate upside for them personally and the cost of keeping the toggle in code is a long term one, spread over the whole organization.
In other words, PM is more likely to get a bonus by slashing work on such tech debt items (and thus them personally delivering the features faster) rather than punished for keeping the toggles/complexity behind.
> Our job is to highlight the tradeoffs they’re making so they can make informed decisions.
This is an oft-stated thing that I oft-disagree with. It states that engineers ought to be subordinate to PMs, which shouldn't always be the case.
If you have shit engineers and great PMs, the best outcome is likely to shift decision making to PMs. If you have great engineers and shit PMs, decision making should shift towards engineers.
If they are both equivalently shit or great, it should be a balance. I believe this is the most likely scenario. I believe that balance is thrown out the window if engineers "highlight the tradeoffs" while the actual decision making is lies with the PMs.
How to actually achieve balance is extremely idiomatic to the team and organization. It's hard to get people to have adult, non-confrontational discussions about this sort of thing, however. Too many people will treat it as a negotiation.
> This is an oft-stated thing that I oft-disagree with. It states that engineers ought to be subordinate to PMs, which shouldn't always be the case.
I think of it more as a partnership.
If I’m in charge of getting groceries and you’re in charge of budgets, we need to have an informed discussion on what exactly is our budget and what food we need so we don’t starve. Sure I could blow the whole budget on steak and I might even love eating nothing but steak for 3 days, but eventually some carbs would be nice. Likewise neither of us will be happy if I go max stingy and buy nothing but bags of rice for the week.
The reason I think PMs should make the final call is not that engineers are subordinate, it’s that PMs are accountable. (RACI – responsible, accountable, consulted, informed). The person whose ass is on the line makes the call.
Usually when I ask engineers if they want to be accountable for making the call (and its outcome), things get real quiet real fast :)
If PMs are accountable, then I'm with you. Decision making should lie with those accountable.
From what I've seen, accountability doesn't mean much. Could be the places I've worked. Poor PMs get promoted despite running projects into the ground, good engineers get held back despite pushing through adverse project plans, vice versa.
I remember working in a team where the backlog was controlled by the PM and he created a separate backlog that developers got to use - unsurprisingly, pretty much nothing ever got moved out of the separate backlog.
> For teams that don't have a good PM, you also need a tech champion.
That's part of the role of a Technical Program Manager. The Eng Manager, Product Manager, and TPM should form a holy trinity of mutual support, filling in for each other's gaps. When that happens, you get much better odd of having a high performing team.
Source: I've been both an engineering manager and a TPM. Never the PM, though.
That just lets the lazy devs scapegoat the PM for “not letting the “ work on the tech debt.
Most people don’t want to work on it. That’s why there is so much. Generating it is like eating candy. It’s unhealthy but you just want to have something sweet right now and the bowl is in reach…
Most co-workers I’ve had would have _loved_ to fix the shortcuts and hacks that were done to meet deadlines, but were never given the time.
“Refactor while you do new features” works sometimes, but doesn’t work on anything larger scale - e.g. if your overall architecture is collapsing under its own weight, it’s hard to “sneak in” the sort of major work you need to do to fix it.
Oh there’s always a few of those, but then there’s the corner cutters who make more of the mess than everyone else, and few impostors who fade into the bushes when there’s a gap in the schedule.
A good PM will understand that to get to C, we need to build and support A + B before we can build C, and plan for this. Like, if we built B to be a terrible barely working mess, they understand that this will make C basically worthless. But in my experience, this ability is surprisingly rare.
you need a smart PM who works closely with the CTO to craft the narrative to sales, that the next critical feature milestone is gated behind fixing said tech debt...
I and one, maybe two other coworkers will fix some of the tech debt while everyone else tries to avoid making eye contact, and we fantasize about a world where voodoo dolls actually work.
This particular design has a very low burn-up indeed, but that's not because of the TRISO fuel. The Chinese HTR-PM helium cooled reactor, that went live 2 years ago, has a burnup of 90 GWd/ton of uranium, which is enriched at 8.5% U-235 [1]. That is an exceptionally high burn-up rate.
The eVinci reactor has an exceptionally low burn-up rate: about 4 GWd/ton, despite using a much more enriched fuel,at 19.75% ([2], but note that this is just an estimate, Westinghouse did not disclose the actual burnup). Why? That's the price you have to pay to have a micro-reactor. The square-cube law says that for such a reactor the surface of the core is very high compared to its volume, so the neutron economy is extremely poor. The only way to make it work is to use highly enriched uranium. Uranium enriched to more than 20% is considered weapons grade, so commercial reactors need to use fuel below that limit, and 19.75 is basically as high as you can go.
TRISO fuel is actually a miracle of science. It addresses many problems of the current generation reactor fuels. Fission results in transmutation. By the very nature of the fission process, you end up with fission products in burned fuel. Some of these products are gases (like Xeon) and they create pressure, and when you have hundreds of thousands of fuel elements some will burst, resulting in fission product discharge in the cooling water. Nasty stuff. The fuel in TRISO is encapsulated in some poppy-seed-sized granules, and it can withstand immense pressures, so this bursting scenario just does not happen. In addition to that, they can withstand immense temperatures as well, and they are surrounded by graphite that has an exceptional heat conductivity, and is also a very good moderator. From the point of view of reactivity control, graphite is actually the best moderator out there, ahead of hydrogen, deuterium and beryllium.
> is difficult to re-process
That's not a problem. You just don't reprocess it.
> it has quite low utilization of enriched uranium
This reactor will have low utilization, as discussed, but not because of the TRISO fuel.
That is an often repeated but incorrect thing. At the current rate of utilization, the proven reserves of uranium would last for one hundred years. What people miss is the fact that elevating a reserve to the status of “proven” (from the lower status of “probable”) costs money. Mining companies spend this money in order to get loans. Loan interest rates are better if the collateral is “proven” reserves. But the financing needs of these companies are limited by the business opportunity, so there is no incentive to “prove” more than 100 years worth of consumption. If the demand increases however, immediately you will see an increase of “proven” reserves. In the end we can extract unlimited amounts of uranium from seawater for only about 5x the current market price. It sounds like a lot, but it translates in less than one extra cent per kWh. The average retail price of 1kWh in the US is about 15 cents.
Since then 500 million people or more have been taken out of poverty. They are competing with you for resources. That's why what was going on in the US in the 50s is no longer possible.
Because all masses accelerate at equal rates in a gravitational field either:
1) Inertial mass and gravitational mass are exactly equal without an explanation why
or
2) The acceleration is just an effect of a curvature of space.
Imagine two bodies thrown exactly Northward on a sphere. Although their paths are parallel they would approach each other, as if there was an acceleration. This acceleration would be the same whatever their mass is.
>Imagine two bodies thrown exactly Northward on a sphere. Although their paths are parallel they would approach each other, as if there was an acceleration. This acceleration would be the same whatever their mass is.
The thing that always confuses me is how the distortion explains their behavior when stationary.
Sure, sure, "stationary" doesn't exist and everything is a matter of reference frames etc etc etc, but still, if you and I are both standing still on a sphere, there's nothing drawing us towards each other. Why are we drawn together from rest?
I am just trying to understand this and not make any claim, so bear with me.
Let's say we have a cylinder with a hemispherical top instead of a sphere.
Say the two objects were thrown directly from the base of the cylinder towards what would be the equivalent of north on the hemisphere. Relative to each other they would be moving perfectly parallel and the distance between them would not be changing.
Once they reach the hemispherical section they would still be moving parallel to one another at the same speed but the distance between them would start to shrink, wouldn't this be the equivalent of acceleration due to gravity? Movement towards each other started at 0 and increased, right?
