Semver is based on a lie. It assumes that you can define what is the proper behavior of a library. That's
not necessarily true, and can be subtlety false, and different depending on the use case. I can think on some situations where I trusted semantic versioning and it bited me when an update was made. I am not talking about new bug introductions. I assumed behavoir that the library owner assumed as not important.
There should be no shame in younger people above ourselves. I am 46 and a coupple of years ago the CEO and CTO of the company I worked for were in their twenties. It did not bother me at all. If they do their jobs properly, it is fine at any age. If they dont do their jobs properly, it is not fine at any age.
I think that there are 2 foundationañ problems that make complex projects over budget:
1. Stakeholders are incentivized to negotiate down the budget, skewing the result.
2. Breaking down a big task into smaller ones comes with the risk of missing some activities, but adding a nob-required subtask is almost imposible, also skewing the results.
Estimates of big endevours must be made by comparison instead of breaking down the tasks to avoid the second issue. That's one of the little secrets that make poker planning succesfull.
Extra points: leave old and outdated documentation and scripts in the repository. New documentation should go to a wiki that is not referenced in code and does not track versions. Different parts of the wiki should apply to different code versions.
I think that the parent says that while you can learn almost anything from youtube, it is imposible for other people to know that you know something you learned on youtube without a test.
I find it sad that this post was flagged. If it is not found interesting by the community no one would upvote it and it would just fade away. Flagging posts like this one makes hacker news far less interesting.
That's not true. It needs to recharge a part of the electricity used. For example, if it provides 2/3 of the electricity being used it would potentially triple the range.
Given what you explained, it seems to me that the cloud was an excuse given by the new overlords to just get you out off the way. Cloud is fashionable now, but any excuse would work for them. This seems to be a power grab.
Commit early. But do not commit garbage. Each commit should be a small but meaningful advance. All tests should pass. If working with compiled code, off course it should compile. No todos. No clunky var or method names. A branch per merge request.
If you do it like this it is great for everyone. Do not squash commits or rebase. Those are antipatterns. We are lying to ourselves when we do it. We cannot learn from history we rewrite.