• Everyone else here who said, “Keep learning” is right on, but don’t forget to work on your soft people skills along with your tech skills. Whether your long term goal is to stay in development or some other aspect of the industry, you should be comfortable talking to all sorts of people (management, sales, customers, etc…), making presentations, being social at conferences and so on. We (techies like me) tend to forget this, but it’s really important.

    Imagine yourself starting your own company in five years or being the senior manager of a large group. How are you going to like meeting new people every day, selling or at least explaining your product or service to them? If the answer is “not very”, then start working on that now.

    • I don’t know if that’s obvious for people entering this profession but mind that you don’t read code like a book. Check how the functions you use are implemented. What’s being called from where (call stack helps in the debugger). How are experience programmers managing their code etc. It’s a good skill to learn how to navigate other people code and quickly find the parts that matter

  •  PowerCrazy   ( @PowerCrazy@lemmy.ml ) 
    link
    fedilink
    English
    1311 months ago

    Remember tech-companies exist to make money, not to “do good.” Whatever problem they are supposedly working on, they are only doing it because someone thinks they can eventually turn it into a revenue stream. Don’t drink the kool-aid, be a mercenary and get as much out of it that you can until you can leave for good. Dont’ be the like the smuck’s that are still working at twitter.

    • Yup, and this applies to any company. If you don’t own the business, you are a line item, not “family”. Always be ready to jump ship for a better opportunity, because they will do the same.

  •  Solemn   ( @Solemn@lemmy.dbzer0.com ) 
    link
    fedilink
    English
    1311 months ago

    Ask the experts from help, and learn from them. Don’t ask things you can legitimately learn really easily on your own by just doing a quick read of the code, but the bar for questions to not be stupid is pretty low. In most projects with any complexity, it’s probably overall saving the company money if you ask someone who knows and can save you time, instead of wasting a ton of your time reaching the same conclusion. But next time that problem comes up, you should know how to solve it, so it saves everyone time.

  • If you’re offered a job with more money/benefits or whatever, take it. Don’t give your employer the option to counter. And if you ever do let them counter out of curiosity, don’t take it… Leave.

    There’s too many horror stories of people basically staying on after a counter-offer, only to train their replacement and end up tossed out anyways.

    Loyalty doesn’t mean shit in tech; any promotion you get internally at a job will be pennies compared to what you’re able to get by shopping around; so do yourself a favor and run whenever the opportunity arises.

    •  Mike   ( @thirtyseven@unilem.org ) 
      link
      fedilink
      English
      311 months ago

      YMMV; staying can work well but you really have to know your employer, and be able to roll with the punches either way. It can be equally risky to be the new guy again. Always have an honest understanding of your replaceability.

      • If you’re irreplaceable, you’re probably doing something wrong, at least in tech.

        All technical fields especially should have a high bar for documenting what you do and how you do it, requiring documentation in every form and for every aspect. In my field, IT support/sysadmin/network admin, process, procedure, common fixes, system set up, network design, etc should all be documented. The only down side to having to replace me should be the long lead time for the new person to chew through the documentation to fully understand what’s going on and how it’s all interconnected, and not much more.

        IMO, person to person “knowledge transfer” as my current employer currently implements, is unviable, and should not be allowed to be the norm. There should never be only one person at an org that knows the job, and the current state of affairs and why the current state is what it is.

        If any org does have that single worker point of failure in knowledge, then they’re just one incident with a bus away from significant risk of their systems entirely collapsing. I call this the individuals “bus factor”, aka, if you’re hit by a bus, how fucked is everyone else? An IT person’s bus factor should always be low since almost all businesses are data management companies that make money doing X; everything from users Rolodex, to the CRM, to their communications and daily working tools, are almost always entirely dependent on IT, in some way, shape, or form. Less so for companies doing non-computer controlled manufacturing, but any desk job, or white collar office would entirely collapse if their IT staff was suddenly unavailable and their IT environment was to go down. At that point, just close up shop.

        •  arvere   ( @arvere@lemmy.ml ) 
          link
          fedilink
          English
          211 months ago

          I don’t think I agree with you, replaceability depends on a lot of factors, really.

          I’m a lead dev who works mostly in test automation and dev ops. I can assure you that no matter how much and thoroughly I document and share knowledge (I’ve became known in my company for that since every piece of doc has my name somewhere on it lol) I can’t see anyone around there being able to fully take the reins if something happened to me.

          in my case, it’s a mixture of talent crisis in the industry, lack of interest/expertise in the field and my own company’s culture (that doesn’t value these infrastructural subjects enough). I bet other people from different areas in tech might share different reasons

          but all in all, being irreplaceable is hardly an employee’s fault. if a company can’t manage to lose an employee (or lets people get away without documenting/sharing knowledge) it’s entirely their own fault!

          • I absolutely get what you’re saying, and it definitely depends on a lot of factors, mainly how easily replaceable you are.

            I agree with the fact that it takes a combination of talent, experience/expertise in the field, and the company itself (mainly it’s culture) that can dictate a lot of that. However, things like previous experience, and talent are not exactly things you can pass on to a new technician via any form of documentation without chronicling your life story with every instance of needing to do anything remotely technical which may lean into the problem-solving skills and thought process you uniquely have, and even then, on-boarding that experience would be a monumental challenge. Simply put, that’s not practical. Even that, doesn’t account for any ability to pass on talent, which isn’t quantifiable in any meaningful way.

            The main argument I have is that the knowledge of the organization’s systems, how they interconnect, why those interconnections matter, how they work, etc. should not be up for question or debate; and it should only be a matter of finding someone with relevant past experience in similar systems, with sufficient talent, who meshes adequately with the company culture, to be found, in order to replace someone.

            Unfortunately, finding someone with sufficient talent is often the most difficult part, and since it’s difficult to assess talent in an interview or even a set of interviews, it’s usually impossible to know if someone is going to “fit the bill” so-to-speak, until they’ve been thrown into the fire… This is the reason for the probationary period of most workers, both for the benefit of the worker, if they’re not meshing with the company, and for the company, if the worker isn’t capable of doing the job. Unfortunately, often, especially with I.T. work, it’s difficult to know whether someone is going to work out long-term after a few months, especially when the amount of knowledge someone needs to have to actually do most tech jobs is so monumental that it’s unlikely that the new hire is going to have any significant depth of knowledge in the technical systems within a few months of being hired.

            All of this sets aside the factor that every individual is unique and makes unique choices and contributions to the whole, so even “replacing” a very replaceable individual position, isn’t a 1:1 comparison, the new worker may be worse, or indeed, even better, than the previous one, but rarely, if ever, would perform EXACTLY the same in every circumstance.

            My core argument is that the information about the system (which needs to be supplemented by talent and experience), should never be lost if an employee decides to walk (either by finding a new job, walking in front of a bus, or off a short pier). If that information is lost, it’s a significant managerial oversight which allowed that to happen.

            •  arvere   ( @arvere@lemmy.ml ) 
              link
              fedilink
              English
              211 months ago

              yep, agreed will all of that

              in any case, I never been somewhere where this is properly done to the letter (from an individual’s or managerial’s perspective). not that I REALLY care tbf, I just do my part to the best of my knowledge and fly away hehe

              • I can appreciate that. I just think we were arguing the same points overall; and as demonstrated, there’s a lot not nuance, not only to the idea of what “replace” means, whether it’s simply having someone fill the role, or having someone do the same job at approximately the same efficiency and level of output, to what other factors may go into the job that cannot be transferred to newcomers by way of speech, text, or video.

                There’s certainly a lot to the discussion, as is the way with many things, but the amount you can help the next person by why of documentation, should always, ALWAYS be something that’s baked into the job.

                Hilariously, I advocated for better documentation at my employer, they gave me every excuse under the sun about it. I was only really asking “which documentation system are we moving forward with?” And got no clear answer. Work has ~4 different sets of documentation, all of which are in varying levels of being obsolete, irrelevant, or incomplete. I wanted to fix it and nobody could decide what to do, so I did nothing.

                About two months ago, I hit burnout, and now I’m on medical leave. So essentially, I had a bunch of information that nobody else had, and I was incapable of putting it into documentation, either due to the uncertainty of where to put it, or the whole zero hours a week that work gave me to document things… And then I was metaphorically hit by a bus.

                Sucks to be them.

                • yeah. I have the feeling that this story is way too common. which is very telling of how much the system isn’t driven towards innovation as many claim. we brag a lot about human ability to pass down knowledge via written language and turns out that most information passed down on some of the highest tech industries is done verbally or not at all! lol

  • If you have an opportunity to learn a new platform or technology, take it. Every environment has a different way of organizing, implementing, troubleshooting, etc. Each one you learn gives you a new way to look at a project, and teaches you something about how other people may think about projects, problems, and solutions.

    People who stick with the same tech for decades are also stuck with the same approach to new projects. When the only tool you have is a hammer, every problem looks like a nail, and all that. Get more tools in your tool belt.

  •  Chahk   ( @chahk@beehaw.org ) 
    link
    fedilink
    English
    811 months ago

    When interviewing, if a company gives you the “We work hard and we play hard” line, run. It actually means tons of unpaid overtime in exchange for some snacks and a broken ping-pong table.

  • Never stop learning. Most important advice IMO.

    Tech is a field that is constantly evolving, whether you’re a developer or IT service desk, the tools you use today will probably be very different 5 or 10 years from now. Never get stuck in a rut, it’ll burn you later in life. Remain curious and keep learning the new things coming out.

  •  accesslog   ( @accesslog@lemmy.one ) 
    link
    fedilink
    English
    7
    edit-2
    11 months ago

    No more than 2 years in a same company and always be interview ready. Keep regular contact with recruiters. There’s always a better opportunity.

    This is exactly what my friend did. He earns double my salary even though I work in one of those big companies and do more than just development.