Like if the main engineer creates lots of really useful hooks etc. is it stealing if you use them outside of work?

I’m talking about using the idea and not necessarily the entire code.

  • Zeth0s@lemmy.world
    link
    fedilink
    arrow-up
    12
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Do whatever you want. Someone has learned something from you at some point. That’s how life works

  • JSocial@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    That’s kind of how experience works. More experience usually means more pay. If one doesn’t take what they learned from previous employment, then they are stealing from their current employer.

    Also, who gives a fuck about your former employer’s IP? You don’t get paid enough to lick the boots of some corporation who isn’t paying you.

    Clone the whole repo and reference it when you need.

    • TootSweet@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      1
      ·
      1 year ago

      …but be smart about it. You never know when some former co-worker with a grudge against you might tattle on you to your unusually litigious former boss. Don’t go bragging about how you copy constantly from your old employer’s repo or have a copy of your old employer’s entire private corporate wiki.

      In other words, fuck your boss, but don’t fuck yourself over in the process.

      • JSocial@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        Good point. Also, your work absolutely does not need your socials, nor do your coworkers. That whole “we’re a family” thing is bullshit. Get real friends.

  • almightyGreek@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    Imagine if I couldn’t use what I learned from work in my side projects. All of them would have looked like I just finished uni

  • space@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    As a general rule, any code you write on company time and on company resources belongs to the company.

    But I think some common sense still applies. If you wrote some autohotkey or shell script that has nothing to do with the projects you worked on and boosts your productivity, sure, it’s fine to take it with you. For example, a script that pastes by typing the characters instead by pressing a certain combination of keys. Or a script that mounts the shared files drive in VMware.

    But taking code from your company projects is not okay. Maybe you implemented some fancy new middle-out compression algorithm in your company’s product, and you would like to take it with you, don’t. Maybe that gives your company the competitive edge.

    If you decide to build a competing product or work for a competing company, I would recommend being 100% clean. Read your contract carefully, and make sure you are 100% in the clear. Make sure that if your company wants to sue you, they have nothing on you. And maybe consult a lawyer.

  • PrinceWith999Enemies@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    If it’s simply good coding practice, then you’re fine.

    If you’re cloning an API, that might be a violation. If you’re copying blocks of code, that’s definitely a violation. The fact that someone else actually wrote it in the first place is also an obvious signal that the code went from work to your personal project, and not vice versa.

    If you’re still working there and want to continue to do so, I’d suggest reviewing your employment agreement and NDAs. Some employers have you sign an agreement that anything you write while employed belongs to them, others explicitly prevent you from using any ideas/use cases that you’re working on at work for outside applications.

  • mrbubblesort@kbin.social
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    It’s highly likely main engineer “stole” them from the guy that taught him. There’s nothing wrong with that, that’s just how learning and experience work.

  • fiah@discuss.tchncs.de
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    If you’re thinking about earning money with it while still being employed, think very hard about what you’re about to do. But otherwise, screw it, they don’t own what’s in your head, regardless of what bullshit they thought they could put into your contact

  • amenotef@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    I see this as part of the experience one has.

    My rule is to not take anything that has information from the client.

    For example I generally just create a txt file with a few example of “how to do this or that”. Generic stuff. So next time it takes me much less time to do the same thing.

  • intensely_human@lemm.ee
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    Methods are pretty much fair game. I’ve never had that be an issue at all, not even a potential one. The only thing that would be trouble is directly copying code from a private company repo.

    If you’re in cybersecurity and some of those methods are non-obvious and knowledge of them could cause your company or its clients some vulnerability, then it might be a different story.

    But at least in the places I’ve worked, absolutely none of the coding methods, design patterns, techniques, etc were considered trade secrets. Only the specific contents of the codebase were special. Like if I worked for Stephen King the only thing that would get me in trouble would be copy pasting one of his works. Using italics for thoughts like aha now we’re in business wouldn’t get me in trouble.

  • Scott@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    I wrote it for closed source software, I copy it for my closed source software.

    My bosses do the same thing for their personal projects, lol.