12
What makes a new grad developer look competent to senior devs and managers? (lemmy.ml)
submitted 3 years ago by to c/ask_experienced_devs@programming.dev
12 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 3 years ago* (2 children)

  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.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 2 points 3 years ago (1 child)

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

    Could you elaborate?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 3 years ago

    Using git effectively is like heading superpowers in programming compared to not having any version control as it allows you to do a bunch of things that would be very complex otherwise. Ex:

    • When writing code, if you only commit “working code” it’s easy to check at any moment what changes you’ve done in the last chunk with git status. Even most IDEs nowadays highlight the changes lines with some special marker. This allows you to know every detail of what you’re doing without filling your working memory tracking files yourself.

    • Seeing the history of your project allows you to track any of your workmates changes as well, you can always check who last changed a line of code with git blame (IDEs also make that easier), your commit text will usually tell you what is that change about.

    • It allows you to quickly try something out and if halfway through it you realize it won’t work, just discard the changes and restart using a different approach.

    • It allows you to have multiple “work-in-progress” features simultaneously in different branches, which makes it possible to do hotfixes on production code even though the development branch is way ahead.

    • It lets you break a big feature into multiple small commits and later on it’s easy to gather multiple commits in a branch into one big commit if it makes sense (let’s say you were not sure how you’d do it at first and kept changing something back and forth trying different things. Once you realize what the best approach is, you can turn all those changes into a single one).

    • Committing often allows you to “revert” any change in the future very easily, in a non destructive way.

    So a lot of advantages of git require also to use it alongside best practices, such as the different git branching models. It doesn’t matter if you prefer using the command line or some visual client, just the fact of understanding how you’re using it makes a lot of difference.

  • permalink
  • fedilink
  • source
  • parent