Rest is for the dead

Previously Baguette@lemm.ee

  • 0 Posts
  • 31 Comments
Joined 2 years ago
cake
Cake day: February 1st, 2024

help-circle


  • The thing is that there are real measurements of the market share of windows dropping. The only reason why adoption of w11 overtook w10 user size is because they made w10 end of life (although there are still ways around)

    Unfortunately, some business idiot mathed up that losing users is fine as long as the others get forced onto w11

    Windows could have done so much differently. More seamless integration with xbox and cross platform for gaming. Different, easily swappable profiles (windows) for different tasks (basically overhauling desktops, like for art, dev work, etc). Optimizing microsofts enterprise software suite without all the bloat. Not deprecating the idea of android support.

    But like all big tech companies, they only see money now













  • Like always, how far your money goes depends on multiple factors. 140k in the Midwest alone means you’re living comfortably. Like all bills paid off, a lot of extra money for leisure, etc.

    If you have a family and live in the bay area, then it’s not that much. I personally wouldn’t put it at poverty, but it’d be somewhat close to being paycheck to paycheck (assuming you still need to pay mortgage and whatnot)






  • The issue with my org is the push to be ci/cd means 90% line and branch coverage, which ends up being you spend just as much time writing tests as actually developing the feature, which already is on an accelerated schedule because my org has made promises that end up becoming ridiculous deadlines, like a 2 month project becoming a 1 month deadline

    Mocking is easy, almost everything in my team’s codebase is designed to be mockable. The only stuff I can think of that isn’t mocked are usually just clocks, which you could mock but I actually like using fixed clocks for unit testing most of the time. But mocking is also tedious. Lots of mocks end up being:

    1. Change the test constant expected. Which usually ends up being almost the same input just with one changed field.
    2. Change the response answer from the mock
    3. Given the response, expect the result to be x or some exception y

    Chances are, if you wrote it you should already know what branches are there. It’s just translating that to actual unit tests that’s a pain. Branching logic should be easy to read as well. If I read a nested if statement chances are there’s something that can be redesigned better.

    I also think that 90% of actual testing should be done through integ tests. Unit tests to me helps to validate what you expect to happen, but expectations don’t necessarily equate to real dependencies and inputs. But that’s a preference, mostly because our design philosophy revolves around dependency injection.