I’m well aware this post has been asked to death on Reddit, but I couldn’t find anything relevant on Lemmy so I thought I’d give it a shot.

I’m starting my first SDE job next week, and to be honest I’ve never really been a dev in a professional environment before. I’ve had an internship where the bar was very low so I did decently, and a part-time gig where I just assigned myself tickets. Either way I’ve never worked on a larger team or in a specific org before.

Apart from the usual like “ask questions when you’re stuck”, “write proper documentation”, “be proactive”, and “communicate well”, what are some technical things I should be familiar with to make sure I’m not bogging anyone down?

More specifically, are there concepts I should know/I am expected to know of that I might not have learned in university?

  • sjg@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Whatever the tech you’re using, find the primary documentation for it, and read it carefully until you understand it properly. Rinse and repeat for 30 years and you’ll be a guru.

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

    I’d add things like

    • plan before you act (be that design before code, or something else of the sort)
    • avoid asking the same question multiple times (take notes, study up on things, and try to not ask the same question or make the same mistake over and over)
    • write useful tests and have good test coverage
  • bignavy@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Good advice already in this thread, but I’d add: ask smart questions, and when you’re engaging with a senior/mentor, build the picture for them. Everyone (including your mentor) expects you to have questions - they want you to ask questions, rather than just spinning your wheels for days and days. But they also want to know what you’ve tried and what you’ve looked at for resources. And despite appearances, they don’t always have the entire code base committed to memory. :)

    For instance - suppose you’d been asked to, using the UI, return a piece of information from an external API and display it within the UI.

    Bad question: “Hey, so I tried to integrate that third party API, but I’m not getting a return.”

    “Okay - what kind of code are you getting? And what do the docs say?”

    🤷‍♂️

    Good question: “Hey, so I tried to integrate that third party API, but the return I’m getting from it is a 401 error. That should be an authentication error - but just in case, I pinged their server from our server, and they can reach each other. The documentation says that I have to use our key to get a JWT, but hitting the endpoint it says gives me a 401 error. I double checked our token; I’ve got the right one. And I’m sending it in the header as ‘auth’ like the documentation says. Where else should I look?”

    “Oh yeah, that’s a tricky one - you have to encode the token before you send it; let me see if I’ve got an example where you can see what that looks like…”

    One of the things that will happen over time, based on the questions that more senior SDEs ask, you’ll be able to ‘rubber ducky’ problem solve by asking yourself the questions that they would usually ask you, and it’s shockingly effective to help you sort your own problems out and clear your own blockers.

  • Baldur Nil@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 year ago
    1. Paying attention and caring about the quality of your output go great lengths. I’ve seen even supposedly senior devs doing a shitty job out of laziness to check what they’re doing.

    2. Getting proficient with git and it’s usefulness. It is one of the single tools that can make you incredibly more productive.

  • xyproto@programming.dev
    link
    fedilink
    arrow-up
    1
    arrow-down
    3
    ·
    1 year ago

    I asked GPT4:

    What are the main differences between having 5 years of experience in a job and 20 years of experience? Make a bullet point list.

    Certainly! Here’s a list detailing some of the main differences between having 5 years and 20 years of experience in a job:

    5 Years of Experience:

    • Foundational Understanding: A solid grasp of the basics and might have ventured into some specialized areas.
    • Eagerness to Learn: Often more receptive to new ideas, looking for opportunities to grow and expand skill sets.
    • Intermediate Problem-Solving: Have encountered and overcome a range of common challenges but might still need guidance for more complex situations.
    • Building Network: Still in the process of developing a professional network within the industry.
    • Adapting to Company Culture: Fully integrated into the company’s culture but might be less resistant to major shifts.
    • Potential for Errors: A higher likelihood to make mistakes as compared to someone with more years of experience.
    • Focused Growth: Looking for ways to advance in their career, either through promotions, lateral moves, or increased responsibilities.
    • More Current Training: Might have more recent education or training on new technologies or methodologies.

    20 Years of Experience:

    • Deep Expertise: Possess a profound understanding of nuances, having seen many scenarios, changes, and evolutions in the industry.
    • Mentorship Role: Often serve as mentors or guides to younger or less experienced colleagues.
    • Advanced Problem-Solving: Can anticipate and solve complex problems based on extensive past experiences.
    • Established Network: Have a wide and deep network of contacts in the industry that can be leveraged for various needs.
    • Shaping Company Culture: Have seen the company culture evolve and might play a role in influencing it.
    • Strategic Thinking: More likely to think in terms of long-term goals and strategies rather than immediate tasks.
    • Stability & Consistency: Typically more resistant to change, valuing stability and having established personal methodologies for accomplishing tasks.
    • Potential for Innovation: While some might be set in their ways, their vast experience can also be a source of innovation, drawing from decades of knowledge to create new solutions.

    It’s essential to note that the above points are generalizations. Individual experiences and growth can vary widely based on the person, the industry, the company, and many other factors.