• 0 Posts
  • 120 Comments
Joined 1 year ago
cake
Cake day: July 25th, 2023

help-circle
  • Really bigger updates obviously require a major version bump to signify to users that there is potential stability or breakage issues expected.

    If your software is following semver, not necessarily. It only requires a major version bump if a change is breaking backwards compatibility. You can have very big minor releases and tiny major releases.

    there was more time for people to run pre-release versions if they are adventurous and thus there is better testing

    Again, by experience, this is assuming a lot.











  • The brackets are pretty simple. It’s percentages and subtractions. Think “buckets” that spill over in the next when they’re full, and each “bucket” has a larger percentage that’s taken as taxes. Keep the numbers small so its easier. Imagine that there are three brackets. 0-100$ pays 10% tax. 101-200$ pays 20%. 200$ and more pays 30%.

    Someone who wins 150$ pays 10% on the money they made from 0 to 100$, and 20% on the 101st dollar until their last, so they’ll win 150-10-10=130$ after tax. They didn’t win more than 200$, so no money gets taxed at the third bracket’s rate.

    Say that person wins 250$ next year. Their first 100$ will result in the exact same 10$ in taxes. Their 100th to 199th dollars will be in the second 20% bracket. Their remaining 50$ falls in the last bracket, so gets taxed 30%. They will therefore this year make 250-10-20-15=205$ after tax.

    Said person gets a big promotion and is now making 1000$ the third year. Their first 100$ gets the same 10$ tax, same for their second 200$ with the same 20$ tax. They have 800$ left in the last bracket, which at 30% means 240$. So they’d be winning 1000-10-20-240=730$ that year.


  • I too had those hour long snoozefests where 99% of what’s said doesn’t pertain to my work, and those useless meetings that could have been a message on a Slack channel. I still feel like the sentiment is a very broad generalization based on some assumptions that may or may not apply well to every work environment.

    My most recent project has direct dependencies between 5 teams just on the developer side, and multiple internal and external clients. Figuring out if we need to reach out to the stakeholders or figuring out who can help them on a particular task isn’t necessarily always that straightforward, depending on scope.

    Anecdotally, the devs on my team were losing a lot of their time doing all that stuff before I joined as a tech lead in August. I spend most of my non-dev time (about 50% of my time, lately) shielding the rest of the team from stakeholders, pushing back when needed, pushing back on various demands, enabling communication lines, all to protect them from context switching and let them code.

    And honestly… Outside all that, agreeing with me or not, is 15 minutes of human interaction that terrible lol?


  • we don’t need managers we need people helping us getting the tools we need and trust that what we do

    The word “manager” is extremely overloaded and barely says anything about what that person does for its team without knowing how the company operates. Where I work, the person you’re describing would be someone in technical management.