hummingn3rd

I am a bit confused by not talking about the salary right away, I have seen advice like yours and in this article about not giving the number fisrt but the opposite in other articles saying to leverage the anchoring bias by giving a high number first. That would help raising the following offers. Both approaches seem to make sense so I am not sure what to choose.

I have been wearing barefoot shoes for walking and felt better, no more pain in the knee, but outside of my personal experience, I haven't been able to find convincing studies on the benefits of barefoot shoes. Does anyone know any links about that ?

I thought this was going to be about all the physics rules in the discwolrd, like how light travels, the rule of the one chance in a million, or that cats can see the eight color or Death etc. I'd love to see a list of all of them, I haven't noticed any inconsistencies so far but I haven't read that many novels yet.

If you speak French or don't mind translating, there is this great video that goes through these techniques in layman's terms https://www.youtube.com/watch?v=FGwmAEMabm4&t=1

Thank you for your work! If you are interested in users verifying your binaries, maybe sigstore could help you.

https://www.sigstore.dev/

Most of the issues described there are solved for me by using pydantic: https://docs.pydantic.dev/latest/ (whose core has actually been recently rewritten in rust ^^).

To avoid switching parameters with the same type, I like to use * in my methods definitions instead of NewType to force naming parameters. Pydantic allows to validate methods parameters too (see https://docs.pydantic.dev/latest/usage/validation_decorator/) but this is at runtime and can add a performance overhead so it could be enough for the modules interfaces with the rest of the code only. For static checking, the NewType method is probably better, using a simple * avoided us many mistakes already.

That makes me think of The Scout Mindset: Why Some People See Things Clearly and Others Don't https://g.co/kgs/2eXND7

Martin fowler made a guide from his own transition to mastodon https://martinfowler.com/articles/exploring-mastodon.html

I've been really into psychology and how to adapt your communication based on that. I've really enjoyed the article taker vs giver on HN, I especially enjoy learning about cognitive biases and things like NVC.

I was curious of seeing if pydantic was mentioned, thanks! We use most of the same tooling as you, I'm always interested in improving our tooling, would you be willing to share your mypy plug-ins names or maybe most useful tools for inspiration?

I really like this way of versioning https://medium.com/@XenoSnowFox/youre-thinking-about-api-ver...

It uses Accept and Content-Type to version resources: application/vnd.company.article-v1+json

Hi, using git flow I would be more in favor for the rebase strategy, I think conflict resolving should be the responsibility of the developer adding the feature. It's part of the cost of developing it. However, it is essential to rebase all the time and do non breaking and microcommits, I suggest doing a rebase many times a day to handle conflicts a little at a time. Moreover, a feature branch should merge with the dev branch and not last more than three days at most to mutualize code and sharing value. This should prevent never ending conflicts

It would be great if it could generate from swagger API like prism

China is looking more and more like some famous distopia

Thanks for the article, I've just learned many options I didn't know !