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?
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.
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
-
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.
-
Getting proficient with git and it’s usefulness. It is one of the single tools that can make you incredibly more productive.
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?
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.
-
I have commitment issues and git doesn’t let me push without commits. Am I not cut out to be a developer? /s
-
The concepts you should know/are expected to know are really going to depend on the company you’re working for and even the team within it. In general as a new grad you’re expected to be learning, and you will slow down the dev that’s assigned to be your mentor. That’s 100% okay, it’s part of their role as a mentor to be interrupted by you and help answer your questions so don’t feel bad about asking for help when you need it.
One useful skill you can start to pick up immediately is learning how to discover things within the company. If you ask your mentor a question and they just give you the answer, don’t hesitate to ask them to show you how they got to that answer. Whether it’s debugging, navigating documentation, etc, the most successful new hires I’ve seen have been ones who have showed that curiosity and used it to learn how to navigate within the company’s codebase/systems.
Another big change when you’ve only done internships in the past is to remember that your career is now a marathon, not a sprint. During an internship you often have a fixed amount of time to achieve a set goal so you can push hard and get there, knowing you’re done at that point and can take a break. Now that you’re working full time there will be more work waiting for you so if you keep pushing too hard you will burn out. Through trial and error you’ll need to find a pace that you can work at sustainably over an extended period of time. Yes, there will be times when you have to push hard for an important deadline or if things are on fire, but hopefully that will be the exception and not the rule. I don’t have any good advice for proactively avoiding burnout though. It’s something that you have to learn by experiencing it and trying to reflect and see if you can identify any early warning signs. I’m almost 20 years into my career now and it’s only in the past 4-5 years that I’ve started to be able to catch burnout before it happens and flag it to my manager.
If somebody more senior than you tells you to do a thing a certain way and you don’t understand why they think their way is better, ask them to explain it, but do it in a polite way. Asking the question shows you’re engaged in the process and not afraid to share your own input.
If you hear the explanation and still disagree, let it go and do it their way. Even if they’re wrong, they won’t want to hear about it from you at that point. You win some, you lose some. Being able to disagree and commit is huge.
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.
deleted by creator
