• 2 Posts
  • 30 Comments
Joined 4 months ago
cake
Cake day: July 6th, 2024

help-circle



  • ByteOnBikes@slrpnk.nettolinuxmemes@lemmy.worldIt do be like that
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    1 month ago

    I’m laughing way too hard at this.

    Honestly this is the best answer.

    Like, use the tools that work for your use case?

    I fucking hate macs but man using a video editor on windows was a pain back in the day. Where I would rather set up a server on Linux, than use whatever the hell windows servers operate.


  • I took it as software engineers tend to build for scalability. And yep, IT often isn’t prepared for that or sees it as wasted resources.

    Which isn’t a bad thing. IT isnt seeing the demands the manager/customer wants.

    I’m glad you’ve done both because yeah, it’s a seesaw.

    If IT provisions just enough hardware, we’ll hit bottlenecks and crashes when there’s a surprise influx of customers. If software teams don’t build for scale, same scenario, but worse.

    From the engineer perspective, it’s always better to scale with physical hardware. Where IT is screaming, “We dont have the funds!”




  • . I think to be a good software developer it helps to know what’s happening under the hood when you take an action.

    There’s so many layers of abstractions that it becomes impossible to know everything.

    Years ago, I dedicated a lot of time understanding how bytes travel from a server into your router into your computer. Very low-level mastery.

    That education is now trivia, because cloud servers, cloudflare, region points, edge-servers, company firewalls… All other barriers that add more and more layers of complexity that I don’t have direct access to but can affect the applications I build. And it continues to grow.

    Add this to the pile of updates to computer languages, new design patterns to learn, operating system and environment updates…

    This is why engineers live alone on a farm after they burn out.

    It’s not feasible to understand everything under the hood anymore. What’s under the hood grows faster than you can pick it up.



  • Absolutely agree, as a developer.

    The devops team set up a pretty effective setup for our devops pipeline that allows us to scale infinity. Which would be great if we had infinite resources.

    We’re hitting situations where the solution is to throw more hardware at it.

    And IT cannot provision tech fast enough within budget for any of this. So devs are absolutely suffering right now.





  • At my job, we have an error code that is similar to this. On the frontend, it’s just like error 123.

    But in our internal error logs, it’s because the user submitted their credit card, didnt fully confirm, press back, removed all the items out of their cart, removed their credit card, then found their way back to the submit button through the browser history and attempted to submit without a card or a cart. Nothing would submit and no error was shown, but it was UI error.

    It’s super convoluted. And we absolutely wanted to shoot the tester who gave us this use case.





  • I’m not as much vitriol as others about Clean Code, but I will argue that engineers who preach the book as some sort of scripture are really obnoxious.

    I love the Single Responsibility Principle, in theory.

    What I don’t like is when devs try to refactor everything to that idea to achieve “Clean Code”. I’ve seen devs over-architect a solution, turning one function into many, because they don’t want to break that rule. Then point to this book as to WHY their code is now 20x longer than it needs to be.

    It also doesn’t help that every recommendation about good programming books include this.

    It’s like recommending a Fitness book from the 70s - information made sense at the time, but new research has made a lot of the advice questionable.

    My main issue is the whole “Uncle Bob” persona. Robert C Martin is sexist and a racist, and has been uninvited by conferences. We don’t need that type of toxicity in the industry.