There isn't a yes-or-no answer to this. Some things I would consider:
1. Does this add additional complexity? How much more time/effort would it take to implement the feature? And most importantly, how much added effort would it take to maintain the feature? (Would adding this feature become a burden later?)
2. Can we be sure that the feature, as we would implement it now with our limited information, will meet future requirements, or would we perhaps be implementing something one way only for it to turn out that it would have been better implemented another way once there's an actual, defined usecase for it? (Remember that once you add something to an API, it can be hard to change or remove it later.)
You can if you have the time, if you also write unit-tests, and if your code will not give too much work for reviewers.
Most of my commits nowadays are very simple and small, and I try to stick to the immediate specifications because they may expanded in the future. In your example, what happens in the future if your boss says "the calculator may NEVER compute the difference of 2 numbers"? You will have useless code and/or harmful code that people will feel free to use but you may have to remove in the future. That's additional work for you.
Last but not least, putting too much unneeded new code may cause problems for others with merge conflicts if you use GitLab or GitHub. It happens all the time. Think about what you need, what you must do, and the problems you may cause later.
Why are you guessing which features to add...? Shouldn't this or any project be informed by some sort of research beforehand, either a formal UX and market research project, or at least a casual chat with the other teams to learn what they need now and in the near future? Then you can prioritize according to audience needs and wants instead of blindly adding random things that may or may not ever be used.
There isn't a yes-or-no answer to this. Some things I would consider:
1. Does this add additional complexity? How much more time/effort would it take to implement the feature? And most importantly, how much added effort would it take to maintain the feature? (Would adding this feature become a burden later?)
2. Can we be sure that the feature, as we would implement it now with our limited information, will meet future requirements, or would we perhaps be implementing something one way only for it to turn out that it would have been better implemented another way once there's an actual, defined usecase for it? (Remember that once you add something to an API, it can be hard to change or remove it later.)
You can if you have the time, if you also write unit-tests, and if your code will not give too much work for reviewers.
Most of my commits nowadays are very simple and small, and I try to stick to the immediate specifications because they may expanded in the future. In your example, what happens in the future if your boss says "the calculator may NEVER compute the difference of 2 numbers"? You will have useless code and/or harmful code that people will feel free to use but you may have to remove in the future. That's additional work for you.
Last but not least, putting too much unneeded new code may cause problems for others with merge conflicts if you use GitLab or GitHub. It happens all the time. Think about what you need, what you must do, and the problems you may cause later.
Why are you guessing which features to add...? Shouldn't this or any project be informed by some sort of research beforehand, either a formal UX and market research project, or at least a casual chat with the other teams to learn what they need now and in the near future? Then you can prioritize according to audience needs and wants instead of blindly adding random things that may or may not ever be used.
I generally view it as bad practice unless you are very confident you will need it soon. There's actually a term for this principle: YAGNI.
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
In this hypothetical example, how busy am I?
Not particularly.
Then yeah I'd probably add it