React has idioms
idomatic
8 Matching Annotations
- Mar 2024
-
react.dev react.dev
-
- Nov 2023
-
abseil.io abseil.io
-
One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs.
This times a million
-
The most storied compiler upgrade in Google’s history took place all the way back in 2006
I like the stories in this book
-
Just as entropy increases in every thermodynamic system, Hyrum’s Law applies to every observable behavior.
Seems like a stretch how they're relating this to entropy
-
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
I've heard some rants by Linus Torvalds about this very issue in the Linux kernel. If a bug gets shipped it's now a feature.
-
For most Google projects, we must assume that they will live indefinitely
Funny because Google has a reputation for abandoning projects.
-
“What is the expected life span1 of your code?”
This is difficult to answer. Hopefully my company is successful and stays in business for a long time. If that's the case I'm still not sure that the code itself will have a long lifespan. If it's amenable to change I would expect it to be changed over and over in the coming years.
At a startup it's difficult to balance short-term needs with long-term aspirations.
-
-
abseil.io abseil.io
-
Mechanical engineers, civil engineers, aeronautical engineers, and those in other engineering disciplines all practice engineering. They all work in the real world and use the application of their theoretical knowledge to create something real. Software engineers also create “something real,” though it is less tangible than the things other engineers create.
I have never been that comfortable with putting the production of software in the same category as other engineering professions.
In those other professions the engineer creates a full design before any building begins. For example a civil engineer creates the design for a bridge, sign-offs happen, and then construction workers begin building.
People have tried to make software engineering work this way. In theory you can have an engineer design the system as a set of UML diagrams, a visual designer creating a set of mockups, and then hand the documentation over to an offshore contractor for building (programming). What we've seen in practice is that this doesn't work very well.
In software engineering you interleave building and designing. Any up front designs are open to modification as the builder uncovers new knowledge (probably much more than the design of a bridge).
Additionally many pieces of software are ongoing projects that last as long as the company funding them is in business. Programming is like building a bridge. Software engineering is like running a city.
-