• 0 Posts
  • 17 Comments
Joined 3 years ago
cake
Cake day: July 29th, 2023

help-circle




  • IMALlama@lemmy.worldtoSelfhosted@lemmy.worldSelfhosted coding assistant?
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    3
    ·
    2 months ago

    Straight up vibe coding is a horrible idea, but I’ll happily take tools to reduce mundane tasks.

    The project I’m currently working on leans on Temporal for durable execution. We define the activities and workflows in protobufs and utilize codegen for all the boring boiler plate stuff. The project hasa number of http endpoints that are again defined in protos, along with their inputs and outputs. Again, lots of code gen. Is code gen making me less creative or degrading my skills? I don’t think so. It sure makes the output more consistent and reduces the opportunity for errors.

    If I engage gen AI during development, which isn’t very often, my prompts are very targeted and the scope is narrow. However, I’ve found that gen AI is great for writing and modifying tests and with a little prompting you can get pretty solid unit test coverage for a verity of different scenarios. In the case of the software I write at work the creativity is in the actual code and the unit tests are often pretty repetitive (happy path, bad input 1…n, no result, mock an error at this step, etc). Once you know how to do that there’s no reason not to offload it IMO.





  • That your company has an in-house software dev team is impressive. Does the revenue-generating business have access to that team?

    Not OP, but in a similar situation. We have in-house dev for both tooling/infrastructure as well as revenue generation. For better or worse, leaders have neglected the software tooling and infrastructure that we use to build and deliver our revenue generating software for decades. Some serious cracks in the foundation showing and we might finally start fixing things.


  • I feel this in my bones. Even before the recent round of restructuring we’ve had a significant about of turnover. Our infrastructure is a massive rube golberg machine with multiple houses of cards built on top of it. Institutional knowledge was never written down and it has been leaving the company at an accelerating rate over the past 5 years. Tons of “new blood” making lots of assumptions on how things work is resulting in… humorous end results.







  • We have a test environment but it’s a hot mess. All the data is made up and extremely low quality. All the things you would normally interface with are also in test, but getting other teams to coordinate testing in the test space is… a chore. We do the best we can with mock services, but without having real services or representative data some of the data pattern assumptions don’t play out. Leaders value writing code and our lack of architects that span teams mean that when team architects either don’t meet ahead of time, make assumptions, or don’t ever agree on a design then…

    We always host UAT. We also track logins. Guess how many users even show up for UAT, let alone actually click on anything.

    This is why the vast majority of our testing happens in prod when our users are doing real work.

    Sorry for the baby rant :)


  • This can also be one of the frustrating parts of open source.

    Find something you don’t like? Fix it. Will the repo owner approve your pull request? Who knows. Maybe they’re a bit absentee. Maybe they view the original behavior as working as designed. Maybe your design doesn’t fit their architectural model, so they’ll (eventually) heavily refactor your changes and merge them in.

    You can always stand up a fork, but keeping those two at feature parity and going in the same general direction can become harder and harder with time.

    That’s not to say not to try! But it also means reaching out to the repo owners/maintainers before making your first change.