638 karma · joined June 28, 2019
That's what they call this and I think it's a pretty clear definition these days to people in the industry.
Is the expectation that people write kotlin in their browser? How do people work this into their development workflow? Is this just a neat demo?
I should also clarify. The sailboats in particular need the bridges raised which is why they have a scheduled time to exit. Ordinary boats can be removed closer to the water or navigate the river without the bridge being raised. Those boats are also removed for the winter.
I think relying on discipline alone in a team is usually a recipe for disaster or at the very least resentment while the most disciplined must continually educate and correct the least disciplined or perhaps least skilled. We have a clippy `deny` rule preventing panics, excepts, and unwraps, even though it's something we know to sometimes be acceptable. We don't warn because warnings are ignored. We don't allow because that makes it too easy to use. We don't use `forbid`, a `deny` that can't be overridden, because there are still places it could be helpful. What this means is that the least disciplined are pushed to correct a mistake by using `Result` and create meaningful error handling. In cases where that does not work, extra effort can be used to add an inline clippy allow instruction. We strongly question all inline clippy overrides to try to avoid our discipline collapsing into accepting always using `unwrap` & `allow` at review time to ensure nothing slips by mistakenly. I will concede that reviews themselves are potentially a dangerous "discipline trap" as well, but it's the secondary line of defense for this specific mistake.
My understanding of this reputation is: This often happens at the detriment of either product quality or employee satisfaction. It's debatable if they actually have a reputation of providing value. I think short term? Maybe, albeit expensive. Long term? I'd say no.
Tiktok was allowed to establish its own brand and develop a community while shorts and reels are intrinsically tied to their past. They may be able to escape that history but I don't think it's helping them be fast movers or win "cool" points.
Is this just your belief or is there evidence you can point to.
How would you differentiate manual intervention from algorithmic intervention?
https://github.com/facebook/buck2/tree/main/starlark-rust/vs...
I thought this was a pretty good system and despite the cycles being shorter, we had enough engineers to fill a rotation pretty well so that at most you were on call once a month, alternating months between weekend and weekday on-call cycles.
I still do not enjoy being forced into on call and wish I could opt-in. We traded weeks a lot but with smaller rotations or really finicky paging its awful. I still have a sinking feeling in my gut when I hear the work phone ringtone from somebody else's phone in public, and murphy's law definitely applies to being on call -- you always get paged the minute after your beer gets delivered at a restaurant.
There are dozens of articles about the problems with matrix management that it introduced.
It produces a dividend of shelter for the owner. Assuming labor and material prices are fixed, the asset should be depreciating in value from wear and use which would all point to flat or lowering value.
Assuming that it must make returns, one or more of the following must be true:
* Labor price increases
* Material price increases
* Land value increases
`git commit -m "Fix actual words that humans read" -m "Fixes: #234353"`
You could probably script this based on branch if you're one of those people who names branches after ticket numbers.
But my actual advice is that I think -m is a bad pattern that leads to bad commit messages, and omitting the message argument opens your EDITOR, and you should use that.