Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @dan@d.sb

  • 0 Posts
  • 42 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle



  • dan@upvote.autoLemmy Shitpost@lemmy.worldYeah
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    6 days ago

    Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be dozens of commits and weeks of work from several developers. The code isn’t merged until the feature is complete. It’s more common in the industry compared to trunk-based development.

    My previous employer had:

    • Feature branches for each new feature.
    • A dev/trunk branch, where features branches were merged once they were done.
    • A beta branch, branched from dev once per week.
    • A live/prod branch, branched from beta four times per year.

    This structure is very common in enterprise apps. Customers that need stability (don’t want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.

    Bug fixes were annoying since you’d have to first do them in the live branch then port them to the beta and dev branches (or vice versa).

    On the other hand, feature flags mean that all the code goes directly into the trunk branch, but it’s turned off until it’s ready. A basic implementation of feature flags would be a static class with a bunch of booleans that get checked throughout the code, but they’re usually dynamic so a misbehaving feature can be turned off without having to redeploy the code.

    Some codebases use both feature branches and feature flags.


  • dan@upvote.autoLemmy Shitpost@lemmy.worldYeah
    link
    fedilink
    arrow-up
    6
    ·
    edit-2
    7 days ago

    It caters more for a linear workflow, though. So modern large teams won’t find joy with SVN

    For what it’s worth, I work at a FAANG company and we don’t use branches at all. Instead, we use feature flags. Source control history is linear with no merges.

    All code changes have to go though code review before they can be committed to the main repo. Pull requests are usually not too large (we aim for ~300 lines max), contain a single commit, aren’t long-lived (often merged the same day they’re submitted unless they’re very controversial), can be stacked to handle dependencies between them (“stacked diffs”), and a whole stack can be landed together. When merged, everything is committed directly to the main branch, which all developers are working off of.

    I know that both Google and Meta take this approach, and probably other companies too.






  • dan@upvote.autoLemmy Shitpost@lemmy.worldPSA on privuhcy
    link
    fedilink
    arrow-up
    23
    ·
    edit-2
    13 days ago

    This is kinda true but also kinda fear mongering. UTM parameters are just to track where you clicked the link from. They’re usually not dynamic, and don’t contain anything about you personally. The example in the screenshot utm_source=newsletter is probably added to all links in a company’s newsletter email, so they can tell that people get to the page via the newsletter.








  • There’s a lot of other expenses with an employee (like payroll taxes, benefits, retirement plans, health plan if they’re in the USA, etc), but you could find a self-employed freelancer for example.

    Or just get an employee anyways because you’ll still likely have a positive ROI. A good developer will take your abstract list of vague requirements and produce something useful and maintainable.



  • At this burn rate, I’ll likely be spending $8,000 month,” he added. “And you know what? I’m not even mad about it. I’m locked in.”

    For that price, why not just hire a developer full-time? For nearly $100k/year, you could find a very good intermediate or senior developer even in Europe or the USA (outside of expensive places like Silicon Valley and New York).

    The job market isn’t great for developers at the moment - there’s been lots of layoffs over the past few years and not enough new jobs for all the people who were laid off - so you’d absolutely find someone.